draft-ietf-v6ops-ra-guard-06.txt   draft-ietf-v6ops-ra-guard-07.txt 
v6ops Working Group E. Levy-Abegnoli v6ops Working Group E. Levy-Abegnoli
Internet-Draft G. Van de Velde Internet-Draft G. Van de Velde
Intended status: Informational C. Popoviciu Intended status: Informational C. Popoviciu
Expires: December 19, 2010 Cisco Systems Expires: March 6, 2011 Cisco Systems
J. Mohacsi J. Mohacsi
NIIF/Hungarnet NIIF/Hungarnet
June 17, 2010 September 02, 2010
IPv6 RA-Guard IPv6 Router Advertisement Guard
<draft-ietf-v6ops-ra-guard-06.txt> <draft-ietf-v6ops-ra-guard-07.txt>
Abstract Abstract
It is particularly easy to experience "rogue" routers on an unsecured
link [reference4]. Devices acting as a rogue router may send
illegitimate RAs. Section 6 of SeND [RFC3971] provides a full
solution to this problem, by enabling routers certification. This
solution does, however, require all nodes on an L2 network segment to
support SeND, as well as it carries some deployment challenges. End-
nodes must be provisioned with certificate anchors. The solution
works better when end-nodes have access to a Certificate Revocation
List server, and to a Network Time Protocol server, both typically
off-link, which brings some bootstrap issues.
When using IPv6 within a single L2 network segment it is possible and When using IPv6 within a single L2 network segment it is possible and
sometimes desirable to enable layer 2 devices to drop rogue RAs sometimes desirable to enable layer 2 devices to drop rogue RAs
before they reach end-nodes. In order to distinguish valid from before they reach end-nodes. In order to distinguish valid from
rogue RAs, the L2 devices can use a spectrum of criteria, from a rogue RAs, the L2 devices can use a spectrum of criteria, from a
static scheme that blocks RAs received on un-trusted ports, or from static scheme that blocks RAs received on un-trusted ports, or from
un-trusted sources, to a more dynamic scheme that uses SeND to un-trusted sources, to a more dynamic scheme that uses Secure
challenge RA sources. Neighbor Discovery (SEND) to challenge RA sources.
This document reviews various techniques applicable on the L2 devices This document reviews various techniques applicable on the L2 devices
to reduce the threat of rogue RAs. to reduce the threat of rogue RAs.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 19, 2010. This Internet-Draft will expire on March 6, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 3, line 7 skipping to change at page 3, line 7
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Model and Applicability . . . . . . . . . . . . . . . . . . . . 4 2. Model and Applicability . . . . . . . . . . . . . . . . . . . 4
3. Stateless RA-Guard . . . . . . . . . . . . . . . . . . . . . . 6 3. Stateless RA-Guard . . . . . . . . . . . . . . . . . . . . . . 6
4. Stateful RA-Guard . . . . . . . . . . . . . . . . . . . . . . . 6 4. Stateful RA-Guard . . . . . . . . . . . . . . . . . . . . . . 6
4.1. State Machine . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. State Machine . . . . . . . . . . . . . . . . . . . . . . 7
4.2. SeND-based RA-Guard . . . . . . . . . . . . . . . . . . . . 7 4.2. SEND-based RA-Guard . . . . . . . . . . . . . . . . . . . 8
5. RA-Guard Use Considerations . . . . . . . . . . . . . . . . . . 8 5. RA-Guard Use Considerations . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
When operating IPv6 in a shared L2 network segment without complete When operating IPv6 in a shared L2 network segment without complete
SeND support by all devices connected or without the availability of SEND support by all devices connected or without the availability of
the infrastructure necessary to support SeND, there is always the the infrastructure necessary to support Secure Neighbor Discovery
risk of facing operational problems due to rogue Router (SEND) [RFC3971], there is always the risk of facing operational
Advertisements generated maliciously or unintentionally by problems due to rogue Router Advertisements generated maliciously or
unauthorized or improperly configured routers connecting to the unintentionally by unauthorized or improperly configured routers
segment. 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 which resulted
in several related studies [reference1] [reference2] in several related studies [reference1] [reference2]
[reference3].This document describes a solution framework for the [reference3].This document describes a solution framework for the
rogue-RA problem where network segments are designed around a single rogue-RA problem where network segments are designed around a single
or a set of L2-switching devices capable of identifying invalid RAs or a set of L2-switching devices capable of identifying invalid RAs
and blocking them. The solutions developed within this framework can and blocking them. The solutions developed within this framework can
span the spectrum from basic (where the port of the L2 device is span the spectrum from basic (where the port of the L2 device is
statically instructed to forward or not to forward RAs received from statically instructed to forward or not to forward RAs received from
the connected device) to advanced (where a criteria is used by the L2 the connected device) to advanced (where a criteria is used by the L2
device to dynamically validate or invalidate a received RA, this device to dynamically validate or invalidate a received RA, this
criteria can even be based on SeND mechanisms). criteria 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 such as an Ethernet hub, when devices can not apply to a shared media such as an Ethernet hub, when devices can
communicate directly without going through an RA-Guard capable L2 communicate directly without going through an RA-Guard capable L2
networking device. 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 |
| | | |
+-------+ +-------+
RA-Guard does not intend to provide a substitute for SeND based Figure 1
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 anchors.
It is also reasonable to expect that some devices might not consider It is also reasonable to expect that some devices might not consider
implementing SeND at all such as IPv6 enabled sensors. An RA-Guard implementing SEND at all such as IPv6 enabled sensors. An RA-Guard
implementation which SeND-validates RAs on behalf of hosts would implementation which SEND-validates RAs on behalf of hosts would
potentially simplify some of these challenges. 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 full
fledge SeND "RA allowed from authorized sources only". fledge 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. If SEND is enabled, the RA is checked against X.509 certificates
any other criteria is in use, such as known L3 (addresses) or L2 [RFC4861]. If any other criteria is in use, such as known L3
(link-layer address, port number) legitimate sources of RAs, the (addresses) or L2 (link-layer address, port number) legitimate
node-in-the middle can use this criteria and filter out any RA that sources of RAs, the node-in-the middle can use this criteria and
does not comply. If this node-in-the-middle is a L2 device, it will filter out any RA that does not comply. If this node-in-the-middle
not change the content of the validated RA, and avoid any of the nd- is a L2 device, it will not change the content of the validated RA,
proxy pitfalls. and 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 an
context environment consisting of with a mix of SeND capable devices context environment consisting of with a mix of SEND capable devices
(L2 switches and routers) and devices that do not consistently use (L2 switches and routers) and devices that do not consistently use
SeND. Furthermore, RA-Guard is useful to simplify SeND deployments, SEND. Furthermore, RA-Guard is useful to simplify SEND deployments,
as only the L2 switch and the routers are required to carry as only the L2 switch and the routers are required to carry
certificates (their own and the trust anchor certificates). 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 decide 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:
skipping to change at page 6, line 39 skipping to change at page 6, line 40
o Allowed/Disallowed link-layer address of RA-sender o Allowed/Disallowed link-layer address of 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 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 destination, whether unicast
or multicast. Otherwise, the RA is dropped. or multicast. Otherwise, the RA is dropped.
4. Stateful RA-Guard An example of a very simple stateless RA-Guard implementation could
be a small L2-switch for which there is one interface "statically-
configured" as the interface connecting to a router, while all other
interfaces are for non-router devices. With his small static setup
the only interface forwarding RAs will be the pre-assigned router
interface, while the non-router interfaces block all RAs.
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 store 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 period of time, then to allow subsequent RAs only on those certain manual determined period of time, where the start of the
ports on which valid RAs were received during this period. A more listening-period and the duration of the listening-period for a
sophisticated stateful scheme is based on SeND, and is described in single instance is controled by the manual intervention. As result
Section 4.2. the L2-device can then allow subsequent RAs only on those ports on
which valid RAs were received during this period. Often the LEARNING
state will only be activated by manual configuration when a new IPv6
router is provisioned on the L2-network.
A more sophisticated stateful scheme is based on SEND, and is
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 A device or interface in RA-Guard "OFF" state, operates as if
the RA-Guard capability is not available. 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 A device or interface in the RA-Guard "Learning" state is
actively acquiring information about the devices connected to actively acquiring information about the IPv6 routing devices
its interfaces. The learning process takes place over a pre- connected. The learning process takes place over a pre-defined
defined period of time by capturing router advertisements or it unique period in time, set by manual configuration or it can be
can be event triggered. The information gathered is compared event triggered. The information gathered is compared against
against pre-defined criteria which qualify the validity of the pre-defined criteria; criteria similar as the stateless RA-
RAs. Guard rules to qualify the validity of the RAs.
In this state, the RA-Guard enabled device or interface is In this state, the RA-Guard enabled device or interface is
either blocking all RAs until their validity is verified or, either blocking "all" RAs until their validity is verified or,
alternatively it can temporarily forward the RAs until the alternatively it can temporarily forward "all" the RAs until
decision is being made. their validity is verified.
Once the L2-device has identified through "Learning" the valid
IPv6 routers and hence also identified the valid RAs, it
transtions each interface from "LEARNING" into either BLOCKING
state if there was no valid IPv6 router discovered at the
interface, or transitions the interface into 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 A device or interface running RA-Guard and in Blocking state
will block ingress RA-messages. will block ingress RA-messages.
An interface can transition from BLOCKING state into FORWARDING
state directly if explicitly instructed by the L2-device
operator.
An interface can transition from BLOCKING state into LEARNING
state if either explicitly told by the L2-device operator or by
a triggered event.
o State 4: FORWARDING o State 4: FORWARDING
A device or interface running RA-Guard and in Forwarding state A device or interface running RA-Guard and in Forwarding state
will accept ingress RAs and forward them to their destination/ will accept valid ingress RAs and forward them to their
destination.
An interface can transition from FORWARDING state into BLOCKING
state directly if explicitly instructed by the L2-device
operator.
An interface can transition from FORWARDING state into LEARNING
state if either explicitly told by the L2-device operator or 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 criteria.
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 CGA address and the RSA signature, as L2-device will first verify the Cryptographically Generated Addresses
specified in section 5 of [RFC3971]. RA should be dropped in case of (CGA) [RFC3971] address and the RSA (Rivest, Shamir and Adleman
failure of this verification. It will then apply host behavior as algorithm for public-key cryptography) signature, as specified in
described in section 6.4.6 of [RFC3971]. In particular, the L2 section 5 of [RFC3971]. RA should be dropped in case of failure of
device will attempt to retrieve a valid certificate from its cache this verification. It will then apply host behavior as described in
for the public key referred to in the RA. If such certificate is section 6.4.6 of [RFC3971]. In particular, the L2 device will
found, the L2 device will forward the RA to destination. If not, the attempt to retrieve a valid certificate from its cache for the public
L2 device will generate a CPS, sourced with UNSPECIFIED address, to key referred to in the RA. If such certificate is found, the L2
query the router certificate(s). It will then capture the CPA(s), device will forward the RA to destination. If not, the L2 device
and attempt to validate the certificate chain. Failure to validate will generate a Certification Path Solicitation (CPS) [RFC3971],
the chain will result in dropping the RA. Upon validation success, sourced with UNSPECIFIED address, to query the router certificate(s).
the L2 device will forward the RA to destination and and store the It will then capture the Certification Path Advertisements (CPA)
router certificate in its cache. [RFC3971], and attempt to validate the certificate chain. Failure to
validate the chain will result in dropping the RA. Upon validation
success, the L2 device will forward the RA to destination and and
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 section
6 of [RFC3971]. It may also establish a layer-3 connectivity with a 6 of [RFC3971]. It may also establish a layer-3 connectivity with a
CRL server and/or with and NTP server. Bootstrapping issue in this Certificate Revocation List (CRL) Certification Path Advertisement
case can be resolved by using the configuration method to specify a server and/or with and NTP server. Bootstrapping issue in this case
trusted port to a first router, and send-based-ra-guard method on all can be resolved by using the configuration method to specify a
other ports. The first router can then be used for NTP and CRL trusted port to a first router, and SEND-based RA-Guard method on all
connectivity. other ports. The first router can then be 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 RA-
Guard capable L2 networking device, the RA-Guard feature cannot Guard capable L2 networking device, the RA-Guard feature cannot
protect against rogue-RAs. protect against rogue-RAs.
skipping to change at page 8, line 38 skipping to change at page 9, line 30
IPv6 traffic is tunneled. IPv6 traffic is tunneled.
6. IANA Considerations 6. IANA Considerations
There are no extra IANA consideration for this document. There are no extra IANA consideration for this document.
7. Security Considerations 7. Security Considerations
Once RA-Guard has setup the proper criteria, for example, it Once RA-Guard has setup the proper criteria, for example, it
identified that a port is allowed to receive RAs, or it identified identified that a port is allowed to receive RAs, or it identified
legitimate sources of RA, or certificate base, then there is no legitimate sources of RA, or certificate base [RFC4861], then there
possible instances of accidentlly filtered legitimate RA's assuming is no possible instances of accidently filtered legitimate Router
the RA-Guard filter enforcement follows strictly the RA-Guard advertisements assuming the RA-Guard filter enforcement follows
criteria's. strictly the RA-Guard set criteria.
in Section 4.1 a simple mechanism to learn dynamical the valid IPv6
routers connected to a L2-device is explained. It is important that
this LEARN state is only entered intentionally by manual
configuration. The list of learned IPv6 routers should be verified
by the network manager to make sure that it corresponds with the
expected valid RA list. This procedure will make sure that either
accidently or intentionally rogue RAs are blocked by RA-guard.
8. Acknowledgements 8. 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 9. References
9.1. Normative References 9.1. Normative References
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
Nicholas, "Internet X.509 Public Key Infrastructure:
Certification Path Building", RFC 4158, September 2005.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010.
9.2. Informative References 9.2. Informative References
[reference1] [reference1]
LORIA/INRIA, "NDPMon - IPv6 Neighbor Discovery Protocol LORIA/INRIA, "NDPMon - IPv6 Neighbor Discovery Protocol
Monitor (http://ndpmon.sourceforge.net/)", November 2007. Monitor (http://ndpmon.sourceforge.net/)", November 2007.
[reference2] [reference2]
KAME Project, "rafixd - developed at KAME - An active KAME Project, "rafixd - developed at KAME - An active
rogue RA nullifier (http://www.kame.net/dev/cvsweb2.cgi/ rogue RA nullifier (http://www.kame.net/dev/cvsweb2.cgi/
kame/kame/kame/rafixd/)", November 2007. kame/kame/kame/rafixd/)", November 2007.
 End of changes. 29 change blocks. 
111 lines changed or deleted 157 lines changed or added

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