draft-ietf-dna-simple-00.txt   draft-ietf-dna-simple-01.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: October 6, 2008 NetStar Networks Expires: January 3, 2009 NetStar Networks
April 4, 2008 July 2, 2008
Simple procedures for Detecting Network Attachment in IPv6 Simple procedures for Detecting Network Attachment in IPv6
draft-ietf-dna-simple-00 draft-ietf-dna-simple-01
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 October 6, 2008. This Internet-Draft will expire on January 3, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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. DNA Roles . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. DNA Roles . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
3. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Host data structures . . . . . . . . . . . . . . . . . . . 5 4. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Link-Layer Indication . . . . . . . . . . . . . . . . . . 5 4.1. Host data structures . . . . . . . . . . . . . . . . . . . 5
3.3. Optimistic DAD . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Steps involved in detecting link change . . . . . . . . . 5
3.4. Sending RS and NS probes . . . . . . . . . . . . . . . . . 6 4.3. Link-Layer Indication . . . . . . . . . . . . . . . . . . 5
3.5. Response Gathering . . . . . . . . . . . . . . . . . . . . 6 4.4. Sending RS and NS probes . . . . . . . . . . . . . . . . . 6
3.6. Further Host Operations . . . . . . . . . . . . . . . . . 7 4.5. Response Gathering . . . . . . . . . . . . . . . . . . . . 6
3.7. Recommended retransmission behavior . . . . . . . . . . . 7 4.6. Further Host Operations . . . . . . . . . . . . . . . . . 7
4. Router Operations . . . . . . . . . . . . . . . . . . . . . . 8 4.7. Recommended retransmission behavior . . . . . . . . . . . 8
5. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Router Operations . . . . . . . . . . . . . . . . . . . . . . 8
6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . . 11
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 [1]. 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 to the one which they have been moved to a different IP network to the one which they have been
recently connected. In order to detect change, router and neighbour recently connected. In order to detect change, router and neighbour
discovery messages are used to collect reachability and configuration discovery messages are used to collect reachability and configuration
information. This information is used to detect whether the existing information. This information is used to detect whether the existing
router and address prefixes are likely to be present. router and address prefixes are likely to be present.
skipping to change at page 3, line 48 skipping to change at page 3, line 48
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 [2] will delay the standard neighbor discovery procedure described in [RFC4861] will
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
of [2]. This delay can be significant and may result in service of [RFC4861]. This delay can be significant and may result in
disruption. Please note that support for fast unicast RAs is not service disruption. Please note that support for fast unicast RAs is
necessary since the simple dna procedure can continue to work using not necessary since the simple dna procedure can continue to work
the NS/NA exchange, which will complete earlier than the RA arrives. using the NS/NA exchange, which will complete earlier than the RA
arrives.
The host detects that the link-layer may have changed, and then The host detects that the link-layer may have changed, and then
simultaneously probes the network with Router Solicitations (RSs) and simultaneously probes the network with Router Solicitations (RSs) and
Neighbour Solicitations (NSs). The host uses advertisements to Neighbour Solicitations (NSs). The host uses advertisements to
determine if the routers it currently has configured are still determine if the routers it currently has configured are still
available. available.
2.2. Applicability 2.2. Applicability
There are a series of assumptions about the network environment which There are a series of assumptions about the network environment which
skipping to change at page 4, line 30 skipping to change at page 4, line 31
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.
If these assumptions do not hold, host change detection systems will If these assumptions do not hold, host change detection systems will
not function optimally. In that case, they may occasionally detect not function optimally. In that case, they may occasionally detect
change spuriously, or experience some delay in detecting network change spuriously, or experience some delay in detecting network
attachment. The delays so experienced will be no longer than those attachment. The delays so experienced will be no longer than those
caused by following the standard neighbor discovery procedure caused by following the standard neighbor discovery procedure
described in [2]. described in [RFC4861].
If systems do not meet these assumptions or if systems seek If systems do not meet these assumptions or if systems seek
deterministic change detection operations they are directed to follow deterministic change detection operations they are directed to follow
the complete dna procedure as defined in [6]. the complete dna procedure as defined in [I-D.ietf-dna-protocol].
3. Host Operations 3. Terminology
+---------------------+---------------------------------------------+
| Term | Definition |
+---------------------+---------------------------------------------+
| Valid IPv6 address | An IPv6 address configured on the node that |
| | has a valid lifetime greater than zero. |
| | |
| Operable IPv6 | An IPv6 address configured on the node that |
| address | can be used safely on the current link. |
+---------------------+---------------------------------------------+
Table 1: Simple DNA Terminology
4. Host Operations
When a host has an existing configuration for IP address prefixes and When a host has an existing configuration for IP address prefixes and
next hop routing, it may be disconnected from its link-layer, and next hop routing, it may be disconnected from its link-layer, and
then subsequently reconnect the link-layer on the same interface. then subsequently reconnect the link-layer on the same interface.
When the link-layer becomes available again, it is important to When the link-layer becomes available again, it is important to
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.
3.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). 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
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 Optimistic DAD
o Sending RS and NS probes o Sending RS and NS probes
o Response gathering and assessment o Response gathering and assessment
These steps are described below. These steps are described below.
3.2. 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 [7]. available [RFC4957].
When the indication is received, the host marks all currently
configured (non-tentative) IP addresses to Optimistic state [5].
3.3. Optimistic DAD
All Router Solicitations and unicast Neighbour Solicitations sent for
DNA purposes while addresses are in optimistic state SHOULD include
the Tentative Option [4].
This allows for DAD-safe transmission of unicast response to After the indication is received, the host considers all currently
solicitation, even if the router has no existing Neighbour Cache configured (non-tentative) IP addresses to as deprecated until the
entry for the solicitor. change detection process completes.
3.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 containing one of the host's optimistic unicast multicast address using a link-local address as the source address
source address [2][5]. If the host is in possession of more than one [RFC4861]. Even if the host is in possession of more than one valid
valid IPv6 address, it MUST send only one router solicitation using IPv6 address, it MUST send only one router solicitation using a valid
any one of its valid IPv6 addresses as the source address.. 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 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.
skipping to change at page 6, line 40 skipping to change at page 6, line 44
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
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 6. Where properly configured. This is further described in Section 7. 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.
3.5. Response Gathering 4.5. Response Gathering
When a responding Neighbour Advertisement is received from a test When a responding Neighbour Advertisement is received from a test
node, the host MUST verify that both the IPv6 and link layer (MAC) node, the host MUST verify that both the IPv6 and link layer (MAC)
addresses of the test node match the expected values before utilizing addresses of the test node match the expected values before utilizing
the configuration associated with the detected network (prefixes, MTU the configuration associated with the detected network (prefixes, MTU
etc.). etc.).
On reception of a Router Advertisement which contains prefixes which On reception of a Router Advertisement 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.
skipping to change at page 7, line 21 skipping to change at page 7, line 25
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, probing of that router SHOULD be
aborted. 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.
3.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 should assess whether it can use the existing NS/NA pair, the host performs the following steps
configured addresses using Optimistic Duplicate Address Detection
[5].
Also, the host SHOULD rejoin any solicited nodes' multicast groups o The host SHOULD rejoin any solicited nodes' multicast groups for
for addresses it continues to use, and select a default router [2]. addresses it continues to use.
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
SHOULD NOT perform duplicate address detection on 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 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 [2][8]. Advertisement [RFC4861][RFC4862].
3.7. Recommended retransmission behavior 4.7. Recommended retransmission behavior
In situations where Neighbor Solicitation probes and Router In situations where Neighbor Solicitation probes and Router
Solicitation probes are used on the same link, it is possible that Solicitation probes are used on the same link, it is possible that
the NS probe will complete successfully, and then the RS probe will the NS probe will complete successfully, and then the RS probe will
complete later with a different result. If this happens, the complete later with a different result. If this happens, the
implementation SHOULD abandon the results obtained from the NS probe implementation SHOULD abandon the results obtained from the NS probe
of the router that responded to the RS and the implementation SHOULD of the router that responded to the RS and the implementation SHOULD
behave as if the NS probe did not successfully complete. If the behave as if the NS probe did not successfully complete. If the
confirmed address was assigned manually, the implementation SHOULD confirmed address was assigned manually, the implementation SHOULD
NOT unconfigure the manually assigned address and SHOULD log an error NOT unconfigure the manually assigned address and SHOULD log an error
skipping to change at page 8, line 29 skipping to change at page 8, line 41
[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. the Simple DNA procedure more than once a second.
4. 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 [4]. Solicitations, as described in [I-D.ietf-dna-tentative].
5. Constants 6. Constants
These constants are described as in [6]. These constants are described as in [I-D.ietf-dna-protocol].
UNICAST_RA_INTERVAL UNICAST_RA_INTERVAL
Definition: The interval corresponding to the maximum average Definition: The interval corresponding to the maximum average
rate of Router Solicitations that the router is prepared to rate of Router Solicitations that the router is prepared to
service with unicast responses. This is the interval at which service with unicast responses. This is the interval at which
the token bucket controlling the unicast responses is the token bucket controlling the unicast responses is
replenished. replenished.
Value: 50 milliseconds Value: 50 milliseconds
skipping to change at page 9, line 24 skipping to change at page 9, line 36
Value: 20 Value: 20
SEND_NA_GRACE_TIME SEND_NA_GRACE_TIME
Definition: An optional period to wait after Neighbour Definition: An optional period to wait after Neighbour
Solicitation before adopting a non-SEND RA's link change Solicitation before adopting a non-SEND RA's link change
information. information.
Value: 40 milliseconds Value: 40 milliseconds
6. Open Issues 7. Open Issues
This section documents issues that are still outstanding within the This section documents issues that are still outstanding within the
document, and the simple DNA solution in general. document, and the simple DNA solution in general.
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.
7. 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
8. 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
environments may be better served using the procedures defined in environments may be better served using the procedures defined in
[6]. [I-D.ietf-dna-protocol].
A host may receive Router Advertisements from non SEND devices, after A host may receive Router Advertisements from non SEND devices, after
receiving a link-layer indications. While it is necessary to assess receiving a link-layer indications. While it is necessary to assess
quickly whether a host has moved to another network, it is important quickly whether a host has moved to another network, it is important
that the host's current secured SEND [3] router information is not that the host's current secured SEND [RFC3971] router information is
replaced by an attacker which spoofs an RA and purports to change the not replaced by an attacker which spoofs an RA and purports to change
link. the link.
As such, the host SHOULD send a Neighbour Solicitation to the As such, the host SHOULD send a Neighbour Solicitation to the
existing SEND router upon link-up indication as described above in existing SEND router upon link-up indication as described above in
Section 3.2. The host SHOULD then ensure that unsecured router Section 4.3. The host SHOULD then ensure that unsecured router
information does not cause deletion of existing SEND state, within information does not cause deletion of existing SEND state, within
MIN_DELAY_BETWEEN_RAS, in order to allow for a present SEND router to MIN_DELAY_BETWEEN_RAS, in order to allow for a present SEND router to
respond. respond.
The host MAY delay SEND_NA_GRACE_TIME after transmission before The host MAY delay SEND_NA_GRACE_TIME after transmission before
adopting a new default router, if it is operating on a network where adopting a new default router, if it is operating on a network where
there is significant threat of RA spoofing. there is significant threat of RA spoofing.
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.
It is easy for hosts soliciting without SEND to deplete a SEND It is easy for hosts soliciting without SEND to deplete a SEND
router's fast advertisement token buckets, and consume additional router's fast advertisement token buckets, and consume additional
bandwidth. As such, a router MAY choose to preserve a portion of bandwidth. As such, a router MAY choose to preserve a portion of
their token bucket to serve solicitations with SEND signatures. their token bucket to serve solicitations with SEND signatures.
9. Acknowledgments 10. Acknowledgments
This document is the product of a discussion between the authors had This document is the product of a discussion between the authors had
with Bernard Aboba, Thomas Narten, Erik Nordmark and Dave Thaler at with Bernard Aboba, Thomas Narten, Erik Nordmark and Dave Thaler at
IETF 69. The authors would like to thank them for clearly detailing IETF 69. The authors would like to thank them for clearly detailing
the requirements of the solution and the goals it needed to meet and the requirements of the solution and the goals it needed to meet and
for helping to explore the solution space. The authors would like to for 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, Sathya Narayan and Frederic Rossi for Aboba, Thomas Narten, Sathya Narayan, Julien Laganier, Domagoj
Premec, Jin Hyeock-Choi, Alfred Hoenes and Frederic Rossi for
performing reviews on the document and providing valuable comments to performing reviews on the document and providing valuable comments to
drive the document forward. drive the document forward.
10. References 11. References
10.1. Normative References 11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery [RFC4861] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
for IP Version 6 (IPv6)", RFC 4861, December 1998. Discovery for IP Version 6 (IPv6)", RFC 4861,
December 1998.
[3] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[4] Daley, G., Nordmark, E., and N. Moore, "Tentative Options for [I-D.ietf-dna-tentative]
IPv6 Neighbour Discovery", draft-ietf-dna-tentative-01 (work in Daley, G., Nordmark, E., and N. Moore, "Tentative Options
progress), July 2007. for IPv6 Neighbour Discovery", draft-ietf-dna-tentative-01
(work in progress), July 2007.
[5] Moore, N., "Optimistic Duplicate Address Detection for IPv6",
RFC RFC4429, April 2006.
[6] Narayanan, S., "Detecting Network Attachment in IPv6 Networks [I-D.ietf-dna-protocol]
(DNAv6)", draft-ietf-dna-protocol (work in progress), June 2007. Narayanan, S., "Detecting Network Attachment in IPv6
Networks (DNAv6)", draft-ietf-dna-protocol (work in
progress), June 2007.
10.2. Informative References 11.2. Informative References
[7] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S., and A. [RFC4957] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S.,
Yegin, "Link-Layer Event Notifications for Detecting Network and A. Yegin, "Link-Layer Event Notifications for
Attachments", RFC 4957, August 2007. Detecting Network Attachments", RFC 4957, August 2007.
[8] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
Authors' Addresses Authors' Addresses
Suresh Krishnan Suresh Krishnan
Ericsson Ericsson
8400 Decarie Blvd. 8400 Decarie Blvd.
Town of Mount Royal, QC Town of Mount Royal, QC
Canada Canada
Phone: +1 514 345 7900 x42871 Phone: +1 514 345 7900 x42871
skipping to change at page 13, line 44 skipping to change at line 551
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 49 change blocks. 
104 lines changed or deleted 113 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/