draft-ietf-dna-simple-13.txt   draft-ietf-dna-simple-14.txt 
Network Working Group S. Krishnan Network Working Group S. Krishnan
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track G. Daley Intended status: Standards Track G. Daley
Expires: August 8, 2010 NetStar Networks Expires: August 18, 2010 NetStar Networks
February 4, 2010 February 14, 2010
Simple procedures for Detecting Network Attachment in IPv6 Simple procedures for Detecting Network Attachment in IPv6
draft-ietf-dna-simple-13 draft-ietf-dna-simple-14
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. 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 network attachment in IPv6 hosts, and procedures for routers to
support such services. support such services.
Status of this Memo Status of this Memo
skipping to change at page 1, line 41 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 August 8, 2010. This Internet-Draft will expire on August 18, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 15 skipping to change at page 3, line 15
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 network to which they had been recently connected. In moved to a network to which they had been recently connected. In
order to detect change, router and neighbor discovery messages are order to detect reconnection to a previously visited network, router
used to collect reachability and configuration information. This and neighbor discovery messages are used to collect reachability and
information is used to detect whether the existing router and address configuration information. This information is used to detect if the
prefixes are likely to be present. host has attached to a link for which it may still have valid address
and other configuration information, and which it can use until it
receives confirmation through either through the Neighbor Discovery
protocol or DHCPv6.
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 MUST NOT conclude that o False positives are not acceptable. A host MUST NOT wrongly
there is no link change when there is one. conclude that it has reattached to a previouly visited network.
o False negatives are acceptable. A host MAY fail to identify a o False negatives are acceptable. A host MAY fail to identify a
previously visited link correctly and attempt to acquire fresh previously visited link correctly and attempt to acquire fresh
addressing and configuration information. addressing and configuration information.
2.2. Applicability 2.2. Applicability
The Simple DNA protocol provides substantial benefits over standard The Simple DNA protocol provides substantial benefits over standard
neighbor discovery procedures [RFC4861] in some scenarios and does neighbor discovery procedures [RFC4861] in some scenarios and does
not provide any benefit at all in certain other scenarios. This is not provide any benefit at all in certain other scenarios. This is
skipping to change at page 6, line 7 skipping to change at page 6, line 7
| | has a valid lifetime greater than zero. | | | has a valid lifetime greater than zero. |
| | | | | |
| Operable IPv6 | An IPv6 address configured on the node that | | Operable IPv6 | An IPv6 address configured on the node that |
| address | can be used safely on the current link. | | address | can be used safely on the current link. |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
Table 1: Simple DNA Terminology Table 1: Simple DNA Terminology
4. Host Operations 4. Host Operations
When a host has an existing configuration for IP address prefixes and On connecting to a new point of attachment, the host performs the
next hop routing, it may be disconnected from its link-layer, and detecting network attachment procedure in order to determine whether
then subsequently reconnect the link-layer on the same interface. the existing addressing and configuration information are still
valid.
When the link-layer becomes available again, it is important to
determine whether the existing addressing and routing configuration
are still valid.
In order to determine this, the host performs the detecting network
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). The host needs to maintain this Simple DNA address table (SDAT). The host needs to maintain this
data structure for each interface on which it performs Simple DNA. data structure for each interface on which it performs Simple DNA.
Each entry in the SDAT table consists of at least the following Each entry in the SDAT table consists of at least the following
parameters. parameters.
skipping to change at page 7, line 44 skipping to change at page 7, line 42
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 (as specified in as immediately send both a Router Solicitation (as specified in as
specified in section 6.3.7 of [RFC4861]) and if it retains at least specified in section 6.3.7 of [RFC4861]) and if it retains at least
one valid IPv6 address, one or more unicast Neighbor Solicitations. one valid IPv6 address, one or more unicast Neighbor Solicitations.
The Router Solicitation is sent to the All-routers multicast address The Router Solicitation is sent to the All-routers multicast address
using a link-local address as the source address [RFC4861]. Even if using a link-local address as the source address [RFC4861]. Even if
the host is in possession of more than one valid IPv6 address, it the host is in possession of more than one valid IPv6 address, it
MUST send only one router solicitation using a valid link-local MUST send only one router solicitation using a valid link-local
address as the source address. address as the source address.
For the purpose of sending neighbor solicitations to previous For each of the addresses in the SDAT, the host looks up the SDAT to
routers, the host first identifies the set of valid IPv6 addresses find out the link-local and MAC addresses of the router(s) that
(candidate set) that it wishes to use. advertised the prefix used to form the address. It then sends an
unicast Neighbor Solicitations to each router's link-local address it
For each of the addresses in the candidate set, the host looks up the obtained from the lookup on the SDAT. The host MUST NOT send unicast
SDAT to find out the link-local and MAC addresses of the router(s) Neighbor Solicitations to a test node corresponding to an IPv6
that advertised the prefix used to form the address. It then sends address that is no longer valid.
an unicast Neighbor Solicitations to each router's link-local address
it obtained from the lookup on the SDAT. The host MUST NOT send
unicast Neighbor Solicitations to a test node corresponding to an
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 Solicitation. Since sending NSs is just an parallel with the Router Solicitation. Since sending NSs is just an
optimization, doing the NSs and the RS 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 NOTE: A Simple DNA implementation SHOULD limit its probing to at most
six previously seen routers 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
skipping to change at page 10, line 37 skipping to change at page 10, line 37
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 that contains prefixes that On reception of a Router Advertisement that contains prefixes that
intersect with those previously advertised by a known router, the intersect with those previously advertised by a known router, the
host utilizes the configuration associated with the detected network. host utilizes the addresses in the SDAT associated with the detected
network.
If the host receives a router advertisement from a router containing If the host receives a router advertisement from a router containing
only prefixes that are disjoint from the prefixes associated with the only prefixes that are disjoint from the prefixes associated with the
same router in the SDAT, then the host MUST conclude that the IPv6 same router in the SDAT, then the host MUST conclude that the IPv6
addresses corresponding to that router are no longer valid. Since addresses corresponding to that router are no longer valid. Since
any NS probes to that router will no longer provide useful any NS probes to that router will no longer provide useful
information, further probing of that router MUST be aborted. information, further probing of that router MUST be aborted.
Furthermore, the host MUST remove all the SDAT entries corresponding Furthermore, the host MUST remove all the SDAT entries corresponding
to this router. to this router.
skipping to change at page 11, line 17 skipping to change at page 11, line 18
When the host receives a Router Advertisement from a given router, When the host receives a Router Advertisement from a given router,
the host MUST look for a Neighbor Cache entry for the sending router the host MUST look for a Neighbor Cache entry for the sending router
and MUST mark that router's Neighbor Cache Entry as REACHABLE if one and MUST mark that router's Neighbor Cache Entry as REACHABLE if one
was found. The host MUST add a new Neighbor Cache Entry in the was found. The host MUST add a new Neighbor Cache Entry in the
REACHABLE state for the sending router if one does not currently REACHABLE state for the sending router if 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
based probes complete with conflicting results. In this case, the
host SHOULD use the following rules to determine the final result.
o If the DHCPv6 exchange was authenticated, use the result from
DHCPv6.
o If the DHCPv6 exchange was not authenticated and the neighbor
discovery exchange was protected by SEND [RFC3971], use the result
from the neighbor discovery probe.
o If both the DHCPv6 and neighbor discovery exchanges were not
authenticated, use the result from DHCPv6.
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.
confirmed address was assigned manually, the implementation SHOULD
NOT unconfigure the manually assigned address and SHOULD log an error
about the mismatching prefix.
4.8. Further Host Operations 4.8. Further Host Operations
Operations subsequent to detecting network attachment depend upon Operations subsequent to detecting network attachment depend upon
whether change was detected. whether or not the host has reconnected to a previously visited
network.
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 Section o The host SHOULD select a default router as described in Section
6.3.6 of [RFC4861]. 6.3.6 of [RFC4861].
If the host has determined that there has been no link change, it If the host has determined that it has reattached to a previously
SHOULD NOT perform duplicate address detection on the addresses that visited link, it SHOULD NOT perform duplicate address detection on
have been confirmed to be operable. the addresses that 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 begin address configuration the ones in the SDAT the host MUST begin address configuration
techniques, as indicated in a received Router Advertisement techniques, as indicated in a received Router Advertisement
[RFC4861][RFC4862]. [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
skipping to change at page 12, line 39 skipping to change at page 12, line 23
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
Solicitations 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 or
Router Solicitation or DHCPv6 message, pending retransmissions MUST Router Solicitation message, pending retransmissions MUST be
be canceled [RFC3315][RFC3736]. A Simple DNA implementation SHOULD canceled. A Simple DNA implementation SHOULD NOT retransmit a
NOT retransmit a Neighbor Solicitation more than twice. To provide Neighbor Solicitation more than twice. To provide damping in the
damping in the case of spurious Link Up indications, the host SHOULD case of spurious Link Up indications, the host SHOULD NOT perform the
NOT perform the Simple DNA procedure more than once a second. Simple DNA procedure more than once a second.
5. Pseudocode for Simple DNA 5. 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
{ {
 End of changes. 14 change blocks. 
61 lines changed or deleted 39 lines changed or added

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