draft-ietf-v6ops-ra-guard-08.txt   rfc6105.txt 
v6ops Working Group E. Levy-Abegnoli Internet Engineering Task Force (IETF) E. Levy-Abegnoli
Internet-Draft G. Van de Velde Request for Comments: 6105 G. Van de Velde
Intended status: Informational C. Popoviciu Category: Informational Cisco Systems
Expires: March 6, 2011 Cisco Systems ISSN: 2070-1721 C. Popoviciu
Technodyne
J. Mohacsi J. Mohacsi
NIIF/Hungarnet NIIF/Hungarnet
September 02, 2010 February 2011
IPv6 Router Advertisement Guard IPv6 Router Advertisement Guard
<draft-ietf-v6ops-ra-guard-08.txt>
Abstract Abstract
Routed protocols are often susceptible to spoof attacks. The Routed protocols are often susceptible to spoof attacks. The
canonical solution for IPv6 is Secure Neighbor Discovery (SEND), a canonical solution for IPv6 is Secure Neighbor Discovery (SEND), a
solution that is non-trivial to deploy. This document proposes a solution that is non-trivial to deploy. This document proposes a
light-weight alternative and complement to SEND based on filtering in light-weight alternative and complement to SEND based on filtering in
the layer-2 network fabric, using a variety of filtering criteria, the layer-2 network fabric, using a variety of filtering criteria,
including, for example, SEND status. including, for example, SEND status.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on March 6, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6105.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 7 skipping to change at page 2, line 34
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
2. Model and Applicability . . . . . . . . . . . . . . . . . . . 4 2. Model and Applicability .........................................3
3. Stateless RA-Guard . . . . . . . . . . . . . . . . . . . . . . 6 3. Stateless RA-Guard ..............................................5
4. Stateful RA-Guard . . . . . . . . . . . . . . . . . . . . . . 6 4. Stateful RA-Guard ...............................................6
4.1. State Machine . . . . . . . . . . . . . . . . . . . . . . 7 4.1. State Machine ..............................................6
4.2. SEND-based RA-Guard . . . . . . . . . . . . . . . . . . . 8 4.2. SEND-Based RA-Guard ........................................8
5. RA-Guard Use Considerations . . . . . . . . . . . . . . . . . 9 5. RA-Guard Use Considerations .....................................8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations .........................................9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements ................................................9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. References ......................................................9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References .......................................9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References .....................................9
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
When operating IPv6 in a shared L2 network segment without complete When operating IPv6 in a shared layer-2 (L2) network segment without
SEND support by all devices connected or without the availability of complete SEcure Neighbor Discovery (SEND) support by all devices
the infrastructure necessary to support Secure Neighbor Discovery connected or without the availability of the infrastructure necessary
(SEND) [RFC3971], there is always the risk of facing operational to support SEND [RFC3971], there is always the risk of facing
problems due to rogue Router Advertisements generated maliciously or operational problems due to rogue Router Advertisements (RAs)
unintentionally by unauthorized or improperly configured routers generated maliciously or unintentionally by unauthorized or
connecting to the segment. improperly configured routers connecting to the segment.
There are several examples of work done on this topic which resulted There are several examples of work done on this topic that resulted
in several related studies [reference1] [reference2] in related studies and code, including [NDPMON] [KAME]
[reference3].This document describes a solution framework for the [IPv6-SAMURAIS]. This document describes a solution framework for
rogue-RA problem where network segments are designed around a single the rogue-RA problem [RFC6104] where network segments are designed
or a set of L2-switching devices capable of identifying invalid RAs around a single L2-switching device or a set of L2-switching devices
and blocking them. The solutions developed within this framework can capable of identifying invalid RAs and blocking them. The solutions
span the spectrum from basic (where the port of the L2 device is developed within this framework can span the spectrum from basic
statically instructed to forward or not to forward RAs received from (where the port of the L2 device is statically instructed to forward
the connected device) to advanced (where a criteria is used by the L2 or not to forward RAs received from the connected device) to advanced
device to dynamically validate or invalidate a received RA, this (where a criterion is used by the L2 device to dynamically validate
criteria can even be based on SEND mechanisms). or invalidate a received RA, this criterion can even be based on SEND
mechanisms).
2. Model and Applicability 2. Model and Applicability
RA-Guard applies to an environment where all messages between IPv6 RA-Guard applies to an environment where all messages between IPv6
end-devices traverse the controlled L2 networking devices. It does end-devices traverse the controlled L2 networking devices. It does
not apply to a shared media, when devices can communicate directly not apply to shared media, when devices can communicate directly
without going through an RA-Guard capable L2 networking device. without going through an RA-Guard-capable L2 networking device.
Figure 1 illustrates a deployment scenario for RA-Guard. Figure 1 illustrates a deployment scenario for RA-Guard.
Block Allow Block Allow
+------+ incoming +---------+ incoming +--------+ +------+ incoming +---------+ incoming +--------+
|Host | RA | L2 | RA | Router | |Host | RA | L2 | RA | Router |
| |----------------| device |--------------| | | |----------------| device |--------------| |
+------+ +----+----+ +--------+ +------+ +----+----+ +--------+
| |
|Block |Block
|incoming |incoming
|RA |RA
| |
| |
| |
+---+---+ +---+---+
| Host | | Host |
| | | |
+-------+ +-------+
Figure 1 Figure 1
RA-Guard does not intend to provide a substitute for SEND based RA-Guard does not intend to provide a substitute for SEND-based
solutions. It actually intends to provide complementary solutions in solutions. It actually intends to provide complementary solutions in
those environments where SEND might not be suitable or fully those environments where SEND might not be suitable or fully
supported by all devices involved. It may take time until SEND is supported by all devices involved. It may take time until SEND is
ubiquitous in IPv6 networks and some of its large scale deployment ubiquitous in IPv6 networks and some of its large-scale deployment
aspects are sorted out such as provisioning hosts with trust anchors. aspects are sorted out, such as provisioning hosts with trust
It is also reasonable to expect that some devices might not consider anchors. It is also reasonable to expect that some devices, such as
implementing SEND at all such as IPv6 enabled sensors. An RA-Guard IPv6-enabled sensors, might not consider implementing SEND at all.
implementation which SEND-validates RAs on behalf of hosts would An RA-Guard implementation that SEND-validates RAs on behalf of hosts
potentially simplify some of these challenges. would potentially simplify some of these challenges.
RA-Guard can be seen as a superset of SEND with regard to router RA-Guard can be seen as a superset of SEND with regard to router
authorization. Its purpose is to filter Router Advertisements based authorization. Its purpose is to filter Router Advertisements based
on a set of criteria, from a simplistic "RA disallowed on a given on a set of criteria, from a simplistic "RA disallowed on a given
interface" to "RA allowed from pre-defined sources" and up to full interface" to "RA allowed from pre-defined sources" and up to a full-
fledge SEND "RA allowed from authorized sources only". fledged SEND "RA allowed from authorized sources only".
In addition to this granularity on the criteria for filtering out In addition to this granularity on the criteria for filtering out
Router Advertisements, RA-Guard introduces the concept of router Router Advertisements, RA-Guard introduces the concept of router
authorization proxy. Instead of each node on the link analyzing RAs authorization proxy. Instead of each node on the link analyzing RAs
and making an individual decision, a legitimate node-in-the-middle and making an individual decision, a legitimate "node-in-the-middle"
performs the analysis on behalf of all other nodes on the link. The performs the analysis on behalf of all other nodes on the link. The
analysis itself is not different from what each node would do: if analysis itself is not different from what each node would do: if
SEND is enabled, the RA is checked against X.509 certificates SEND is enabled, the RA is checked against X.509 certificates
[RFC4861]. If any other criteria is in use, such as known L3
[RFC4861]. If any other criterion is in use, such as known L3
(addresses) or L2 (link-layer address, port number) legitimate (addresses) or L2 (link-layer address, port number) legitimate
sources of RAs, the node-in-the middle can use this criteria and sources of RAs, the node-in-the middle can use this criterion and
filter out any RA that does not comply. If this node-in-the-middle filter out any RA that does not comply. If this node-in-the-middle
is a L2 device, it will not change the content of the validated RA, is an L2 device, it will not change the content of the validated RA
and avoid any of the ND-proxy pitfalls. and will avoid any of the ND-proxy pitfalls.
RA-Guard intends to provide simple solutions to the rogue-RA problem RA-Guard intends to provide simple solutions to the rogue-RA problem
in contexts where simplicity is required while leveraging SEND in an in contexts where simplicity is required while leveraging SEND in a
context environment consisting of with a mix of SEND capable devices context environment consisting of a mix of SEND-capable devices (L2
(L2 switches and routers) and devices that do not consistently use switches and routers) and devices that do not consistently use SEND.
SEND. Furthermore, RA-Guard is useful to simplify SEND deployments, Furthermore, RA-Guard is useful to simplify SEND deployments, as only
as only the L2 switch and the routers are required to carry the L2 switch and the routers are required to carry certificates
certificates (their own and the trust anchor certificates). (their own and the trust anchor certificates).
3. Stateless RA-Guard 3. Stateless RA-Guard
Stateless RA-Guard examines incoming RAs and decide whether to Stateless RA-Guard examines incoming RAs and decides whether to
forward or block them based solely on information found in the forward or block them based solely on information found in the
message or in the L2-device configuration. Typical information message or in the L2-device configuration. Typical information
available in the frames received, useful for RA validation is: available in the frames received, useful for RA validation, is as
follows:
o Link-layer address of the sender o Link-layer address of the sender
o Port on which the frame was received o Port on which the frame was received
o IP source address o IP source address
o Prefix list o Prefix list
The following configuration information created on the L2-device can The following configuration information created on the L2 device can
be made available to RA-Guard, to validate against the information be made available to RA-Guard, to validate against the information
found in the received RA frame: found in the received RA frame:
o Allowed/Disallowed link-layer address of RA-sender o Allowed/Disallowed link-layer address of the RA sender
o Allowed/Disallowed ports for receiving RAs o Allowed/Disallowed ports for receiving RAs
o Allowed/Disallowed IP source addresses of RA-sender
o Allowed/Disallowed IP source addresses of the RA sender
o Allowed Prefix list and Prefix ranges o Allowed Prefix list and Prefix ranges
o Router Priority o Router Priority
Once the L2 device has validated the content of the RA frame against Once the L2 device has validated the content of the RA frame against
the configuration, it forwards the RA to destination, whether unicast the configuration, it forwards the RA to its destination, whether
or multicast. Otherwise, the RA is dropped. unicast or multicast. Otherwise, the RA is dropped.
An example of a very simple stateless RA-Guard implementation could An example of a very simple stateless RA-Guard implementation could
be a small L2-switch for which there is one interface "statically- be a small L2 switch for which there is one interface "statically
configured" as the interface connecting to a router, while all other configured" as the interface connecting to a router, while all other
interfaces are for non-router devices. With his small static setup interfaces are for non-router devices. With this small static setup,
the only interface forwarding RAs will be the pre-assigned router the only interface forwarding RAs will be the pre-assigned router
interface, while the non-router interfaces block all RAs. interface, while the non-router interfaces block all RAs.
4. Stateful RA-Guard 4. Stateful RA-Guard
4.1. State Machine 4.1. State Machine
Stateful RA-Guard learns dynamically about legitimate RA senders, and Stateful RA-Guard learns dynamically about legitimate RA senders and
store this information for allowing subsequent RAs. A simple stores this information for allowing subsequent RAs. A simple
stateful scheme would be for the L2-device to listen to RAs during a stateful scheme would be for the L2 device to listen to RAs during a
certain manual determined period of time, where the start of the certain manually configured period of time, where the start of the
listening-period and the duration of the listening-period for a listening period and the duration of the listening period for a
single instance is controled by the manual intervention. As result single instance are controlled by the manual intervention. As a
the L2-device can then allow subsequent RAs only on those ports on result, the L2 device can then allow subsequent RAs only on those
which valid RAs were received during this period. Often the LEARNING ports on which valid RAs were received during this period. Often,
state will only be activated by manual configuration when a new IPv6 the "LEARNING" state will only be activated by manual configuration
router is provisioned on the L2-network. when a new IPv6 router is provisioned on the L2 network.
A more sophisticated stateful scheme is based on SEND, and is A more sophisticated stateful scheme is based on SEND and is
described in Section 4.2. described in Section 4.2.
The state machine for stateful RA-Guard can be global, per-interface, The state machine for stateful RA-Guard can be global, per-interface,
or per-peer, depending on the scheme used for authorizing RAs. or per-peer, depending on the scheme used for authorizing RAs.
When RA-Guard is SEND-based, the state machine is per-peer and When RA-Guard is SEND-based, the state machine is per-peer and
defined in [RFC3971]. defined in [RFC3971].
When RA-Guard is using a discovery method, the state-machine of the When RA-Guard is using a discovery method, the state machine of the
RA-Guard capability consists of four different states: RA-Guard capability consists of four different states:
o State 1: OFF o State 1: OFF
A device or interface in RA-Guard "OFF" state, operates as if
the RA-Guard capability is not available. A device or interface in the RA-Guard "OFF" state operates as if
the RA-Guard capability is not available.
o State 2: LEARNING o State 2: LEARNING
A device or interface in the RA-Guard "Learning" state is
actively acquiring information about the IPv6 routing devices A device or interface in the RA-Guard "LEARNING" state is actively
connected. The learning process takes place over a pre-defined acquiring information about the IPv6 routing devices connected to
unique period in time, set by manual configuration or it can be its interfaces. The learning process takes place over a
event triggered. The information gathered is compared against pre-defined unique period of time, as set by manual configuration;
pre-defined criteria; criteria similar as the stateless RA- or it can be event-triggered. The information gathered is
Guard rules to qualify the validity of the RAs. compared against pre-defined criteria (criteria similar to the
In this state, the RA-Guard enabled device or interface is stateless RA-Guard rules) to qualify the validity of the RAs.
either blocking "all" RAs until their validity is verified or,
alternatively it can temporarily forward "all" the RAs until In this state, the RA-Guard-enabled device or interface is either
their validity is verified. blocking "all" RAs until their validity is verified or,
Once the L2-device has identified through "Learning" the valid alternatively, it can temporarily forward "all" of the RAs until
IPv6 routers and hence also identified the valid RAs, it their validity is verified.
transtions each interface from "LEARNING" into either BLOCKING
state if there was no valid IPv6 router discovered at the When the L2 device reaches the end of the LEARNING state, it has a
interface, or transitions the interface into FORWARDING state record of which interfaces are attached to links with valid IPv6
if there was a valid IPv6 router discovered. routers. The L2 device transitions each interface from the
LEARNING state into either the BLOCKING state if there was no
valid IPv6 router discovered at the interface, or into the
FORWARDING state if there was a valid IPv6 router discovered.
o State 3: BLOCKING o State 3: BLOCKING
A device or interface running RA-Guard and in Blocking state
will block ingress RA-messages. A device or interface running RA-Guard and in the BLOCKING state
An interface can transition from BLOCKING state into FORWARDING will block ingress RA messages.
state directly if explicitly instructed by the L2-device
operator. An interface can transition from the BLOCKING state into the
An interface can transition from BLOCKING state into LEARNING FORWARDING state directly if explicitly instructed by the
state if either explicitly told by the L2-device operator or by L2-device operator.
a triggered event.
An interface can transition from the BLOCKING state into the
LEARNING state if either explicitly instructed by the L2-device
operator or prompted by a triggered event.
o State 4: FORWARDING o State 4: FORWARDING
A device or interface running RA-Guard and in Forwarding state
will accept valid ingress RAs and forward them to their A device or interface running RA-Guard and in the FORWARDING state
destination. will accept valid ingress RAs and forward them to their
An interface can transition from FORWARDING state into BLOCKING destination.
state directly if explicitly instructed by the L2-device
operator. An interface can transition from the FORWARDING state into the
An interface can transition from FORWARDING state into LEARNING BLOCKING state directly if explicitly instructed by the L2-device
state if either explicitly told by the L2-device operator or by operator.
a triggered event.
An interface can transition from the FORWARDING state into the
LEARNING state if either explicitly instructed by the L2-device
operator or prompted by a triggered event.
The transition between these states can be triggered by manual The transition between these states can be triggered by manual
configuration or by meeting a pre-defined criteria. configuration or by meeting a pre-defined criterion.
4.2. SEND-based RA-Guard 4.2. SEND-Based RA-Guard
In this scenario, the L2 device is blocking or forwarding RAs based In this scenario, the L2 device is blocking or forwarding RAs based
on SEND considerations. Upon capturing an RA on the interface, the on SEND considerations. Upon capturing an RA on the interface, the
L2-device will first verify the Cryptographically Generated Addresses L2 device will first verify the Cryptographically Generated Address
(CGA) [RFC3971] address and the RSA (Rivest, Shamir and Adleman (CGA) [RFC3971] and the RSA (Rivest, Shamir, and Adleman algorithm
algorithm for public-key cryptography) signature, as specified in for public-key cryptography) signature, as specified in Section 5 of
section 5 of [RFC3971]. RA should be dropped in case of failure of [RFC3971]. The RA should be dropped in case of failure of this
this verification. It will then apply host behavior as described in verification. It will then apply host behavior as described in
section 6.4.6 of [RFC3971]. In particular, the L2 device will Section 6.4.6 of [RFC3971]. In particular, the L2 device will
attempt to retrieve a valid certificate from its cache for the public attempt to retrieve a valid certificate from its cache for the public
key referred to in the RA. If such certificate is found, the L2 key referred to in the RA. If such a certificate is found, the L2
device will forward the RA to destination. If not, the L2 device device will forward the RA to its destination. If not, the L2 device
will generate a Certification Path Solicitation (CPS) [RFC3971], will generate a Certification Path Solicitation (CPS) [RFC3971] with
sourced with UNSPECIFIED address, to query the router certificate(s). an unspecified source address, to query the router certificate(s).
It will then capture the Certification Path Advertisements (CPA) It will then capture the Certification Path Advertisement (CPA)
[RFC3971], and attempt to validate the certificate chain. Failure to [RFC3971] and attempt to validate the certificate chain. Failure to
validate the chain will result in dropping the RA. Upon validation validate the chain will result in dropping the RA. Upon validation
success, the L2 device will forward the RA to destination and and success, the L2 device will forward the RA to its destination and
store the router certificate in its cache. store the router certificate in its cache.
In order to operate in this scenario, the L2-device should be In order to operate in this scenario, the L2 device should be
provisioned with a trust anchor certificate, as specified in section provisioned with a trust anchor certificate, as specified in
6 of [RFC3971]. It may also establish a layer-3 connectivity with a Section 6 of [RFC3971]. It may also establish layer-3 connectivity
Certificate Revocation List (CRL) Certification Path Advertisement with a Certificate Revocation List (CRL) Certification Path
server and/or with and NTP server. Bootstrapping issue in this case Advertisement server and/or with an NTP server. A bootstrapping
can be resolved by using the configuration method to specify a issue in this case can be resolved by using the configuration method
trusted port to a first router, and SEND-based RA-Guard method on all to specify a trusted port to a first router, and the SEND-based
other ports. The first router can then be used for Network Time RA-Guard method on all other ports. The first router can then be
Protocol (NTP) [RFC5905] and CRL connectivity. used for Network Time Protocol (NTP) [RFC5905] and CRL connectivity.
5. RA-Guard Use Considerations 5. RA-Guard Use Considerations
The RA-Guard mechanism is effective only when all messages between The RA-Guard mechanism is effective only when all messages between
IPv6 devices in the target environment traverse controlled L2 IPv6 devices in the target environment traverse controlled L2
networking devices. In the case of environments such as Ethernet networking devices. In the case of environments such as Ethernet
hubs, devices can communicate directly without going through an RA- hubs, devices can communicate directly without going through an
Guard capable L2 networking device, the RA-Guard feature cannot RA-Guard-capable L2 networking device, and the RA-Guard feature
protect against rogue-RAs. cannot protect against rogue RAs.
RA-Guard mechanisms do not offer protection in environments where RA-Guard mechanisms do not offer protection in environments where
IPv6 traffic is tunneled. IPv6 traffic is tunneled.
6. IANA Considerations 6. Security Considerations
There are no extra IANA consideration for this document.
7. Security Considerations
Once RA-Guard has setup the proper criteria, for example, it Once RA-Guard has set up the proper criteria (for example, it
identified that a port is allowed to receive RAs, or it identified specified that a port is allowed to receive RAs, or it identified
legitimate sources of RA, or certificate base [RFC4861], then there legitimate sources of RAs or certificate bases [RFC4861]), then there
is no possible instances of accidently filtered legitimate Router are no possible instances of accidentally filtered legitimate Router
advertisements assuming the RA-Guard filter enforcement follows Advertisements, assuming the RA-Guard filter enforcement strictly
strictly the RA-Guard set criteria. follows the RA-Guard set criteria.
in Section 4.1 a simple mechanism to learn dynamical the valid IPv6 In Section 4.1, a simple mechanism to dynamically learn the valid
routers connected to a L2-device is explained. It is important that IPv6 routers connected to an L2 device is explained. It is important
this LEARN state is only entered intentionally by manual that this LEARNING state is only entered intentionally by manual
configuration. The list of learned IPv6 routers should be verified configuration. The list of learned IPv6 routers should be verified
by the network manager to make sure that it corresponds with the by the network manager to make sure that it corresponds with the
expected valid RA list. This procedure will make sure that either expected valid RA list. This procedure will make sure that either
accidently or intentionally rogue RAs are blocked by RA-guard. accidentally or intentionally generated rogue RAs are blocked by
RA-Guard.
8. Acknowledgements 7. Acknowledgements
The authors dedicate this document to the memory of Jun-ichiro Hagino The authors dedicate this document to the memory of Jun-ichiro Hagino
(itojun) for his contributions to the development and deployment of (itojun) for his contributions to the development and deployment of
IPv6. IPv6.
9. References 8. References
9.1. Normative References
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 8.1. Normative References
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
September 2007.
[RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
Nicholas, "Internet X.509 Public Key Infrastructure: "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
Certification Path Building", RFC 4158, September 2005. September 2007.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
9.2. Informative References 8.2. Informative References
[reference1] [NDPMON] LORIA/INRIA, "NDPMon - IPv6 Neighbor Discovery Protocol
LORIA/INRIA, "NDPMon - IPv6 Neighbor Discovery Protocol Monitor", November 2007,
Monitor (http://ndpmon.sourceforge.net/)", November 2007. <http://ndpmon.sourceforge.net/>.
[reference2] [KAME] KAME Project, "rafixd - developed at KAME - An active
KAME Project, "rafixd - developed at KAME - An active rogue RA nullifier", November 2007,
rogue RA nullifier (http://www.kame.net/dev/cvsweb2.cgi/ <http://www.kame.net/>.
kame/kame/kame/rafixd/)", November 2007.
[reference3] [IPv6-SAMURAIS]
Hagino (itojun), Jun-ichiro., "Discussion of the various Hagino (itojun), J., "IPv6 demystified: I have a problem
solutions (http://ipv6samurais.com/ipv6samurais/ with rogue RAs in my IPv6 network", 2007,
demystified/rogue-RA.html)", 2007. <http://ipv6samurais.com/>.
[reference4] [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement
Chown, Tim. and Stig. Venaas, "Rogue IPv6 Router Problem Statement", RFC 6104, February 2011.
Advertisement Problem (draft-ietf-v6ops-rogue-ra-00.txt)",
May 2009.
Authors' Addresses Authors' Addresses
Eric Levy Abegnoli Eric Levy-Abegnoli
Cisco Systems Cisco Systems
Village d'Entreprises Green Side - 400, Avenue Roumanille Village d'Entreprises Green Side - 400, Avenue Roumanille
Biot - Sophia Antipolis, PROVENCE-ALPES-COTE D'AZUR 06410 Biot - Sophia Antipolis, PROVENCE-ALPES-COTE D'AZUR 06410
France France
Phone: +33 49 723 2620 Phone: +33 49 723 2620
Email: elevyabe@cisco.com EMail: elevyabe@cisco.com
Gunter Van de Velde Gunter Van de Velde
Cisco Systems Cisco Systems
De Kleetlaan 6a De Kleetlaan 6a
Diegem 1831 Diegem 1831
Belgium Belgium
Phone: +32 2704 5473 Phone: +32 2704 5473
Email: gunter@cisco.com EMail: gunter@cisco.com
Ciprian Popoviciu Ciprian Popoviciu
Cisco Systems Technodyne
7025-6 Kit Creek Road 111 Wood Ave. S.
Research Triangle Park, North Carolina NC 27709-4987 Iselin, NJ 08830
USA USA
Phone: +1 919 392-3723 Phone: +1 1 919 599-5666
Email: cpopovic@cisco.com EMail: chip@technodyne.com
Janos Mohacsi Janos Mohacsi
NIIF/Hungarnet NIIF/Hungarnet
18-22 Victor Hugo 18-22 Victor Hugo
Budapest H-1132 Budapest H-1132
Hungary Hungary
Phone: tbc EMail: mohacsi@niif.hu
Email: mohacsi@niif.hu
 End of changes. 70 change blocks. 
229 lines changed or deleted 239 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/