draft-ietf-dna-simple-11.txt   draft-ietf-dna-simple-12.txt 
Network Working Group S. Krishnan Network Working Group S. Krishnan
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 4861 (if approved) G. Daley Intended status: Standards Track G. Daley
Intended status: Standards Track NetStar Networks Expires: July 25, 2010 NetStar Networks
Expires: April 29, 2010 October 26, 2009 January 21, 2010
Simple procedures for Detecting Network Attachment in IPv6 Simple procedures for Detecting Network Attachment in IPv6
draft-ietf-dna-simple-11 draft-ietf-dna-simple-12
Abstract
Detecting Network Attachment allows hosts to assess if its existing
addressing or routing configuration is valid for a newly connected
network. This document provides simple procedures for detecting
network attachment in IPv6 hosts, and procedures for routers to
support such services.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 41
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 29, 2010. This Internet-Draft will expire on July 25, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Detecting Network Attachment allows hosts to assess if its existing described in the BSD License.
addressing or routing configuration is valid for a newly connected
network.
This document provides simple procedures for detecting network
attachment in IPv6 hosts, and procedures for routers to support such
services.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Link Identification model . . . . . . . . . . . . . . . . 4 2.3. Link Identification model . . . . . . . . . . . . . . . . 4
2.4. DNA Overview . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. DNA Overview . . . . . . . . . . . . . . . . . . . . . . . 4
2.5. Working Assumptions . . . . . . . . . . . . . . . . . . . 5 2.5. Working Assumptions . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 6 4. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Host data structures . . . . . . . . . . . . . . . . . . . 6 4.1. Host data structures . . . . . . . . . . . . . . . . . . . 6
4.2. Steps involved in detecting link change . . . . . . . . . 6 4.1.1. SDAT Maintenance . . . . . . . . . . . . . . . . . . . 6
4.2. Steps involved in detecting link change . . . . . . . . . 7
4.3. Link-Layer Indication . . . . . . . . . . . . . . . . . . 7 4.3. Link-Layer Indication . . . . . . . . . . . . . . . . . . 7
4.4. Sending Neighbor Discovery probes . . . . . . . . . . . . 7 4.4. Sending Neighbor Discovery probes . . . . . . . . . . . . 7
4.5. Contents of the Neighbor Discovery messages . . . . . . . 8 4.5. Contents of the Neighbor Discovery messages . . . . . . . 9
4.5.1. Neighbor Solicitation messages . . . . . . . . . . . . 8 4.5.1. Neighbor Solicitation messages . . . . . . . . . . . . 9
4.5.2. Router Solicitation messages . . . . . . . . . . . . . 8 4.5.2. Router Solicitation messages . . . . . . . . . . . . . 9
4.6. DHCPv6 operation . . . . . . . . . . . . . . . . . . . . . 9 4.6. DHCPv6 operation . . . . . . . . . . . . . . . . . . . . . 10
4.7. Response Gathering . . . . . . . . . . . . . . . . . . . . 9 4.7. Response Gathering . . . . . . . . . . . . . . . . . . . . 10
4.7.1. Conflicting results . . . . . . . . . . . . . . . . . 10 4.7.1. Conflicting results . . . . . . . . . . . . . . . . . 11
4.8. Further Host Operations . . . . . . . . . . . . . . . . . 11 4.8. Further Host Operations . . . . . . . . . . . . . . . . . 11
4.9. Recommended retransmission behavior . . . . . . . . . . . 11 4.9. Recommended retransmission behavior . . . . . . . . . . . 12
5. Pseudocode for Simple DNA . . . . . . . . . . . . . . . . . . 13 5. Pseudocode for Simple DNA . . . . . . . . . . . . . . . . . . 13
6. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Relationship to DNAv4 . . . . . . . . . . . . . . . . . . . . 15 7. Relationship to DNAv4 . . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Issues with confirming manually assigned addresses . 17 Appendix A. Issues with confirming manually assigned addresses . 17
skipping to change at page 3, line 14 skipping to change at page 3, line 14
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 than the one to which they have been moved to a network to which they had been recently connected. In
recently connected. In order to detect change, router and neighbor order to detect change, router and neighbor discovery messages are
discovery messages are used to collect reachability and configuration used to collect reachability and configuration information. This
information. This information is used to detect whether the existing information is used to detect whether the existing router and address
router and address prefixes are likely to be present. 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 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 The most common use cases are optimized. o The most common use cases are optimized.
o In the worst case, detection latency is equal to that of standard o In the worst case, detection latency is equal to that of standard
neighbor discovery so that performance is never degraded. neighbor discovery so that performance is never degraded.
o False positives are not acceptable. A host should not conclude o False positives are not acceptable. A host MUST NOT conclude that
that there is no link change when there is one. 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 MAY fail to identify a
a link change when there is none. previously visited link correctly and attempt to acquire fresh
addressing and configuration information.
2.2. Applicability 2.2. Applicability
The Simple DNA protocol provides substantial benefits in some The Simple DNA protocol provides substantial benefits over standard
scenarios and does not provide any benefit at all in certain other neighbor discovery procedures [RFC4861] in some scenarios and does
scenarios. This is intentional as Simple DNA was designed for not provide any benefit at all in certain other scenarios. This is
simplicity rather than completeness. In particular, the Simple DNA intentional as Simple DNA was designed for simplicity rather than
protocol provides maximum benefits when a host moves between a small completeness. In particular, the Simple DNA protocol provides
set of known links. When a host moves to a completely new link that maximum benefits when a host moves between a small set of known
is previously unknown, the performance of the Simple DNA protocol links. When a host moves to a completely new link that is previously
will be identical to that using standard neighbor discovery unknown, the performance of the Simple DNA protocol will be identical
procedures [RFC4861]. The Simple DNA procedure provides support for to that using standard neighbor discovery procedures [RFC4861]. In
addresses configured using either IPv6 Stateless Address this case the main benefit of the Simple DNA protocol is to
immediately flush out the inoperable addresses and configuration
instead of timing them out. The Simple DNA procedure provides
support for addresses configured using either IPv6 Stateless Address
Autoconfiguration [RFC4862] or DHCPv6 [RFC3315]. It does not support Autoconfiguration [RFC4862] or DHCPv6 [RFC3315]. It does not support
manually configured addresses since they are not widely used and can manually configured addresses since they are not widely used and can
cause unpredictable results and/or aggressive probing behavior cause unpredictable results and/or aggressive probing behavior
[Appendix A]. [Appendix A].
2.3. Link Identification model 2.3. Link Identification model
Earlier methods of detecting network attachment, e.g. the procedure Earlier methods of detecting network attachment, e.g. the procedure
defined in [I-D.ietf-dna-protocol], relied on detecting whether the defined in [I-D.ietf-dna-protocol], relied on detecting whether the
host was still connected to the same link. If the host was attached host was still connected to the same link. If the host was attached
skipping to change at page 5, line 14 skipping to change at page 5, line 17
using unicast Neighbor Solicitations. As a result, where the host using unicast Neighbor Solicitations. As a result, where the host
with a valid configuration is returning to a previously encountered with a valid configuration is returning to a previously encountered
link, delays in the sending of a Router Advertisement (RA) will not link, delays in the sending of a Router Advertisement (RA) will not
delay configuration as long as NS probing is successful. However in delay configuration as long as NS probing is successful. However in
situations where the host is attaching to a link for the first time, situations where the host is attaching to a link for the first time,
or where it does not have a valid IP address on the link, it will be or where it does not have a valid IP address on the link, it will be
dependent on the receipt of an RA for stateless auto-configuration. dependent on the receipt of an RA for stateless auto-configuration.
In these situations delays in the receipt of an RA can be significant In these situations delays in the receipt of an RA can be significant
and may result in service disruption. and may result in service disruption.
As a result, in addition to implementing simple DNA, it is desirable
that routers adopt procedures which allow for fast unicast Router
Advertisement (RA) messages.
2.5. Working Assumptions 2.5. 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 22 skipping to change at page 6, line 22
determine whether the existing addressing and routing configuration determine whether the existing addressing and routing configuration
are still valid. are still valid.
In order to determine this, the host performs the detecting network In order to determine this, the host performs the detecting network
attachment procedure. attachment procedure.
4.1. Host data structures 4.1. Host data structures
In order to correctly perform the procedure described in this In order to correctly perform the procedure described in this
document the host needs to maintain a data structure called the document the host needs to maintain a data structure called the
Simple DNA address table (SDAT). This data structure is maintained Simple DNA address table (SDAT). The host needs to maintain this
by the host on a per interface basis. Each entry in the SDAT table data structure for each interface on which it performs Simple DNA.
consists of at least the following parameters. Each entry in the SDAT table consists of at least the following
parameters.
o IPv6 address and its related parameters like valid lifetime. o IPv6 address and its related parameters like valid lifetime,
preferred lifetime etc.
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(es) of the router(s) that advertised the
prefix.
o Link-layer (MAC) address of the router that advertised the prefix. o Link-layer (MAC) address(es) of the router(s) that advertised the
prefix.
o DHCP Unique IDentifier (DUID) in case DHCPv6 was used to acquire o Flag indicating whether the address was obtained using SLAAC or
the address [RFC3315]. DHCPv6.
o DHCP specific information in case DHCPv6 [RFC3315] was used to
acquire the address. This information includes DUID, IA_ID, a
flag indicating IA_NA/IA_TA, configuration information such as DNS
server address, NTP server address etc.
4.1.1. SDAT Maintenance
The host SHOULD maintain the SDAT table by periodically cleaning out
entries whose valid lifetimes have expired. The host MAY also
maintain the table by allowing SDAT entries from "n" previously
visited links. When the host attaches to a previously unknown link
and the SDAT already contains entries from the previous "n" attached
links,it will discard all the SDAT entries corrsponding to the least
recently attached link.
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 of neighbor discovery or DHCPv6 probes o Sending of neighbor discovery and/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 be deprecated until the configured (non-tentative) IP addresses to be deprecated until the
change detection process completes. It SHOULD also set all Neighbor change detection process completes. It MUST 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 Neighbor Discovery 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 (as specified in as
least one valid IPv6 address, one or more unicast Neighbor specified in section 6.3.7 of [RFC4861]) and if it retains at least
Solicitations. The Router Solicitation is sent to the All-routers one valid IPv6 address, one or more unicast Neighbor Solicitations.
multicast address using a link-local address as the source address The Router Solicitation is sent to the All-routers multicast address
[RFC4861]. Even if the host is in possession of more than one valid using a link-local address as the source address [RFC4861]. Even if
IPv6 address, it MUST send only one router solicitation using a valid the host is in possession of more than one valid IPv6 address, it
link-local address as the source address. MUST send only one router solicitation using a valid 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 identifies the set of operable IPv6 addresses routers, the host first identifies the set of valid IPv6 addresses
(candidate set) that it wishes to use. If the addresses obtained (candidate set) that it wishes to use.
from a previous router are no longer valid, the host does not include
these 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(s)
advertised the prefix used to form the address. It then sends an that advertised the prefix used to form the address. It then sends
unicast Neighbor Solicitations to each router's link-local address it an unicast Neighbor Solicitations to each router's link-local address
obtained from the lookup on the SDAT. The host SHOULD NOT send it obtained from the lookup on the SDAT. The host MUST 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 Neighbor Solicitations SHOULD be sent in Please note that the Neighbor Solicitations SHOULD be sent in
parallel with the Router Solicitations. Since sending NSs is just an parallel with the Router Solicitation. Since sending NSs is just an
optimization, doing the NSs and RSs in parallel ensures that the optimization, doing the NSs and the RS 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.
NOTE: A Simple DNA implementation MUST limit its probing to at most
six previously seen routers
4.5. Contents of the Neighbor Discovery messages 4.5. Contents of the Neighbor Discovery messages
4.5.1. Neighbor Solicitation messages 4.5.1. Neighbor Solicitation messages
This section describes the contents of the neighbor solicitation This section describes the contents of the neighbor solicitation
probe messages sent during the probing procedure. probe messages sent during the probing procedure.
Source Address: A link-local address assigned to the Source Address: A link-local address assigned to the
probing host. probing host.
skipping to change at page 8, line 30 skipping to change at page 9, line 30
ND Options: ND Options:
Target Address: The link-local address of the router being Target Address: The link-local address of the router being
probed as learnt from the SDAT. probed as learnt from the SDAT.
Link Layer Header: Link Layer Header:
Destination Address: The link-layer (MAC) address of the router Destination Address: The link-layer (MAC) address of the router
being probed as learnt from the SDAT. being probed as learnt from the SDAT.
The probing node SHOULD include a Source link-layer address option in The probing node SHOULD include the Source link-layer address option
the probe messages if the address was obtained using DHCPv6 and the in the probe messages.
lease has not expired. Otherwise the probing node SHOULD NOT include
the Source link-layer address option in the probe messages.
4.5.2. Router Solicitation messages 4.5.2. Router Solicitation messages
This section describes the contents of the router solicitation probe This section describes the contents of the router solicitation probe
message sent during the probing procedure. message sent during the probing procedure.
Source Address: A link-local address assigned to the Source Address: A link-local address assigned to the
probing host. probing host.
Destination Address: The all-routers multicast address. Destination Address: The all-routers multicast address.
skipping to change at page 9, line 21 skipping to change at page 10, line 21
not result in additional delay in the case where reachability tests not result in additional delay in the case where reachability tests
fail, or where a DHCPv6 exchange completes more quickly than the fail, or where a DHCPv6 exchange completes more quickly than the
reachability tests. reachability tests.
In situations where both simple DNA and DHCPv6 are used on the same In situations where both simple DNA and DHCPv6 are used on the same
link, it is possible that simple DNA probing will complete link, it is possible that simple DNA probing will complete
successfully, and then DHCPv6 will complete later with a different successfully, and then DHCPv6 will complete later with a different
result. If this happens, the procedure described in Section 4.7.1 result. If this happens, the procedure described in Section 4.7.1
are utilized. are utilized.
Where the host attempts to obtain IPv6 configuration in parallel with The host attempts to verify its DHCPv6-obtained information in
simple DNA, on receiving a link-layer "up" indication, it sends a parallel with simple DNA. On receiving a link-layer "up" indication,
DHCPv6 SOLICIT to All_DHCP_Relay_Agents_and_Servers. This message it will initiate a DHCPv6 exchange as specified in [RFC3315] in order
contains an Identity Association for either a Temporary Address to verify whether the addresses and configuration obtained using
(IA_TA) or Non-Temporary Address (IA_NA) [RFC3315]. Where an DHCPv6 are still usable on the link.
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.7. Response Gathering 4.7. Response Gathering
When a responding Neighbor Advertisement is received from a test When a responding Neighbor 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 or advertising DHCPv6 message On reception of a Router Advertisement that contains prefixes that
(a REPLY or ADVERTISE) which contains prefixes that intersect with intersect with those previously advertised by a known router, the
those previously advertised by a known router, the host utilizes the host utilizes the configuration associated with the detected network.
configuration associated with the detected network.
When the host receives an advertisement containing only prefixes If the host receives a router advertisement from a router containing
which are disjoint from known advertised prefixes, the host MUST only prefixes that are disjoint from the prefixes associated with the
determine whether the solicited advertisement corresponds to any of same router in the SDAT, then the host MUST conclude that the IPv6
the routers probed via NS. If it does, then the host SHOULD conclude addresses corresponding to that router are no longer valid. Since
that the IPv6 addresses corresponding to that router are no longer any NS probes to that router will no longer provide useful
valid. Since any NS probes to that router will no longer provide information, further probing of that router MUST be aborted.
useful information, further probing of that router SHOULD be aborted. Furthermore, the host MUST remove all the SDAT entries corresponding
to this router.
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. In case the Neighbor Advertisement was
secured using SEND and the Router Advertisement was not, the host
MUST wait for SEND_NA_GRACE_TIME to see if a SEND-secured RA is
received. If a SEND-secured RA is not received, the conclusions
obtained from the NS/NA exchange will be considered definitive.
When the host receives a Router Advertisement in reply to the Router When the host receives a Router Advertisement from a given router,
Solicitation it sent, the host SHOULD look for a Neighbor Cache entry the host MUST look for a Neighbor Cache entry for the sending router
for the sending router and SHOULD mark that router's Neighbor Cache and MUST mark that router's Neighbor Cache Entry as REACHABLE if one
Entry as REACHABLE if one was found. The host SHOULD add a new was found. The host MUST add a new Neighbor Cache Entry in the
Neighbor Cache Entry in the REACHABLE state for the sending router if REACHABLE state for the sending router if one does not currently
one does not currently exist. exist.
4.7.1. Conflicting results 4.7.1. Conflicting results
It is possible that the DHCPv6 exchanges and the neighbor discovery It is possible that the DHCPv6 exchanges and the neighbor discovery
based probes complete with conflicting results. In this case, the based probes complete with conflicting results. In this case, the
host SHOULD use the following rules to determine the final result. host SHOULD use the following rules to determine the final result.
o If the DHCPv6 exchange was authenticated, use the result from o If the DHCPv6 exchange was authenticated, use the result from
DHCPv6. DHCPv6.
skipping to change at page 11, line 19 skipping to change at page 12, line 8
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.
o The host SHOULD select a default router as described in [RFC4861]. o The host SHOULD select a default router as described in Section
6.3.6 of [RFC4861].
If the host has determined that there has been no link change, it If the host has determined that there has been no link change, it
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 begin address configuration
addresses received from the given router, and MUST begin address techniques, as indicated in a received Router Advertisement
configuration techniques, as indicated in the received Router [RFC4861][RFC4862].
Advertisement [RFC4861][RFC4862].
4.9. Recommended retransmission behavior 4.9. Recommended retransmission behavior
Where the NS probe does not complete successfully, it usually implies Where the NS probe does not complete successfully, it usually implies
that the host is not attached to the network whose configuration is that the host is not attached to the network whose configuration is
being tested. In such circumstances, there is typically little value being tested. In such circumstances, there is typically little value
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
[RFC3315], scheduling DNAv6 retransmissions between Router [RFC3315], scheduling DNAv6 retransmissions between Router
Solicitation or DHCPv6 retransmissions. Solicitations 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 [RFC3315][RFC3736]. A Simple DNA implementation SHOULD be canceled [RFC3315][RFC3736]. A Simple DNA implementation SHOULD
NOT retransmit a Neighbor Solicitation more than twice. To provide NOT retransmit a Neighbor Solicitation more than twice. To provide
damping in the case of spurious Link Up indications, the host SHOULD damping in the case of spurious Link Up indications, the host SHOULD
NOT perform the Simple DNA procedure more than once a second. NOT perform the Simple DNA procedure more than once a second.
5. Pseudocode for Simple DNA 5. Pseudocode for Simple DNA
skipping to change at page 16, line 15 skipping to change at page 16, line 15
If the current default router is a SEND-secured router, the host If the current default router is a SEND-secured router, the host
SHOULD wait SEND_NA_GRACE_TIME after transmission before adopting a SHOULD wait SEND_NA_GRACE_TIME after transmission before adopting a
new default router. new default router.
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.
Unless SEND or other form of secure address configuration is used,
the DNA procedure does not in itself provide positive, secure
authentication of the router(s) on the network, or authentication of
the network itself, as e.g. would be provided by mutual
authentication at the link layer. Therefore when such assurance is
not available, the host MUST NOT make any security-sensitive
decisions based on the DNA procedure alone. In particular, it MUST
NOT decide that it has moved from an untrusted to a trusted network,
and MUST NOT make any security decisions that depend on the
determination that such a transition has occurred.
10. Acknowledgments 10. Acknowledgments
This document is the product of a discussion the authors had with This document is the product of a discussion the authors had with
Bernard Aboba, Thomas Narten, Erik Nordmark and Dave Thaler at IETF Bernard Aboba, Thomas Narten, Erik Nordmark and Dave Thaler at IETF
69. The authors would like to thank them for clearly detailing the 69. The authors would like to thank them for clearly detailing the
requirements of the solution and the goals it needed to meet and for requirements of the solution and the goals it needed to meet and for
helping to explore the solution space. The authors would like to 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, Jari Arkko, Sathya Narayan, Julien Laganier, Aboba, Thomas Narten, Jari Arkko, Sathya Narayan, Julien Laganier,
Domagoj Premec, Jin Hyeock-Choi, Alfred Hoenes and Frederic Rossi for Domagoj Premec, Jin Hyeock-Choi, Alfred Hoenes, Frederic Rossi, Ralph
performing reviews on the document and providing valuable comments to Droms, Ted Lemon, Erik Nordmark, Lars Eggert, Brian Carpenter and
drive the document forward. Yaron Sheffer for performing reviews on the document and providing
valuable comments to drive the document forward.
11. References 11. References
11.1. Normative References 11.1. Normative References
[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.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004. (DHCP) Service for IPv6", RFC 3736, April 2004.
 End of changes. 36 change blocks. 
132 lines changed or deleted 152 lines changed or added

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