draft-ietf-dna-simple-07.txt   draft-ietf-dna-simple-08.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: January 3, 2010 July 2, 2009 Expires: January 14, 2010 July 13, 2009
Simple procedures for Detecting Network Attachment in IPv6 Simple procedures for Detecting Network Attachment in IPv6
draft-ietf-dna-simple-07 draft-ietf-dna-simple-08
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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, 2010. This Internet-Draft will expire on January 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Link Identification model . . . . . . . . . . . . . . . . 4 2.3. Link Identification model . . . . . . . . . . . . . . . . 4
2.4. DNA Roles . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. DNA Roles . . . . . . . . . . . . . . . . . . . . . . . . 4
2.5. Working Assumptions . . . . . . . . . . . . . . . . . . . 4 2.5. Working Assumptions . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 5 4. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Host data structures . . . . . . . . . . . . . . . . . . . 6 4.1. Host data structures . . . . . . . . . . . . . . . . . . . 6
4.2. Steps involved in detecting link change . . . . . . . . . 6 4.2. Steps involved in detecting link change . . . . . . . . . 6
4.3. Link-Layer Indication . . . . . . . . . . . . . . . . . . 6 4.3. Link-Layer Indication . . . . . . . . . . . . . . . . . . 7
4.4. Sending Neighbor Discovery probes . . . . . . . . . . . . 6 4.4. Sending Neighbor Discovery probes . . . . . . . . . . . . 7
4.5. Contents of the Neighbor Discovery messages . . . . . . . 8 4.5. Contents of the Neighbor Discovery messages . . . . . . . 8
4.5.1. Neighbor Solicitation messages . . . . . . . . . . . . 8 4.5.1. Neighbor Solicitation messages . . . . . . . . . . . . 8
4.5.2. Router Solicitation messages . . . . . . . . . . . . . 8 4.5.2. Router Solicitation messages . . . . . . . . . . . . . 8
4.6. Sending DHCPv6 probes . . . . . . . . . . . . . . . . . . 8 4.6. Sending DHCPv6 probes . . . . . . . . . . . . . . . . . . 9
4.7. Response Gathering . . . . . . . . . . . . . . . . . . . . 9 4.7. Response Gathering . . . . . . . . . . . . . . . . . . . . 9
4.8. Further Host Operations . . . . . . . . . . . . . . . . . 10 4.8. Further Host Operations . . . . . . . . . . . . . . . . . 10
4.9. Recommended retransmission behavior . . . . . . . . . . . 10 4.9. Recommended retransmission behavior . . . . . . . . . . . 10
5. Router Operations . . . . . . . . . . . . . . . . . . . . . . 11 5. Pseudocode for Simple DNA . . . . . . . . . . . . . . . . . . 12
5.1. DHCPv6 Router/Server Operations . . . . . . . . . . . . . 12 6. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Pseudocode for Simple DNA . . . . . . . . . . . . . . . . . . 12 7. Relationship to DNAv4 . . . . . . . . . . . . . . . . . . . . 14
7. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Relationship to DNAv4 . . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
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 5, line 18 skipping to change at page 5, line 27
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 [RFC4861]. described in [RFC4861].
If systems do not meet these assumptions or if systems seek
deterministic change detection operations they are directed to follow
the complete dna procedure as defined in [I-D.ietf-dna-protocol].
3. Terminology 3. Terminology
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| Term | Definition | | Term | Definition |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| Valid IPv6 address | An IPv6 address configured on the node that | | Valid IPv6 address | An IPv6 address configured on the node that |
| | 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. |
skipping to change at page 6, line 43 skipping to change at page 7, line 12
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 be deprecated until the
change detection process completes. It SHOULD also set all Neighbor change detection process completes. It SHOULD also set all Neighbor
Cache entries for the routers on its Default Router List to STALE. Cache entries for the routers on its Default Router List to STALE.
This is done to speed up the acquisition of a new default router when This is done to speed up the acquisition of a new default router when
link change has occurred. link change has occurred.
4.4. Sending Neighbor Discovery probes 4.4. Sending Neighbor Discovery probes
When a host receives a link-layer "up" indication, it SHOULD When a host receives a link-layer "up" indication, it SHOULD
immediately send both a Router Solicitation and if it retains at immediately send both a Router Solicitation 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
link-local address 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 identifies the set of operable IPv6 addresses
addresses (candidate set) that it wishes to use. How this subset of (candidate set) that it wishes to use. If the addresses obtained
addresses is picked is based on host configuration. e.g. The host from a previous router are no longer valid, the host does not include
may select configured addresses from each of zero, one or two these addresses in the candidate set for NS based probing.
previously connected links. If the addresses obtained from a
previous router are no longer valid, the host does not include these
addresses in the candidate set for NS based probing.
For each of the addresses in the candidate set, the host looks up the For each of the addresses in the candidate set, the host looks up the
SDAT to find out the link-local and MAC addresses of the router that SDAT to find out the link-local and MAC addresses of the router 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
cause packet flooding in bridged networks, if the networks are not
properly configured. This is further described in Section 9. Where
flooding may cause performance issues within the LAN, host SHOULD
limit the number of unicast solicitations.
4.5. Contents of the Neighbor Discovery messages 4.5. Contents of the Neighbor Discovery messages
4.5.1. Neighbor Solicitation messages 4.5.1. Neighbor Solicitation messages
This section describes the contents of the neighbor solicitation This section describes the contents of the neighbor solicitation
probe messages sent during the probing procedure. probe messages sent during the probing procedure.
Source Address: A link-local address assigned to the Source Address: A link-local address assigned to the
probing host. probing host.
skipping to change at page 8, line 26 skipping to change at page 8, line 26
probed as learnt from the SDAT. probed as learnt from the SDAT.
Hop Limit: 255 Hop Limit: 255
ND Options: ND Options:
Target Address: The link-local address of the router being Target Address: The link-local address of the router being
probed as learnt from the SDAT. probed as learnt from the SDAT.
The probing node SHOULD include a Source link-layer address option in The probing node SHOULD include a Source link-layer address option in
the probe messages. If the node believes that the source address of the probe messages if the address was obtained using DHCPv6 and the
the NS may not be unique on the newly attached link, it MAY omit the lease has not expired. Otherwise the probing node SHOULD NOT include
Source link-layer address option in the probe messages. the Source link-layer address option in the probe messages.
4.5.2. Router Solicitation messages 4.5.2. Router Solicitation messages
This section describes the contents of the router solicitation probe This section describes the contents of the router solicitation probe
message sent during the probing procedure. message sent during the probing procedure.
Source Address: A link-local address assigned to the Source Address: A link-local address assigned to the
probing host. probing host.
Destination Address: The all-routers multicast address. Destination Address: The all-routers multicast address.
Hop Limit: 255 Hop Limit: 255
The probing node SHOULD NOT include a Source link-layer address The probing node SHOULD include a Source link-layer address option in
option if it has not performed duplicate address detection [RFC4862], the probe messages if the address was obtained using DHCPv6 and the
for the source address of the NS, on the newly attached link. lease has not expired. Otherwise the probing node SHOULD NOT include
the Source link-layer address option in the probe messages.
4.6. Sending DHCPv6 probes 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 Association 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
should be placed in the Identity Association's IAADDR element, and should be placed in the Identity Association's IAADDR element, and
the DUID associated with that address should be copied to the DHCP the DUID associated with that address should be copied to the DHCP
SOLICIT from the SDAT. SOLICIT from the SDAT.
In order to quickly acquire a new address in the case that link In order to quickly acquire a new address in the case that link
change has occurred, this SOLICIT message MAY contain the Rapid- change has occurred, this SOLICIT message MAY contain the Rapid-
Commit option. Commit option.
skipping to change at page 11, line 23 skipping to change at page 12, line 5
[RFC3315], scheduling DNAv6 retransmissions between Router [RFC3315], 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 [RFC3315][RFC3736]. A Simple DNA implementation SHOULD be canceled [RFC3315][RFC3736]. A Simple DNA implementation SHOULD
NOT retransmit a Neighbor Solicitation more than twice. To provide NOT retransmit a Neighbor Solicitation more than twice. To provide
damping in the case of spurious Link Up indications, the host SHOULD damping in the case of spurious Link Up indications, the host SHOULD
NOT perform the Simple DNA procedure more than once a second. NOT perform the Simple DNA procedure more than once a second.
5. Router Operations 5. Pseudocode for Simple DNA
Hosts checking their network attachment are unsure of their address
status, and may be using Tentative link-layer addressing information
in their router or neighbour solicitations.
A router which desires to support hosts' DNA operations MUST process
Tentative Options from unicast source addressed Router and Neighbour
Solicitations, as described in [I-D.ietf-dna-tentative].
5.1. DHCPv6 Router/Server Operations
DHCPv6 Server operations occur in accordance with the DHCPv6 RFC
[RFC3315].
6. 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
{ {
if (Get_Address_State(Configured_Address)!=AS_TENTATIVE) if (Get_Address_State(Configured_Address)!=AS_TENTATIVE)
{ {
skipping to change at page 14, line 4 skipping to change at page 13, line 44
L3_Source=Get_L3_Source(RECEIVED_MESSAGE); L3_Source=Get_L3_Source(RECEIVED_MESSAGE);
L2_Source=Get_L2_Source(RECEIVED_MESSAGE); L2_Source=Get_L2_Source(RECEIVED_MESSAGE);
if (Is_Router_on_NA_Ignore_List(L3_Source)) { if (Is_Router_on_NA_Ignore_List(L3_Source)) {
/* Ignore message and wait for next message */ /* Ignore message and wait for next message */
continue; continue;
} }
SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source)); SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source));
foreach SDAT_Entry in SDAT_Entry_List foreach SDAT_Entry in SDAT_Entry_List
{ {
/* Address is operable. Configure on Interface */ /* Address is operable. Configure on Interface */
} }
Figure 1: Pseudocode for Simple DNA Figure 1: Pseudocode for Simple DNA
7. Constants 6. Constants
These constants are described as in [I-D.ietf-dna-protocol].
UNICAST_RA_INTERVAL
Definition: The interval corresponding to the maximum average
rate of Router Solicitations that the router is prepared to
service with unicast responses. This is the interval at which
the token bucket controlling the unicast responses is
replenished.
Value: 50 milliseconds
MAX_UNICAST_RA_BURST
Definition: The maximum size burst of Router Solicitations that
the router is prepared to service with unicast responses. This
is the maximum number of tokens allowed in the token bucket
controlling the unicast responses.
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
8. Relationship to DNAv4 7. Relationship to DNAv4
DNAv4 [RFC4436] specifies a set of steps that optimize the (common) DNAv4 [RFC4436] specifies a set of steps that optimize the (common)
case of re-attachment to an IPv4 network that one has been connected case of re-attachment to an IPv4 network that one has been connected
to previously by attempting to re-use a previous (but still valid) to previously by attempting to re-use a previous (but still valid)
configuration. This document shares the same goal as DNAv4 (that of configuration. This document shares the same goal as DNAv4 (that of
minimizing the handover latency in moving between points of minimizing the handover latency in moving between points of
attachment) but differs in the steps it performs to achieve this attachment) but differs in the steps it performs to achieve this
goal. Another difference is that this document also supports goal. Another difference is that this document also supports
stateless autoconfiguration of addresses in addition to addresses stateless autoconfiguration of addresses in addition to addresses
configured using DHCPv6. configured using DHCPv6.
9. Open Issues 8. IANA Considerations
This section documents issues that are still outstanding within the
document, and the simple DNA solution in general.
Rate limitation for solicitations.
Hosts MAY implement hysteresis mechanisms to pace solicitations
where necessary to prevent damage to a particular medium.
Implementors should be aware that when such hysteresis is
triggered, Detecting Network Attachment may be slowed, which may
affect application traffic.
10. IANA Considerations
There are no changes to IANA registries required in this document. There are no changes to IANA registries required in this document.
11. Security Considerations 9. Security Considerations
When providing fast responses to router solicitations, it is possible
to cause collisions with other signaling packets on contention based
media. This can cause repeated packet loss or delay when multiple
routers are present on the link.
As such the fast router advertisement system is NOT RECOMMENDED in
this form for media which are susceptible to collision loss. Such
environments may be better served using the procedures defined in
[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 [RFC3971] router information is that the host's current secured SEND [RFC3971] router information is
not replaced by an attacker which spoofs an RA and purports to change not replaced by an attacker which spoofs an RA and purports to change
the 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 4.3. 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 If the current default router is a SEND-secured router, the host
adopting a new default router, if it is operating on a network where SHOULD wait SEND_NA_GRACE_TIME after transmission before adopting a
there is significant threat of RA spoofing. new default router.
Even if SEND signatures on RAs are used, it may not be immediately Even if SEND signatures on RAs are used, it may not be immediately
clear if the router is authorized to make such advertisements. As clear if the router is authorized to make such advertisements. As
such, a host SHOULD NOT treat such devices as secure until and unless such, a host SHOULD NOT treat such devices as secure until and unless
authorization delegation discovery is successful. authorization delegation discovery is successful.
It is easy for hosts soliciting without SEND to deplete a SEND 10. Acknowledgments
router's fast advertisement token buckets, and consume additional
bandwidth. As such, a router MAY choose to preserve a portion of
their token bucket to serve solicitations with SEND signatures.
12. 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, Julien Laganier, Domagoj Aboba, Thomas Narten, Jari Arkko, Sathya Narayan, Julien Laganier,
Premec, Jin Hyeock-Choi, Alfred Hoenes and Frederic Rossi for 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.
13. References 11. References
13.1. Normative References
[I-D.ietf-dna-tentative] 11.1. Normative References
Daley, G., Nordmark, E., and N. Moore, "Tentative Options
for IPv6 Neighbour Discovery", draft-ietf-dna-tentative-01
(work in progress), July 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004. (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3971] 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.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
13.2. Informative References 11.2. Informative References
[I-D.ietf-dna-protocol] [I-D.ietf-dna-protocol]
Narayanan, S., "Detecting Network Attachment in IPv6 Narayanan, S., "Detecting Network Attachment in IPv6
Networks (DNAv6)", draft-ietf-dna-protocol (work in Networks (DNAv6)", draft-ietf-dna-protocol (work in
progress), June 2007. progress), June 2007.
[RFC4957] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S., [RFC4957] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S.,
and A. Yegin, "Link-Layer Event Notifications for and A. Yegin, "Link-Layer Event Notifications for
Detecting Network Attachments", RFC 4957, August 2007. Detecting Network Attachments", RFC 4957, August 2007.
 End of changes. 28 change blocks. 
130 lines changed or deleted 47 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/