Network Working Group S. Krishnan
Internet-Draft Ericsson
Updates: 4861 (if approved) G. Daley
Intended status: Standards Track NetStar Networks
Expires: August 28, 2009 February 24, 2009
Simple procedures for Detecting Network Attachment in IPv6
draft-ietf-dna-simple-06
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 28, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract
Detecting Network Attachment allows hosts to assess if its existing
Krishnan & Daley Expires August 28, 2009 [Page 1]
Internet-Draft Simple DNA February 2009
addressing or routing configuration is valid for a newly connected
network.
This document provides simple procedures for detecting network
attachment in IPv6 hosts, and procedures for routers to support such
services.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Link Identification model . . . . . . . . . . . . . . . . 4
2.4. DNA Roles . . . . . . . . . . . . . . . . . . . . . . . . 4
2.5. Working Assumptions . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Host data structures . . . . . . . . . . . . . . . . . . . 6
4.2. Steps involved in detecting link change . . . . . . . . . 6
4.3. Link-Layer Indication . . . . . . . . . . . . . . . . . . 6
4.4. Sending Neighbor Discovery probes . . . . . . . . . . . . 6
4.5. Contents of the Neighbor Discovery messages . . . . . . . 8
4.5.1. Neighbor Solicitation messages . . . . . . . . . . . . 8
4.5.2. Router Solicitation messages . . . . . . . . . . . . . 8
4.6. Sending DHCPv6 probes . . . . . . . . . . . . . . . . . . 8
4.7. Response Gathering . . . . . . . . . . . . . . . . . . . . 9
4.8. Further Host Operations . . . . . . . . . . . . . . . . . 10
4.9. Recommended retransmission behavior . . . . . . . . . . . 10
5. Router Operations . . . . . . . . . . . . . . . . . . . . . . 11
5.1. DHCPv6 Router/Server Operations . . . . . . . . . . . . . 12
6. Pseudocode for Simple DNA . . . . . . . . . . . . . . . . . . 12
7. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Relationship to DNAv4 . . . . . . . . . . . . . . . . . . . . 14
9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. Security Considerations . . . . . . . . . . . . . . . . . . . 15
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Krishnan & Daley Expires August 28, 2009 [Page 2]
Internet-Draft Simple DNA February 2009
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction
Hosts require procedures to simply and reliably identify if they have
moved to a different IP network to the one which they have been
recently connected. In order to detect change, router and neighbour
discovery messages are used to collect reachability and configuration
information. This information is used to detect whether the existing
router and address prefixes are likely to be present.
This document incorporates feedback from host and router operating
systems implementors, which seeks to make implementation and adoption
of IPv6 change detection procedures simple for general use.
2.1. Goals
The goal of this document is to specify a simple procedure for
detecting network attachment (Simple DNA) that has the following
characteristics.
o Routers do not have to be modified to support this scheme.
o Handle only the simplest and most likely use cases.
o Work at least as quickly as standard neighbor discovery.
o False positives are not acceptable. A host should not conclude
that there is no link change when there is one.
o False negatives are acceptable. A host can conclude that there is
a link change when there is none.
2.2. Applicability
The Simple DNA protocol provides substantial benefits in some
scenarios and does not provide any benefit at all in certain other
scenarios. This is intentional as Simple DNA was designed for
simplicity rather than completeness. In particular, the Simple DNA
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
is previously unknown, the performance of the Simple DNA protocol
will be identical to that using standard neighbor discovery
Krishnan & Daley Expires August 28, 2009 [Page 3]
Internet-Draft Simple DNA February 2009
procedures [RFC4861].
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
neighbour discovery and router discovery messages to routers after
connecting to a network.
It is desirable that routers adopt procedures which allow for fast
unicast Router Advertisement (RA) messages. Routers that follow the
standard neighbor discovery procedure described in [RFC4861] will
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
of [RFC4861]. This delay can be significant and may result in
service disruption. Please note that support for fast unicast RAs is
not necessary since the simple dna procedure can continue to work
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
simultaneously probes the network with Router Solicitations (RSs) and
Neighbour Solicitations (NSs). The host uses advertisements to
determine if the routers it currently has configured are still
available.
Additionally, on links with no statelessly configured addresses, the
host may make use of DHCPv6 procedures to identify an operable
address.
2.5. Working Assumptions
There are a series of assumptions about the network environment which
underpin these procedures.
Krishnan & Daley Expires August 28, 2009 [Page 4]
Internet-Draft Simple DNA February 2009
o The combination of the link layer address and the link local IPv6
address of a router is unique across links.
o Hosts receive indications when a link-layer comes up. Without
this, they would not know when to commence the DNA procedure.
If these assumptions do not hold, host change detection systems will
not function optimally. In that case, they may occasionally detect
change spuriously, or experience some delay in detecting network
attachment. The delays so experienced will be no longer than those
caused by following the standard neighbor discovery procedure
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
+---------------------+---------------------------------------------+
| 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
next hop routing, it may be disconnected from its link-layer, and
then subsequently reconnect the link-layer on the same interface.
When the link-layer becomes available again, it is important to
determine whether the existing addressing and routing configuration
are still valid.
In order to determine this, the host performs the detecting network
attachment procedure.
Krishnan & Daley Expires August 28, 2009 [Page 5]
Internet-Draft Simple DNA February 2009
4.1. Host data structures
In order to correctly perform the procedure described in this
document the host needs to maintain a data structure called the
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.
o IPv6 address and its related parameters like valid lifetime.
o Prefix from which the address was formed.
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 DHCP Unique IDentifier (DUID) in case DHCPv6 was used to acquire
the address [RFC3315].
4.2. Steps involved in detecting link change
The steps involved in basic detection of network attachment are:
o Link-Layer Indication
o Sending of neighbour discovery or DHCPv6 probes
o Response gathering and assessment
These steps are described below.
4.3. Link-Layer Indication
In order to start Detection of network attachment procedures, a host
typically requires a link-layer indication that the medium has become
available [RFC4957].
After the indication is received, the host considers all currently
configured (non-tentative) IP addresses to as deprecated until the
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 Neighbor Discovery probes
When a host receives a link-layer "up" indication, it SHOULD
immediately send both a Router Solicitation and if it retains at
Krishnan & Daley Expires August 28, 2009 [Page 6]
Internet-Draft Simple DNA February 2009
least one valid IPv6 address, one or more unicast Neighbor
Solicitations. The Router Solicitation is sent to the All-routers
multicast address using a link-local address as the source address
[RFC4861]. Even if the host is in possession of more than one valid
IPv6 address, it MUST send only one router solicitation using a valid
link-local address as the source address.
For the purpose of sending neighbor solicitations to previous
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 is picked is based on host configuration. e.g. The host
may select configured addresses from each of zero, one or two
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
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
unicast Neighbor Solicitations to each router's link-local address it
obtained from the lookup on the SDAT. The host SHOULD NOT send
unicast Neighbor Solicitations to a test node corresponding to an
IPv6 address that is no longer valid.
Please note that the Neighbour Solicitations SHOULD be sent in
parallel with the Router Solicitations. Since sending NSs is just an
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.
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.
Krishnan & Daley Expires August 28, 2009 [Page 7]
Internet-Draft Simple DNA February 2009
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 include a Source link-layer address option in
the probe messages. If the node believes that the source address of
the NS may not be unique on the newly attached link, it MAY omit the
Source link-layer address option in the probe messages.
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
not have a global prefix, it MAY prefer to use DHCPv6 messages either
before or simultanously with Neighbour Discovery probing.
In that case, when the host receives a link-layer indication, it
Krishnan & Daley Expires August 28, 2009 [Page 8]
Internet-Draft Simple DNA February 2009
sends a DHCPv6 SOLICIT to All_DHCP_Relay_Agents_and_Servers. This
message contains an Identity Addociation for either a Temporary
Address (IA_TA) or Non-Temporary Address (IA_NA) [RFC3315]. Where an
existing valid address is being tested for operability, this address
should be placed in the Identity Association's IAADDR element, and
the DUID associated with that address should be copied to the DHCP
SOLICIT from the SDAT.
In order to quickly acquire a new address in the case that link
change has occurred, this SOLICIT message MAY contain the Rapid-
Commit option.
Where the Rapid-Commit option has not been used, a present DHCP
server will respond with an ADVERTISE message. The IP address
contained in the Identity Association (IA_TA or IA_NA) will contain
an IP Address which is operable for the link.
Where Rapid-Commit option has been sent, a DHCPv6 server will respond
with REPLY. In addition to being operable, this address is allocated
to the host for the lease duration indicated in the Identity
Association.
4.7. Response Gathering
When a responding Neighbour Advertisement is received from a test
node, the host MUST verify that both the IPv6 and link layer (MAC)
addresses of the test node match the expected values before utilizing
the configuration associated with the detected network (prefixes, MTU
etc.).
On reception of a Router Advertisement or advertising DHCPv6 message
(a REPLY or ADVERTISE) which contains prefixes that intersect with
those previously advertised by a known router, the host utilizes the
configuration associated with the detected network.
When the host receives an advertisement containing only prefixes
which are disjoint from known advertised prefixes, the host MUST
determine whether the solicited advertisement corresponds to any of
the routers probed via NS. If it does, then the host SHOULD conclude
that the IPv6 addresses corresponding to that router are no longer
valid. Since any NS probes to that router will no longer provide
useful information, further probing of that router SHOULD be aborted.
Where the conclusions obtained from the Neighbor Solicitation/
Advertisement from a given router and the RS/RA exchange with the
same router differ, the results obtained from the RS/RA will be
considered definitive.
Krishnan & Daley Expires August 28, 2009 [Page 9]
Internet-Draft Simple DNA February 2009
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.8. Further Host Operations
Operations subsequent to detecting network attachment depend upon
whether change was detected.
After confirming the reachability of the associated router using an
NS/NA pair, the host performs the following steps.
o The host SHOULD rejoin any solicited nodes' multicast groups for
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
based probe on the same router completed with different prefixes than
the ones in the SDAT the host MUST unconfigure all the existing
addresses received from the given router, and MUST begin address
configuration techniques, as indicated in the received Router
Advertisement [RFC4861][RFC4862].
4.9. Recommended retransmission behavior
In situations where Neighbor Solicitation probes and Router
Solicitation probes are used on the same link, it is possible that
the NS probe will complete successfully, and then the RS probe will
complete later with a different result. If this happens, the
implementation SHOULD abandon the results obtained from the NS probe
of the router that responded to the RS and the implementation SHOULD
behave as if the NS probe did not successfully complete. If the
confirmed address was assigned manually, the implementation SHOULD
NOT unconfigure the manually assigned address and SHOULD log an error
about the mismatching prefix.
Where the NS probe does not complete successfully, it usually implies
that the host is not attached to the network whose configuration is
being tested. In such circumstances, there is typically little value
in aggressively retransmitting unicast neighbor solicitations that do
Krishnan & Daley Expires August 28, 2009 [Page 10]
Internet-Draft Simple DNA February 2009
not elicit a response.
Where unicast Neighbor Solicitations and Router Solicitations are
sent in parallel, one strategy is to forsake retransmission of
Neighbor Solicitations and to allow retransmission only of Router
Solicitations or DHCPv6. In order to reduce competition between
unicast Neighbor Solicitations and Router Solicitations and DHCPv6
retransmissions, a DNAv6 implementation that retransmits may utilize
the retransmission strategy described in the DHCPv6 specification
[RFC3315], scheduling DNAv6 retransmissions between Router
Solicitation or DHCPv6 retransmissions.
If a response is received to any unicast Neighbor Solicitation,
Router Solicitation or DHCPv6 message, pending retransmissions MUST
be canceled [RFC3315][RFC3736]. A Simple DNA implementation SHOULD
NOT retransmit a Neighbor Solicitation more than twice. To provide
damping in the case of spurious Link Up indications, the host SHOULD
NOT perform the Simple DNA procedure more than once a second.
5. Router Operations
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].
Krishnan & Daley Expires August 28, 2009 [Page 11]
Internet-Draft Simple DNA February 2009
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 */
/* Start Simple DNA process */
/* Mark All Addresses as deprecated */
Configured_Address_List=Get_Address_List(INTERFACE);
foreach Configured_Address in Configured_Address_List
{
if (Get_Address_State(Configured_Address)!=AS_TENTATIVE)
{
Set_Address_State(Configured_Address,AS_DEPRECATED);
}
}
/* Mark all routers' NC entries as STALE to speed up */
/* acquisition of new router if link change has occurred */
foreach Router_Address in DEFAULT_ROUTER_LIST
{
NCEntry=Get_Neighbor_Cache_Entry(Router_Address);
Set_Neighbor_Cache_Entry_State(NCEntry,NCS_STALE);
}
/* Thread A : Send Router Solicitation */
RS_Target_Address=FF02::2;
RS_Source_Address=Get_Any_Link_Local_Address(INTERFACE);
Send_Router_Solicitation(RS_Source_Address,RS_Target_Address);
/* Thread B : Send Neighbor Solicitation(s) */
Previously_Known_Router_List=Get_Router_List_from_SDAT();
NS_Source_Address=Get_Any_Link_Local_Address(INTERFACE);
foreach Router_Address in Previously_Known_Router_List
{
if (Get_Any_Valid_Address_from_SDAT(Router_Address))
{
Send_Neighbor_Solicitation(NS_Source_Address,Router_Address);
}
}
/* Thread C : Response collection */
Krishnan & Daley Expires August 28, 2009 [Page 12]
Internet-Draft Simple DNA February 2009
/* Received Router Advertisement processing */
/* Only for RAs received as response to DNA RSs */
L3_Source=Get_L3_Source(RECEIVED_MESSAGE);
L2_Source=Get_L2_Source(RECEIVED_MESSAGE);
SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source));
foreach SDAT_Entry in SDAT_Entry_List
{
if (Exists_PIO(RECEIVED_MESSAGE,Get_Prefix(SDAT_Entry)))
{
/* Address is operable. Configure on Interface */
/* Rejoin solicited-node multicast group for address */
}
else
{
/* If address is configured on interface, remove it */
/* This could be because of a NA arriving before RA */
}
}
/* Mark router as reachable */
NCEntry=Get_Neighbor_Cache_Entry(L3_Source);
if (NCEntry is not NULL)
{
Set_Neighbor_Cache_Entry_State(NCEntry,NCS_REACHABLE);
}
else
{
Create_Neighbor_Cache_Entry(L3_Source,NCS_REACHABLE);
}
/* Ignore further NAs from this router */
Add_Router_to_NA_Ignore_List(L3_Source);
/* Received Neighbor Advertisement processing */
/* Only for NAs received as response to DNA NSs */
L3_Source=Get_L3_Source(RECEIVED_MESSAGE);
L2_Source=Get_L2_Source(RECEIVED_MESSAGE);
if (Is_Router_on_NA_Ignore_List(L3_Source)) {
/* Ignore message and wait for next message */
continue;
}
SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source));
Krishnan & Daley Expires August 28, 2009 [Page 13]
Internet-Draft Simple DNA February 2009
foreach SDAT_Entry in SDAT_Entry_List
{
/* Address is operable. Configure on Interface */
}
Figure 1: Pseudocode for Simple DNA
7. 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
Definition: An optional period to wait after Neighbour
Solicitation before adopting a non-SEND RA's link change
information.
Value: 40 milliseconds
8. Relationship to DNAv4
DNAv4 [RFC4436] specifies a set of steps that optimize the (common)
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)
configuration. This document shares the same goal as DNAv4 (that of
minimizing the handover latency in moving between points of
attachment) but differs in the steps it performs to achieve this
Krishnan & Daley Expires August 28, 2009 [Page 14]
Internet-Draft Simple DNA February 2009
goal. Another difference is that this document also supports
stateless autoconfiguration of addresses in addition to addresses
configured using DHCPv6.
9. Open Issues
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.
11. 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
receiving a link-layer indications. While it is necessary to assess
quickly whether a host has moved to another network, it is important
that the host's current secured SEND [RFC3971] router information is
not replaced by an attacker which spoofs an RA and purports to change
the link.
As such, the host SHOULD send a Neighbour Solicitation to the
existing SEND router upon link-up indication as described above in
Section 4.3. The host SHOULD then ensure that unsecured router
information does not cause deletion of existing SEND state, within
MIN_DELAY_BETWEEN_RAS, in order to allow for a present SEND router to
Krishnan & Daley Expires August 28, 2009 [Page 15]
Internet-Draft Simple DNA February 2009
respond.
The host MAY delay SEND_NA_GRACE_TIME after transmission before
adopting a new default router, if it is operating on a network where
there is significant threat of RA spoofing.
Even if SEND signatures on RAs are used, it may not be immediately
clear if the router is authorized to make such advertisements. As
such, a host SHOULD NOT treat such devices as secure until and unless
authorization delegation discovery is successful.
It is easy for hosts soliciting without SEND to deplete a SEND
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
with Bernard Aboba, Thomas Narten, Erik Nordmark and Dave Thaler at
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
for helping to explore the solution space. The authors would like to
thank the authors and editors of the complete DNA specification for
detailing the overall problem space and solutions. The authors would
like to thank Jari Arkko for driving the evolution of a simple and
probabilistic DNA solution. The authors would like to thank Bernard
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
drive the document forward.
13. References
13.1. Normative References
[I-D.ietf-dna-tentative]
Daley, G., Nordmark, E., and N. Moore, "Tentative Options
for IPv6 Neighbour Discovery", draft-ietf-dna-tentative-01
(work in progress), July 2007.
[I-D.ietf-dna-protocol]
Narayanan, S., "Detecting Network Attachment in IPv6
Networks (DNAv6)", draft-ietf-dna-protocol (work in
progress), June 2007.
Krishnan & Daley Expires August 28, 2009 [Page 16]
Internet-Draft Simple DNA February 2009
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
13.2. Informative References
[RFC4957] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S.,
and A. Yegin, "Link-Layer Event Notifications for
Detecting Network Attachments", RFC 4957, August 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
Authors' Addresses
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com
Krishnan & Daley Expires August 28, 2009 [Page 17]
Internet-Draft Simple DNA February 2009
Greg Daley
NetStar Networks
Level 9/636 St Kilda Rd
Melbourne, Victoria 3004
Australia
Phone: +61 3 8532 4042
Email: gdaley@netstarnetworks.com
Krishnan & Daley Expires August 28, 2009 [Page 18]