draft-ietf-dna-simple-02.txt   draft-ietf-dna-simple-03.txt 
Network Working Group S. Krishnan Network Working Group S. Krishnan
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track G. Daley Updates: 4861 (if approved) G. Daley
Expires: January 11, 2009 NetStar Networks Intended status: Standards Track NetStar Networks
July 10, 2008 Expires: April 6, 2009 October 3, 2008
Simple procedures for Detecting Network Attachment in IPv6 Simple procedures for Detecting Network Attachment in IPv6
draft-ietf-dna-simple-02 draft-ietf-dna-simple-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 11, 2009. This Internet-Draft will expire on April 6, 2009.
Abstract Abstract
Detecting Network Attachment allows hosts to assess if its existing Detecting Network Attachment allows hosts to assess if its existing
addressing or routing configuration is valid for a newly connected addressing or routing configuration is valid for a newly connected
network. network.
This document provides simple procedures for detecting network This document provides simple procedures for detecting network
attachment in IPv6 hosts, and procedures for routers to support such attachment in IPv6 hosts, and procedures for routers to support such
services. services.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. DNA Roles . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. DNA Roles . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Working Assumptions . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 5 4. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Host data structures . . . . . . . . . . . . . . . . . . . 5 4.1. Host data structures . . . . . . . . . . . . . . . . . . . 5
4.2. Steps involved in detecting link change . . . . . . . . . 5 4.2. Steps involved in detecting link change . . . . . . . . . 6
4.3. Link-Layer Indication . . . . . . . . . . . . . . . . . . 5 4.3. Link-Layer Indication . . . . . . . . . . . . . . . . . . 6
4.4. Sending RS and NS probes . . . . . . . . . . . . . . . . . 6 4.4. Sending RS and NS probes . . . . . . . . . . . . . . . . . 6
4.5. Response Gathering . . . . . . . . . . . . . . . . . . . . 7 4.5. Response Gathering . . . . . . . . . . . . . . . . . . . . 7
4.6. Further Host Operations . . . . . . . . . . . . . . . . . 7 4.6. Further Host Operations . . . . . . . . . . . . . . . . . 8
4.7. Recommended retransmission behavior . . . . . . . . . . . 8 4.7. Recommended retransmission behavior . . . . . . . . . . . 8
5. Router Operations . . . . . . . . . . . . . . . . . . . . . . 9 5. Router Operations . . . . . . . . . . . . . . . . . . . . . . 9
6. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Pseudocode for Simple DNA . . . . . . . . . . . . . . . . . . 10
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 12 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 12.2. Informative References . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
Hosts require procedures to simply and reliably identify if they have Hosts require procedures to simply and reliably identify if they have
moved to a different IP network to the one which they have been moved to a different IP network to the one which they have been
recently connected. In order to detect change, router and neighbour recently connected. In order to detect change, router and neighbour
discovery messages are used to collect reachability and configuration discovery messages are used to collect reachability and configuration
information. This information is used to detect whether the existing information. This information is used to detect whether the existing
router and address prefixes are likely to be present. router and address prefixes are likely to be present.
This document incorporates feedback from host and router operating This document incorporates feedback from host and router operating
systems implementors, which seeks to make implementation and adoption systems implementors, which seeks to make implementation and adoption
of IPv6 change detection procedures simple for general use. of IPv6 change detection procedures simple for general use.
2.1. Goals
The goal of this document is to specify a simple procedure for The goal of this document is to specify a simple procedure for
detecting network attachment (Simple DNA) that has the following detecting network attachment (Simple DNA) that has the following
characteristics. characteristics.
o Routers do not have to be modified to support this scheme. o Routers do not have to be modified to support this scheme.
o Handle only the simplest and most likely use cases. o Handle only the simplest and most likely use cases.
o Work at least as quickly as standard neighbor discovery. o Work at least as quickly as standard neighbor discovery.
o False positives are not acceptable. A host should not conclude o False positives are not acceptable. A host should not conclude
that there is no link change when there is one. that there is no link change when there is one.
o False negatives are acceptable. A host can conclude that there is o False negatives are acceptable. A host can conclude that there is
a link change when there is none. a link change when there is none.
2.1. DNA Roles 2.2. Applicability
The Simple DNA protocol is provides substantial benefits in some
scenarios and does not provide any benefit at all in certain other
scenarios. This is intentional as Simple DNA was designed for
simplicity rather than completeness. In particular, the Simple DNA
protocol provides maximum benefits when a host moves between a small
set of known links. When a host moves to a completely new link that
is previously unknown, the performance of the Simple DNA protocol
will be identical to that using standard neighbor discovery
procedures [RFC4861].
2.3. DNA Roles
Detecting Network Attachment is performed by hosts by sending IPv6 Detecting Network Attachment is performed by hosts by sending IPv6
neighbour discovery and router discovery messages to routers after neighbour discovery and router discovery messages to routers after
connecting to a network. connecting to a network.
It is desirable that routers adopt procedures which allow for fast It is desirable that routers adopt procedures which allow for fast
unicast Router Advertisement (RA) messages. Routers that follow the unicast Router Advertisement (RA) messages. Routers that follow the
standard neighbor discovery procedure described in [RFC4861] will standard neighbor discovery procedure described in [RFC4861] will
delay the router advertisement by a random period between 0 and delay the router advertisement by a random period between 0 and
MAX_RA_DELAY_TIME (defined to be 500ms) as described in Section 6.2.6 MAX_RA_DELAY_TIME (defined to be 500ms) as described in Section 6.2.6
skipping to change at page 4, line 15 skipping to change at page 4, line 29
not necessary since the simple dna procedure can continue to work not necessary since the simple dna procedure can continue to work
using the NS/NA exchange, which will complete earlier than the RA using the NS/NA exchange, which will complete earlier than the RA
arrives. arrives.
The host detects that the link-layer may have changed, and then The host detects that the link-layer may have changed, and then
simultaneously probes the network with Router Solicitations (RSs) and simultaneously probes the network with Router Solicitations (RSs) and
Neighbour Solicitations (NSs). The host uses advertisements to Neighbour Solicitations (NSs). The host uses advertisements to
determine if the routers it currently has configured are still determine if the routers it currently has configured are still
available. available.
2.2. Applicability 2.4. Working Assumptions
There are a series of assumptions about the network environment which There are a series of assumptions about the network environment which
underpin these procedures. underpin these procedures.
o The combination of the link layer address and the link local IPv6 o The combination of the link layer address and the link local IPv6
address of a router is unique across links. address of a router is unique across links.
o Hosts receive indications when a link-layer comes up. Without o Hosts receive indications when a link-layer comes up. Without
this, they would not know when to commence the DNA procedure. this, they would not know when to commence the DNA procedure.
skipping to change at page 6, line 30 skipping to change at page 6, line 47
[RFC4861]. Even if the host is in possession of more than one valid [RFC4861]. Even if the host is in possession of more than one valid
IPv6 address, it MUST send only one router solicitation using a valid IPv6 address, it MUST send only one router solicitation using a valid
link-local address as the source address. link-local address as the source address.
For the purpose of sending neighbor solicitations to previous For the purpose of sending neighbor solicitations to previous
routers, the host first needs to pick a subset of operable IPv6 routers, the host first needs to pick a subset of operable IPv6
addresses (candidate set) that it wishes to use. How this subset of addresses (candidate set) that it wishes to use. How this subset of
addresses is picked is based on host configuration. e.g. The host addresses is picked is based on host configuration. e.g. The host
may select configured addresses from each of zero, one or two may select configured addresses from each of zero, one or two
previously connected links. If the addresses obtained from a previously connected links. If the addresses obtained from a
previous router are no longer valid, the host does include these previous router are no longer valid, the host does not include these
addresses in the candidate set for NS based probing. addresses in the candidate set for NS based probing.
For each of the addresses in the candidate set, the host looks up the For each of the addresses in the candidate set, the host looks up the
SDAT to find out the link-local and MAC addresses of the router that SDAT to find out the link-local and MAC addresses of the router that
advertised the prefix used to form the address. It then sends an advertised the prefix used to form the address. It then sends an
unicast Neighbor Solicitations to each router's link-local address it unicast Neighbor Solicitations to each router's link-local address it
obtained from the lookup on the SDAT. The host SHOULD NOT send obtained from the lookup on the SDAT. The host SHOULD NOT send
unicast Neighbor Solicitations to a test node corresponding to an unicast Neighbor Solicitations to a test node corresponding to an
IPv6 address that is no longer valid. IPv6 address that is no longer valid.
Please note that the Neighbour Solicitations SHOULD be sent in Please note that the Neighbour Solicitations SHOULD be sent in
parallel with the Router Solicitations. Since sending NSs is just an parallel with the Router Solicitations. Since sending NSs is just an
optimization, doing the NSs and RSs in parallel ensures that the optimization, doing the NSs and RSs in parallel ensures that the
procedure does not run slower than it would if it only used an RS. procedure does not run slower than it would if it only used an RS.
Be aware that each unicast solicitation which is not successful may Be aware that each unicast solicitation which is not successful may
cause packet flooding in bridged networks, if the networks are not cause packet flooding in bridged networks, if the networks are not
properly configured. This is further described in Section 7. Where properly configured. This is further described in Section 8. Where
flooding may cause performance issues within the LAN, host SHOULD flooding may cause performance issues within the LAN, host SHOULD
limit the number of unicast solicitations. limit the number of unicast solicitations.
4.5. Response Gathering 4.5. Response Gathering
When a responding Neighbour Advertisement is received from a test When a responding Neighbour Advertisement is received from a test
node, the host MUST verify that both the IPv6 and link layer (MAC) node, the host MUST verify that both the IPv6 and link layer (MAC)
addresses of the test node match the expected values before utilizing addresses of the test node match the expected values before utilizing
the configuration associated with the detected network (prefixes, MTU the configuration associated with the detected network (prefixes, MTU
etc.). etc.).
skipping to change at page 9, line 15 skipping to change at page 10, line 5
5. Router Operations 5. Router Operations
Hosts checking their network attachment are unsure of their address Hosts checking their network attachment are unsure of their address
status, and may be using Tentative link-layer addressing information status, and may be using Tentative link-layer addressing information
in their router or neighbour solicitations. in their router or neighbour solicitations.
A router which desires to support hosts' DNA operations MUST process A router which desires to support hosts' DNA operations MUST process
Tentative Options from unicast source addressed Router and Neighbour Tentative Options from unicast source addressed Router and Neighbour
Solicitations, as described in [I-D.ietf-dna-tentative]. Solicitations, as described in [I-D.ietf-dna-tentative].
6. Constants 6. Pseudocode for Simple DNA
/* Link up indication received on INTERFACE */
/* Start Simple DNA process */
/* Mark All Addresses as deprecated */
Configured_Address_List=Get_Address_List(INTERFACE);
foreach Configured_Address in Configured_Address_List
{
if (Get_Address_State(Configured_Address)!=AS_TENTATIVE)
{
Set_Address_State(Configured_Address,AS_DEPRECATED);
}
}
/* Mark all routers' NC entries as STALE to speed up */
/* acquisition of new router if link change has occurred */
foreach Router_Address in DEFAULT_ROUTER_LIST
{
NCEntry=Get_Neighbor_Cache_Entry(Router_Address);
Set_Neighbor_Cache_Entry_State(NCEntry,NCS_STALE);
}
/* Thread A : Send Router Solicitation */
RS_Target_Address=FF02::2;
RS_Source_Address=Get_Any_Link_Local_Address(INTERFACE);
Send_Router_Solicitation(RS_Source_Address,RS_Target_Address);
/* Thread B : Send Neighbor Solicitation(s) */
Previously_Known_Router_List=Get_Router_List_from_SDAT();
NS_Source_Address=Get_Any_Link_Local_Address(INTERFACE);
foreach Router_Address in Previously_Known_Router_List
{
if (Get_Any_Valid_Address_from_SDAT(Router_Address))
{
Send_Neighbor_Solicitation(NS_Source_Address,Router_Address);
}
}
/* Thread C : Response collection */
/* Received Router Advertisement processing */
/* Only for RAs received as response to DNA RSs */
L3_Source=Get_L3_Source(RECEIVED_MESSAGE);
L2_Source=Get_L2_Source(RECEIVED_MESSAGE);
SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source));
foreach SDAT_Entry in SDAT_Entry_List
{
if (Exists_PIO(RECEIVED_MESSAGE,Get_Prefix(SDAT_Entry)))
{
/* Address is operable. Configure on Interface */
/* Rejoin solicited-node multicast group for address */
}
else
{
/* If address is configured on interface, remove it */
/* This could be because of a NA arriving before RA */
}
}
/* Mark router as reachable */
NCEntry=Get_Neighbor_Cache_Entry(L3_Source);
if (NCEntry is not NULL)
{
Set_Neighbor_Cache_Entry_State(NCEntry,NCS_REACHABLE);
}
else
{
Create_Neighbor_Cache_Entry(L3_Source,NCS_REACHABLE);
}
/* Ignore further NAs from this router */
Add_Router_to_NA_Ignore_List(L3_Source);
/* Received Neighbor Advertisement processing */
/* Only for NAs received as response to DNA NSs */
L3_Source=Get_L3_Source(RECEIVED_MESSAGE);
L2_Source=Get_L2_Source(RECEIVED_MESSAGE);
if (Is_Router_on_NA_Ignore_List(L3_Source)) {
/* Ignore message and wait for next message */
continue;
}
SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source));
foreach SDAT_Entry in SDAT_Entry_List
{
/* Address is operable. Configure on Interface */
}
Figure 1: Pseudocode for Simple DNA
7. Constants
These constants are described as in [I-D.ietf-dna-protocol]. These constants are described as in [I-D.ietf-dna-protocol].
UNICAST_RA_INTERVAL UNICAST_RA_INTERVAL
Definition: The interval corresponding to the maximum average Definition: The interval corresponding to the maximum average
rate of Router Solicitations that the router is prepared to rate of Router Solicitations that the router is prepared to
service with unicast responses. This is the interval at which service with unicast responses. This is the interval at which
the token bucket controlling the unicast responses is the token bucket controlling the unicast responses is
replenished. replenished.
skipping to change at page 9, line 46 skipping to change at page 12, line 36
Value: 20 Value: 20
SEND_NA_GRACE_TIME SEND_NA_GRACE_TIME
Definition: An optional period to wait after Neighbour Definition: An optional period to wait after Neighbour
Solicitation before adopting a non-SEND RA's link change Solicitation before adopting a non-SEND RA's link change
information. information.
Value: 40 milliseconds Value: 40 milliseconds
7. Open Issues 8. Open Issues
This section documents issues that are still outstanding within the This section documents issues that are still outstanding within the
document, and the simple DNA solution in general. document, and the simple DNA solution in general.
Rate limitation for solicitations. Rate limitation for solicitations.
Hosts MAY implement hysteresis mechanisms to pace solicitations Hosts MAY implement hysteresis mechanisms to pace solicitations
where necessary to prevent damage to a particular medium. where necessary to prevent damage to a particular medium.
Implementors should be aware that when such hysteresis is Implementors should be aware that when such hysteresis is
triggered, Detecting Network Attachment may be slowed, which may triggered, Detecting Network Attachment may be slowed, which may
affect application traffic. affect application traffic.
8. IANA Considerations 9. IANA Considerations
There are no changes to IANA registries required in this document. There are no changes to IANA registries required in this document.
9. Security Considerations 10. Security Considerations
When providing fast responses to router solicitations, it is possible When providing fast responses to router solicitations, it is possible
to cause collisions with other signaling packets on contention based to cause collisions with other signaling packets on contention based
media. This can cause repeated packet loss or delay when multiple media. This can cause repeated packet loss or delay when multiple
routers are present on the link. routers are present on the link.
As such the fast router advertisement system is NOT RECOMMENDED in As such the fast router advertisement system is NOT RECOMMENDED in
this form for media which are susceptible to collision loss. Such this form for media which are susceptible to collision loss. Such
environments may be better served using the procedures defined in environments may be better served using the procedures defined in
[I-D.ietf-dna-protocol]. [I-D.ietf-dna-protocol].
skipping to change at page 11, line 10 skipping to change at page 14, line 5
Even if SEND signatures on RAs are used, it may not be immediately Even if SEND signatures on RAs are used, it may not be immediately
clear if the router is authorized to make such advertisements. As clear if the router is authorized to make such advertisements. As
such, a host SHOULD NOT treat such devices as secure until and unless such, a host SHOULD NOT treat such devices as secure until and unless
authorization delegation discovery is successful. authorization delegation discovery is successful.
It is easy for hosts soliciting without SEND to deplete a SEND It is easy for hosts soliciting without SEND to deplete a SEND
router's fast advertisement token buckets, and consume additional router's fast advertisement token buckets, and consume additional
bandwidth. As such, a router MAY choose to preserve a portion of bandwidth. As such, a router MAY choose to preserve a portion of
their token bucket to serve solicitations with SEND signatures. their token bucket to serve solicitations with SEND signatures.
10. Acknowledgments 11. Acknowledgments
This document is the product of a discussion between the authors had This document is the product of a discussion between the authors had
with Bernard Aboba, Thomas Narten, Erik Nordmark and Dave Thaler at with Bernard Aboba, Thomas Narten, Erik Nordmark and Dave Thaler at
IETF 69. The authors would like to thank them for clearly detailing IETF 69. The authors would like to thank them for clearly detailing
the requirements of the solution and the goals it needed to meet and the requirements of the solution and the goals it needed to meet and
for helping to explore the solution space. The authors would like to for helping to explore the solution space. The authors would like to
thank the authors and editors of the complete DNA specification for thank the authors and editors of the complete DNA specification for
detailing the overall problem space and solutions. The authors would detailing the overall problem space and solutions. The authors would
like to thank Jari Arkko for driving the evolution of a simple and like to thank Jari Arkko for driving the evolution of a simple and
probabilistic DNA solution. The authors would like to thank Bernard probabilistic DNA solution. The authors would like to thank Bernard
Aboba, Thomas Narten, Sathya Narayan, Julien Laganier, Domagoj Aboba, Thomas Narten, Sathya Narayan, Julien Laganier, Domagoj
Premec, Jin Hyeock-Choi, Alfred Hoenes and Frederic Rossi for Premec, Jin Hyeock-Choi, Alfred Hoenes and Frederic Rossi for
performing reviews on the document and providing valuable comments to performing reviews on the document and providing valuable comments to
drive the document forward. drive the document forward.
11. References 12. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4861] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 4861,
December 1998.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 12.1. Normative References
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[I-D.ietf-dna-tentative] [I-D.ietf-dna-tentative]
Daley, G., Nordmark, E., and N. Moore, "Tentative Options Daley, G., Nordmark, E., and N. Moore, "Tentative Options
for IPv6 Neighbour Discovery", draft-ietf-dna-tentative-01 for IPv6 Neighbour Discovery", draft-ietf-dna-tentative-01
(work in progress), July 2007. (work in progress), July 2007.
[I-D.ietf-dna-protocol] [I-D.ietf-dna-protocol]
Narayanan, S., "Detecting Network Attachment in IPv6 Narayanan, S., "Detecting Network Attachment in IPv6
Networks (DNAv6)", draft-ietf-dna-protocol (work in Networks (DNAv6)", draft-ietf-dna-protocol (work in
progress), June 2007. progress), June 2007.
11.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
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.
12.2. Informative References
[RFC4957] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S., [RFC4957] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S.,
and A. Yegin, "Link-Layer Event Notifications for and A. Yegin, "Link-Layer Event Notifications for
Detecting Network Attachments", RFC 4957, August 2007. Detecting Network Attachments", RFC 4957, August 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
Authors' Addresses Authors' Addresses
 End of changes. 20 change blocks. 
43 lines changed or deleted 156 lines changed or added

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