draft-ietf-dna-simple-01.txt   draft-ietf-dna-simple-02.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: January 3, 2009 NetStar Networks Expires: January 11, 2009 NetStar Networks
July 2, 2008 July 10, 2008
Simple procedures for Detecting Network Attachment in IPv6 Simple procedures for Detecting Network Attachment in IPv6
draft-ietf-dna-simple-01 draft-ietf-dna-simple-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 3, 2009. This Internet-Draft will expire on January 11, 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 17 skipping to change at page 2, line 17
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. DNA Roles . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. DNA Roles . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 5 4. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Host data structures . . . . . . . . . . . . . . . . . . . 5 4.1. Host data structures . . . . . . . . . . . . . . . . . . . 5
4.2. Steps involved in detecting link change . . . . . . . . . 5 4.2. Steps involved in detecting link change . . . . . . . . . 5
4.3. Link-Layer Indication . . . . . . . . . . . . . . . . . . 5 4.3. Link-Layer Indication . . . . . . . . . . . . . . . . . . 5
4.4. Sending RS and NS probes . . . . . . . . . . . . . . . . . 6 4.4. Sending RS and NS probes . . . . . . . . . . . . . . . . . 6
4.5. Response Gathering . . . . . . . . . . . . . . . . . . . . 6 4.5. Response Gathering . . . . . . . . . . . . . . . . . . . . 7
4.6. Further Host Operations . . . . . . . . . . . . . . . . . 7 4.6. Further Host Operations . . . . . . . . . . . . . . . . . 7
4.7. Recommended retransmission behavior . . . . . . . . . . . 8 4.7. Recommended retransmission behavior . . . . . . . . . . . 8
5. Router Operations . . . . . . . . . . . . . . . . . . . . . . 8 5. Router Operations . . . . . . . . . . . . . . . . . . . . . . 9
6. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 13
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
skipping to change at page 3, line 35 skipping to change at page 3, line 35
detecting network attachment (Simple DNA) that has the following detecting network attachment (Simple DNA) that has the following
characteristics. characteristics.
o Routers do not have to be modified to support this scheme. o Routers do not have to be modified to support this scheme.
o Handle only the simplest and most likely use cases. o Handle only the simplest and most likely use cases.
o Work at least as quickly as standard neighbor discovery. o Work at least as quickly as standard neighbor discovery.
o False positives are not acceptable. A host should not conclude o False positives are not acceptable. A host should not conclude
that there is no link change when there is one that there is no link change when there is one.
o False negatives are acceptable. A host can conclude that there is o False negatives are acceptable. A host can conclude that there is
a link change when there is none a link change when there is none.
2.1. DNA Roles 2.1. 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
skipping to change at page 5, line 22 skipping to change at page 5, 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). Each entry in the SDAT table Simple DNA address table (SDAT). This data structure is maintained
by the host on a per interface basis. Each entry in the SDAT table
consists of at least the following parameters. 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.
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.
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 RS and NS probes
o Response gathering and assessment o Response gathering and assessment
skipping to change at page 6, line 7 skipping to change at page 6, line 8
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. change detection process completes. It SHOULD also set all Neighbor
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
link change has occurred.
4.4. Sending RS and NS probes 4.4. Sending RS and NS 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
skipping to change at page 6, line 30 skipping to change at page 6, line 34
For the purpose of sending neighbor solicitations to previous For the purpose of sending neighbor solicitations to previous
routers, the host first needs to pick a subset of operable IPv6 routers, the host first needs to pick a subset of operable IPv6
addresses (candidate set) that it wishes to use. How this subset of addresses (candidate set) that it wishes to use. How this subset of
addresses is picked is based on host configuration. e.g. The host addresses is picked is based on host configuration. e.g. The host
may select configured addresses from each of zero, one or two may select configured addresses from each of zero, one or two
previously connected links. If the addresses obtained from a previously connected links. If the addresses obtained from a
previous router are no longer valid, the host does include these previous router are no longer valid, the host does include these
addresses in the candidate set for NS based probing. addresses in the candidate set for NS based probing.
For each of the addresses in the candidate set, the host looks up the For each of the addresses in the candidate set, the host looks up the
SDAT to find out the link local and MAC addresses of the router that SDAT to find out the link-local and MAC addresses of the router that
advertised the prefix used to form the address. It then sends an advertised the prefix used to form the address. It then sends an
unicast Neighbor Solicitations to each router's link local address it unicast Neighbor Solicitations to each router's link-local address it
obtained from the lookup on the SDAT. The host SHOULD NOT send obtained from the lookup on the SDAT. The host SHOULD NOT send
unicast Neighbor Solicitations to a test node corresponding to an unicast Neighbor Solicitations to a test node corresponding to an
IPv6 address that is no longer valid. IPv6 address that is no longer valid.
Please note that the Neighbour Solicitations SHOULD be sent in Please note that the Neighbour Solicitations SHOULD be sent in
parallel with the Router Solicitations. Since sending NSs is just an parallel with the Router Solicitations. Since sending NSs is just an
optimization, doing the NSs and RSs in parallel ensures that the optimization, doing the NSs and RSs in parallel ensures that the
procedure does not run slower than it would if it only used an RS. procedure does not run slower than it would if it only used an RS.
Be aware that each unicast solicitation which is not successful may Be aware that each unicast solicitation which is not successful may
skipping to change at page 7, line 17 skipping to change at page 7, line 23
On reception of a Router Advertisement which contains prefixes which On reception of a Router Advertisement which contains prefixes which
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 configuration associated with the detected network.
When the host receives a router advertisement containing only When the host receives a router advertisement containing only
prefixes which are disjoint from known advertised prefixes, the host prefixes which are disjoint from known advertised prefixes, the host
MUST determine whether the solicited router advertisement corresponds MUST determine whether the solicited router advertisement corresponds
to any of the routers probed via NS. If it does, then the host to any of the routers probed via NS. If it does, then the host
SHOULD conclude that the IPv6 addresses corresponding to that router SHOULD conclude that the IPv6 addresses corresponding to that router
are no longer valid. Since any NS probes to that router will no are no longer valid. Since any NS probes to that router will no
longer provide useful information, probing of that router SHOULD be longer provide useful information, further probing of that router
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
Solicitation it sent, the host SHOULD look for a Neighbor Cache entry
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
Neighbor Cache Entry in the REACHABLE state for the sending router if
one does not currently exist.
4.6. Further Host Operations 4.6. 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.
o The host SHOULD select a default router as described in [RFC4861]. o The host SHOULD select a default router as described in [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.
skipping to change at page 8, line 39 skipping to change at page 8, line 47
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 [RFCDHCPv6], 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. A Simple DNA implementation SHOULD NOT retransmit a
Neighbor Solicitation more than twice. To provide damping in the Neighbor Solicitation more than twice. To provide damping in the
case of spurious Link Up indications, the host SHOULD NOT perform the case of spurious Link Up indications, the host SHOULD NOT perform the
the Simple DNA procedure more than once a second. 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].
skipping to change at page 10, line 7 skipping to change at page 10, line 15
Rate limitation for solicitations. Rate limitation for solicitations.
Hosts MAY implement hysteresis mechanisms to pace solicitations Hosts MAY implement hysteresis mechanisms to pace solicitations
where necessary to prevent damage to a particular medium. where necessary to prevent damage to a particular medium.
Implementors should be aware that when such hysteresis is Implementors should be aware that when such hysteresis is
triggered, Detecting Network Attachment may be slowed, which may triggered, Detecting Network Attachment may be slowed, which may
affect application traffic. affect application traffic.
8. IANA Considerations 8. IANA Considerations
There are no changes to IANA registries required in this document There are no changes to IANA registries required in this document.
9. Security Considerations 9. Security Considerations
When providing fast responses to router solicitations, it is possible When providing fast responses to router solicitations, it is possible
to cause collisions with other signaling packets on contention based to cause collisions with other signaling packets on contention based
media. This can cause repeated packet loss or delay when multiple media. This can cause repeated packet loss or delay when multiple
routers are present on the link. routers are present on the link.
As such the fast router advertisement system is NOT RECOMMENDED in As such the fast router advertisement system is NOT RECOMMENDED in
this form for media which are susceptible to collision loss. Such this form for media which are susceptible to collision loss. Such
 End of changes. 22 change blocks. 
23 lines changed or deleted 34 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/