draft-ietf-dna-simple-04.txt   draft-ietf-dna-simple-05.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 30, 2009 October 27, 2008 Expires: May 7, 2009 November 3, 2008
Simple procedures for Detecting Network Attachment in IPv6 Simple procedures for Detecting Network Attachment in IPv6
draft-ietf-dna-simple-04 draft-ietf-dna-simple-05
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 30, 2009. This Internet-Draft will expire on May 7, 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. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 3
2.3. DNA Roles . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Link Identification model . . . . . . . . . . . . . . . . 4
2.4. Working Assumptions . . . . . . . . . . . . . . . . . . . 4 2.4. DNA Roles . . . . . . . . . . . . . . . . . . . . . . . . 4
2.5. 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 . . . . . . . . . . . . . . . . . . . 6
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 Neighbor Discovery probes . . . . . . . . . . . . 6 4.4. Sending Neighbor Discovery probes . . . . . . . . . . . . 6
4.5. Sending DHCPv6 probes . . . . . . . . . . . . . . . . . . 7 4.5. Contents of the Neighbor Discovery messages . . . . . . . 8
4.6. Response Gathering . . . . . . . . . . . . . . . . . . . . 8 4.5.1. Neighbor Solicitation messages . . . . . . . . . . . . 8
4.7. Further Host Operations . . . . . . . . . . . . . . . . . 8 4.5.2. Router Solicitation messages . . . . . . . . . . . . . 8
4.8. Recommended retransmission behavior . . . . . . . . . . . 9 4.6. Sending DHCPv6 probes . . . . . . . . . . . . . . . . . . 8
5. Router Operations . . . . . . . . . . . . . . . . . . . . . . 10 4.7. Response Gathering . . . . . . . . . . . . . . . . . . . . 9
5.1. DHCPv6 Router/Server Operations . . . . . . . . . . . . . 11 4.8. Further Host Operations . . . . . . . . . . . . . . . . . 10
6. Pseudocode for Simple DNA . . . . . . . . . . . . . . . . . . 11 4.9. Recommended retransmission behavior . . . . . . . . . . . 10
7. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Router Operations . . . . . . . . . . . . . . . . . . . . . . 11
8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. DHCPv6 Router/Server Operations . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. Pseudocode for Simple DNA . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . . 16 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
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 4, line 6 skipping to change at page 4, line 6
The Simple DNA protocol 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. Link Identification model
Earlier methods of detecting network attachment, e.g. the procedure
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
to the same link, all information related to the link such as the
routers, prefixes and configuration parameters was considered to be
valid. The Simple DNA protocol follows an alternate approach where
it relies on probing each previously known router to determine
whether to use information learnt from THAT router. This allows
simple DNA to probe routers learnt from multiple earlier attachments
to optimize movement between a known set of links.
2.4. 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 33 skipping to change at page 4, line 46
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 Additionally, on links with no statelessly configured addresses, the
host may make use of DHCPv6 procedures to identify an operable host may make use of DHCPv6 procedures to identify an operable
address. address.
2.4. 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 7, line 24 skipping to change at page 8, line 5
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. Sending DHCPv6 probes 4.5. Contents of the Neighbor Discovery messages
4.5.1. Neighbor Solicitation messages
This section describes the contents of the neighbor solicitation
probe messages sent during the probing procedure.
Source Address: A link-local address assigned to the
probing host.
Destination Address: The link-local address of the router being
probed as learnt from the SDAT.
Hop Limit: 255
ND Options:
Target Address: The link-local address of the router being
probed as learnt from the SDAT.
The probing node SHOULD NOT include a Source link-layer address
option if it has not performed duplicate address detection [RFC4862],
for the source address of the NS, on the newly attached link.
4.5.2. Router Solicitation messages
This section describes the contents of the router solicitation probe
message sent during the probing procedure.
Source Address: A link-local address assigned to the
probing host.
Destination Address: The all-routers multicast address.
Hop Limit: 255
The probing node SHOULD NOT include a Source link-layer address
option if it has not performed duplicate address detection [RFC4862],
for the source address of the NS, on the newly attached link.
4.6. Sending DHCPv6 probes
Where the host has acquired addresses from DHCPv6 or the host does 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 not have a global prefix, it MAY prefer to use DHCPv6 messages either
before or simultanously with Neighbour Discovery probing. before or simultanously with Neighbour Discovery probing.
In that case, when the host receives a link-layer indication, it In that case, when the host receives a link-layer indication, it
sends a DHCPv6 SOLICIT to All_DHCP_Relay_Agents_and_Servers. This sends a DHCPv6 SOLICIT to All_DHCP_Relay_Agents_and_Servers. This
message contains an Identity Addociation for either a Temporary message contains an Identity Addociation for either a Temporary
Address (IA_TA) or Non-Temporary Address (IA_NA) [RFC3315]. Where an Address (IA_TA) or Non-Temporary Address (IA_NA) [RFC3315]. Where an
existing valid address is being tested for operability, this address existing valid address is being tested for operability, this address
skipping to change at page 8, line 5 skipping to change at page 9, line 25
Where the Rapid-Commit option has not been used, a present DHCP Where the Rapid-Commit option has not been used, a present DHCP
server will respond with an ADVERTISE message. The IP address server will respond with an ADVERTISE message. The IP address
contained in the Identity Association (IA_TA or IA_NA) will contain contained in the Identity Association (IA_TA or IA_NA) will contain
an IP Address which is operable for the link. an IP Address which is operable for the link.
Where Rapid-Commit option has been sent, a DHCPv6 server will respond Where Rapid-Commit option has been sent, a DHCPv6 server will respond
with REPLY. In addition to being operable, this address is allocated with REPLY. In addition to being operable, this address is allocated
to the host for the lease duration indicated in the Identity to the host for the lease duration indicated in the Identity
Association. Association.
4.6. Response Gathering 4.7. 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 or advertising DHCPv6 message On reception of a Router Advertisement or advertising DHCPv6 message
(a REPLY or ADVERTISE) which contains prefixes that intersect with (a REPLY or ADVERTISE) which contains prefixes that intersect with
those previously advertised by a known router, the host utilizes the those previously advertised by a known router, the host utilizes the
skipping to change at page 8, line 38 skipping to change at page 10, line 10
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.7. 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 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 9, line 13 skipping to change at page 10, line 34
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.8. Recommended retransmission behavior 4.9. 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
 End of changes. 12 change blocks. 
29 lines changed or deleted 86 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/