draft-ietf-dna-simple-03.txt   draft-ietf-dna-simple-04.txt 
Network Working Group S. Krishnan Network Working Group S. Krishnan
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 4861 (if approved) G. Daley Updates: 4861 (if approved) G. Daley
Intended status: Standards Track NetStar Networks Intended status: Standards Track NetStar Networks
Expires: April 6, 2009 October 3, 2008 Expires: April 30, 2009 October 27, 2008
Simple procedures for Detecting Network Attachment in IPv6 Simple procedures for Detecting Network Attachment in IPv6
draft-ietf-dna-simple-03 draft-ietf-dna-simple-04
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 April 6, 2009. This Internet-Draft will expire on April 30, 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.
skipping to change at page 2, line 18 skipping to change at page 2, line 18
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 3
2.3. DNA Roles . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. DNA Roles . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Working Assumptions . . . . . . . . . . . . . . . . . . . 4 2.4. Working Assumptions . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . 6 4.2. Steps involved in detecting link change . . . . . . . . . 6
4.3. Link-Layer Indication . . . . . . . . . . . . . . . . . . 6 4.3. Link-Layer Indication . . . . . . . . . . . . . . . . . . 6
4.4. Sending RS and NS probes . . . . . . . . . . . . . . . . . 6 4.4. Sending Neighbor Discovery probes . . . . . . . . . . . . 6
4.5. Response Gathering . . . . . . . . . . . . . . . . . . . . 7 4.5. Sending DHCPv6 probes . . . . . . . . . . . . . . . . . . 7
4.6. Further Host Operations . . . . . . . . . . . . . . . . . 8 4.6. Response Gathering . . . . . . . . . . . . . . . . . . . . 8
4.7. Recommended retransmission behavior . . . . . . . . . . . 8 4.7. Further Host Operations . . . . . . . . . . . . . . . . . 8
5. Router Operations . . . . . . . . . . . . . . . . . . . . . . 9 4.8. Recommended retransmission behavior . . . . . . . . . . . 9
6. Pseudocode for Simple DNA . . . . . . . . . . . . . . . . . . 10 5. Router Operations . . . . . . . . . . . . . . . . . . . . . . 10
7. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. DHCPv6 Router/Server Operations . . . . . . . . . . . . . 11
8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Pseudocode for Simple DNA . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 13
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
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
skipping to change at page 3, line 44 skipping to change at page 3, line 44
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.2. Applicability 2.2. Applicability
The Simple DNA protocol is provides substantial benefits in some The Simple DNA protocol provides substantial benefits in some
scenarios and does not provide any benefit at all in certain other scenarios and does not provide any benefit at all in certain other
scenarios. This is intentional as Simple DNA was designed for scenarios. This is intentional as Simple DNA was designed for
simplicity rather than completeness. In particular, the Simple DNA simplicity rather than completeness. In particular, the Simple DNA
protocol provides maximum benefits when a host moves between a small 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 set of known links. When a host moves to a completely new link that
is previously unknown, the performance of the Simple DNA protocol is previously unknown, the performance of the Simple DNA protocol
will be identical to that using standard neighbor discovery will be identical to that using standard neighbor discovery
procedures [RFC4861]. procedures [RFC4861].
2.3. DNA Roles 2.3. DNA Roles
skipping to change at page 4, line 29 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.
Additionally, on links with no statelessly configured addresses, the
host may make use of DHCPv6 procedures to identify an operable
address.
2.4. Working Assumptions 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 5, line 49 skipping to change at page 6, line 6
o IPv6 address and its related parameters like valid lifetime. o IPv6 address and its related parameters like valid lifetime.
o Prefix from which the address was formed. o Prefix from which the address was formed.
o Link-local IPv6 address of the router that advertised the prefix. o Link-local IPv6 address of the router that advertised the prefix.
o Link layer (MAC) address of the router that advertised the prefix. o Link layer (MAC) address of the router that advertised the prefix.
o DHCP Unique IDentifier (DUID) in case DHCPv6 was used to acquire o DHCP Unique IDentifier (DUID) in case DHCPv6 was used to acquire
the address. the address [RFC3315].
4.2. Steps involved in detecting link change 4.2. Steps involved in detecting link change
The steps involved in basic detection of network attachment are: The steps involved in basic detection of network attachment are:
o Link-Layer Indication o Link-Layer Indication
o Sending RS and NS probes o Sending of neighbour discovery or DHCPv6 probes
o Response gathering and assessment o Response gathering and assessment
These steps are described below. These steps are described below.
4.3. Link-Layer Indication 4.3. Link-Layer Indication
In order to start Detection of network attachment procedures, a host In order to start Detection of network attachment procedures, a host
typically requires a link-layer indication that the medium has become typically requires a link-layer indication that the medium has become
available [RFC4957]. available [RFC4957].
After the indication is received, the host considers all currently After the indication is received, the host considers all currently
configured (non-tentative) IP addresses to as deprecated until the configured (non-tentative) IP addresses to as deprecated until the
change detection process completes. It SHOULD also set all Neighbor change detection process completes. It SHOULD also set all Neighbor
Cache entries for the routers on its Default Router List to STALE. Cache entries for the routers on its Default Router List to STALE.
This is done to speed up the acquisition of a new default router when This is done to speed up the acquisition of a new default router when
link change has occurred. link change has occurred.
4.4. Sending RS and NS probes 4.4. Sending Neighbor Discovery probes
When a host receives a link-layer "up" indication, it SHOULD When a host receives a link-layer "up" indication, it SHOULD
immediately send both a Router Solicitation and if it retains at immediately send both a Router Solicitation and if it retains at
least one valid IPv6 address, one or more unicast Neighbor least one valid IPv6 address, one or more unicast Neighbor
Solicitations. The Router Solicitation is sent to the All-routers Solicitations. The Router Solicitation is sent to the All-routers
multicast address using a link-local address as the source address multicast address using a link-local address as the source address
[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.
skipping to change at page 7, line 20 skipping to change at page 7, line 24
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 8. 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. Sending DHCPv6 probes
Where the host has acquired addresses from DHCPv6 or the host does
not have a global prefix, it MAY prefer to use DHCPv6 messages either
before or simultanously with Neighbour Discovery probing.
In that case, when the host receives a link-layer indication, it
sends a DHCPv6 SOLICIT to All_DHCP_Relay_Agents_and_Servers. This
message contains an Identity Addociation for either a Temporary
Address (IA_TA) or Non-Temporary Address (IA_NA) [RFC3315]. Where an
existing valid address is being tested for operability, this address
should be placed in the Identity Association's IAADDR element, and
the DUID associated with that address should be copied to the DHCP
SOLICIT from the SDAT.
In order to quickly acquire a new address in the case that link
change has occurred, this SOLICIT message MAY contain the Rapid-
Commit option.
Where the Rapid-Commit option has not been used, a present DHCP
server will respond with an ADVERTISE message. The IP address
contained in the Identity Association (IA_TA or IA_NA) will contain
an IP Address which is operable for the link.
Where Rapid-Commit option has been sent, a DHCPv6 server will respond
with REPLY. In addition to being operable, this address is allocated
to the host for the lease duration indicated in the Identity
Association.
4.6. 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.).
On reception of a Router Advertisement which contains prefixes which On reception of a Router Advertisement or advertising DHCPv6 message
intersect with those previously advertised by a known router, the (a REPLY or ADVERTISE) which contains prefixes that intersect with
host utilizes the configuration associated with the detected network. those previously advertised by a known router, the host utilizes the
configuration associated with the detected network.
When the host receives a router advertisement containing only When the host receives an advertisement containing only prefixes
prefixes which are disjoint from known advertised prefixes, the host which are disjoint from known advertised prefixes, the host MUST
MUST determine whether the solicited router advertisement corresponds determine whether the solicited advertisement corresponds to any of
to any of the routers probed via NS. If it does, then the host the routers probed via NS. If it does, then the host SHOULD conclude
SHOULD conclude that the IPv6 addresses corresponding to that router that the IPv6 addresses corresponding to that router are no longer
are no longer valid. Since any NS probes to that router will no valid. Since any NS probes to that router will no longer provide
longer provide useful information, further probing of that router useful information, further probing of that router SHOULD be aborted.
SHOULD be aborted.
Where the conclusions obtained from the Neighbor Solicitation/ Where the conclusions obtained from the Neighbor Solicitation/
Advertisement from a given router and the RS/RA exchange with the Advertisement from a given router and the RS/RA exchange with the
same router differ, the results obtained from the RS/RA will be same router differ, the results obtained from the RS/RA will be
considered definitive. considered definitive.
When the host receives a Router Advertisement in reply to the Router When the host receives a Router Advertisement in reply to the Router
Solicitation it sent, the host SHOULD look for a Neighbor Cache entry Solicitation it sent, the host SHOULD look for a Neighbor Cache entry
for the sending router and SHOULD mark that router's Neighbor Cache for the sending router and SHOULD mark that router's Neighbor Cache
Entry as REACHABLE if one was found. The host SHOULD add a new Entry as REACHABLE if one was found. The host SHOULD add a new
Neighbor Cache Entry in the REACHABLE state for the sending router if Neighbor Cache Entry in the REACHABLE state for the sending router if
one does not currently exist. one does not currently exist.
4.6. Further Host Operations 4.7. Further Host Operations
Operations subsequent to detecting network attachment depend upon Operations subsequent to detecting network attachment depend upon
whether change was detected. whether change was detected.
After confirming the reachability of the associated router using an After confirming the reachability of the associated router using an
NS/NA pair, the host performs the following steps. NS/NA pair, the host performs the following steps.
o The host SHOULD rejoin any solicited nodes' multicast groups for o The host SHOULD rejoin any solicited nodes' multicast groups for
addresses it continues to use. addresses it continues to use.
skipping to change at page 8, line 29 skipping to change at page 9, line 13
SHOULD NOT perform duplicate address detection on the addresses that SHOULD NOT perform duplicate address detection on the addresses that
have been confirmed to be operable. have been confirmed to be operable.
If the NS based probe with a router did not complete or if the RS If the NS based probe with a router did not complete or if the RS
based probe on the same router completed with different prefixes than based probe on the same router completed with different prefixes than
the ones in the SDAT the host MUST unconfigure all the existing the ones in the SDAT the host MUST unconfigure all the existing
addresses received from the given router, and MUST begin address addresses received from the given router, and MUST begin address
configuration techniques, as indicated in the received Router configuration techniques, as indicated in the received Router
Advertisement [RFC4861][RFC4862]. Advertisement [RFC4861][RFC4862].
4.7. Recommended retransmission behavior 4.8. Recommended retransmission behavior
In situations where Neighbor Solicitation probes and Router In situations where Neighbor Solicitation probes and Router
Solicitation probes are used on the same link, it is possible that Solicitation probes are used on the same link, it is possible that
the NS probe will complete successfully, and then the RS probe will the NS probe will complete successfully, and then the RS probe will
complete later with a different result. If this happens, the complete later with a different result. If this happens, the
implementation SHOULD abandon the results obtained from the NS probe implementation SHOULD abandon the results obtained from the NS probe
of the router that responded to the RS and the implementation SHOULD of the router that responded to the RS and the implementation SHOULD
behave as if the NS probe did not successfully complete. If the behave as if the NS probe did not successfully complete. If the
confirmed address was assigned manually, the implementation SHOULD confirmed address was assigned manually, the implementation SHOULD
NOT unconfigure the manually assigned address and SHOULD log an error NOT unconfigure the manually assigned address and SHOULD log an error
skipping to change at page 9, line 6 skipping to change at page 9, line 39
in aggressively retransmitting unicast neighbor solicitations that do in aggressively retransmitting unicast neighbor solicitations that do
not elicit a response. not elicit a response.
Where unicast Neighbor Solicitations and Router Solicitations are Where unicast Neighbor Solicitations and Router Solicitations are
sent in parallel, one strategy is to forsake retransmission of sent in parallel, one strategy is to forsake retransmission of
Neighbor Solicitations and to allow retransmission only of Router Neighbor Solicitations and to allow retransmission only of Router
Solicitations or DHCPv6. In order to reduce competition between Solicitations or DHCPv6. In order to reduce competition between
unicast Neighbor Solicitations and Router Solicitations and DHCPv6 unicast Neighbor Solicitations and Router Solicitations and DHCPv6
retransmissions, a DNAv6 implementation that retransmits may utilize retransmissions, a DNAv6 implementation that retransmits may utilize
the retransmission strategy described in the DHCPv6 specification the retransmission strategy described in the DHCPv6 specification
[RFCDHCPv6], scheduling DNAv6 retransmissions between Router [RFC3315], scheduling DNAv6 retransmissions between Router
Solicitation or DHCPv6 retransmissions. Solicitation or DHCPv6 retransmissions.
If a response is received to any unicast Neighbor Solicitation, If a response is received to any unicast Neighbor Solicitation,
Router Solicitation or DHCPv6 message, pending retransmissions MUST Router Solicitation or DHCPv6 message, pending retransmissions MUST
be canceled. A Simple DNA implementation SHOULD NOT retransmit a be canceled [RFC3315][RFC3736]. A Simple DNA implementation SHOULD
Neighbor Solicitation more than twice. To provide damping in the NOT retransmit a Neighbor Solicitation more than twice. To provide
case of spurious Link Up indications, the host SHOULD NOT perform the damping in the case of spurious Link Up indications, the host SHOULD
Simple DNA procedure more than once a second. NOT perform the Simple DNA procedure more than once a second.
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].
5.1. DHCPv6 Router/Server Operations
DHCPv6 Server operations occur in accordance with the DHCPv6 RFC
[RFC3315].
6. Pseudocode for Simple DNA 6. Pseudocode for Simple DNA
/* Link up indication received on INTERFACE */ /* Link up indication received on INTERFACE */
/* Start Simple DNA process */ /* Start Simple DNA process */
/* Mark All Addresses as deprecated */ /* Mark All Addresses as deprecated */
Configured_Address_List=Get_Address_List(INTERFACE); Configured_Address_List=Get_Address_List(INTERFACE);
foreach Configured_Address in Configured_Address_List foreach Configured_Address in Configured_Address_List
{ {
if (Get_Address_State(Configured_Address)!=AS_TENTATIVE) if (Get_Address_State(Configured_Address)!=AS_TENTATIVE)
skipping to change at page 14, line 38 skipping to change at page 15, line 41
(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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[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, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
12.2. Informative References 12.2. Informative References
[RFC4957] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S., [RFC4957] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S.,
skipping to change at page 15, line 23 skipping to change at page 16, line 35
Phone: +1 514 345 7900 x42871 Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com Email: suresh.krishnan@ericsson.com
Greg Daley Greg Daley
NetStar Networks NetStar Networks
Level 9/636 St Kilda Rd Level 9/636 St Kilda Rd
Melbourne, Victoria 3004 Melbourne, Victoria 3004
Australia Australia
Phone: +61 405 494849 Phone: +61 3 8532 4042
Email: gdaley@netstarnetworks.com Email: gdaley@netstarnetworks.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
 End of changes. 19 change blocks. 
43 lines changed or deleted 90 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/