draft-ietf-dna-simple-08.txt   draft-ietf-dna-simple-09.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 14, 2010 July 13, 2009 Expires: March 20, 2010 September 16, 2009
Simple procedures for Detecting Network Attachment in IPv6 Simple procedures for Detecting Network Attachment in IPv6
draft-ietf-dna-simple-08 draft-ietf-dna-simple-09
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 14, 2010. This Internet-Draft will expire on March 20, 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 30 skipping to change at page 2, line 30
4. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . 7 4.3. Link-Layer Indication . . . . . . . . . . . . . . . . . . 7
4.4. Sending Neighbor Discovery probes . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . 9 4.6. Sending DHCPv6 probes . . . . . . . . . . . . . . . . . . 9
4.7. Response Gathering . . . . . . . . . . . . . . . . . . . . 9 4.7. Response Gathering . . . . . . . . . . . . . . . . . . . . 9
4.7.1. Conflicting results . . . . . . . . . . . . . . . . . 10
4.8. Further Host Operations . . . . . . . . . . . . . . . . . 10 4.8. Further Host Operations . . . . . . . . . . . . . . . . . 10
4.9. Recommended retransmission behavior . . . . . . . . . . . 10 4.9. Recommended retransmission behavior . . . . . . . . . . . 11
5. Pseudocode for Simple DNA . . . . . . . . . . . . . . . . . . 12 5. Pseudocode for Simple DNA . . . . . . . . . . . . . . . . . . 12
6. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Relationship to DNAv4 . . . . . . . . . . . . . . . . . . . . 14 7. Relationship to DNAv4 . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Issues with confirming manually assigned addresses . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
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
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 neighbor
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.
This document incorporates feedback from host and router operating This document incorporates feedback from host and router operating
systems implementors, which seeks to make implementation and adoption systems implementors, which seeks to make implementation and adoption
of IPv6 change detection procedures simple for general use. of IPv6 change detection procedures simple for general use.
2.1. Goals 2.1. Goals
skipping to change at page 4, line 15 skipping to change at page 4, line 15
2.2. Applicability 2.2. Applicability
The Simple DNA protocol provides substantial benefits in some The Simple DNA protocol provides substantial benefits in some
scenarios and does not provide any benefit at all in certain other scenarios and does not provide any benefit at all in certain other
scenarios. This is intentional as Simple DNA was designed for scenarios. This is intentional as Simple DNA was designed for
simplicity rather than completeness. In particular, the Simple DNA simplicity rather than completeness. In particular, the Simple DNA
protocol provides maximum benefits when a host moves between a small protocol provides maximum benefits when a host moves between a small
set of known links. When a host moves to a completely new link that set of known links. When a host moves to a completely new link that
is previously unknown, the performance of the Simple DNA protocol is previously unknown, the performance of the Simple DNA protocol
will be identical to that using standard neighbor discovery will be identical to that using standard neighbor discovery
procedures [RFC4861]. procedures [RFC4861]. The Simple DNA procedure provides support for
addresses configured using either IPv6 Stateless Address
Autoconfiguration [RFC4862] or DHCPv6 [RFC3315]. It does not support
manually configured addresses since they are not widely used and can
cause unpredictable results and/or aggressive probing behavior
[Appendix A].
2.3. Link Identification model 2.3. Link Identification model
Earlier methods of detecting network attachment, e.g. the procedure Earlier methods of detecting network attachment, e.g. the procedure
defined in [I-D.ietf-dna-protocol], relied on detecting whether the 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 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 to the same link, all information related to the link such as the
routers, prefixes and configuration parameters was considered to be routers, prefixes and configuration parameters was considered to be
valid. The Simple DNA protocol follows an alternate approach where valid. The Simple DNA protocol follows an alternate approach where
it relies on probing each previously known router to determine it relies on probing each previously known router to determine
whether to use information learnt from THAT router. This allows whether to use information learnt from THAT router. This allows
simple DNA to probe routers learnt from multiple earlier attachments simple DNA to probe routers learnt from multiple earlier attachments
to optimize movement between a known set of links. to optimize movement between a known set of links.
2.4. DNA Roles 2.4. DNA Roles
Detecting Network Attachment is performed by hosts by sending IPv6 Detecting Network Attachment is performed by hosts by sending IPv6
neighbour discovery and router discovery messages to routers after neighbor discovery and router discovery messages to routers after
connecting to a network. connecting to a network.
It is desirable that routers adopt procedures which allow for fast It is desirable that routers adopt procedures which allow for fast
unicast Router Advertisement (RA) messages. Routers that follow the unicast Router Advertisement (RA) messages. Routers that follow the
standard neighbor discovery procedure described in [RFC4861] will standard neighbor discovery procedure described in [RFC4861] will
delay the router advertisement by a random period between 0 and delay the router advertisement by a random period between 0 and
MAX_RA_DELAY_TIME (defined to be 500ms) as described in Section 6.2.6 MAX_RA_DELAY_TIME (defined to be 500ms) as described in Section 6.2.6
of [RFC4861]. This delay can be significant and may result in of [RFC4861]. This delay can be significant and may result in
service disruption. Please note that support for fast unicast RAs is service disruption. Please note that support for fast unicast RAs is
not necessary since the simple dna procedure can continue to work not necessary since the simple dna procedure can continue to work
using the NS/NA exchange, which will complete earlier than the RA using the NS/NA exchange, which will complete earlier than the RA
arrives. 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 Neighbor Solicitations (NSs). The host uses advertisements to
determine if the routers it currently has configured are still determine if the routers it currently has configured are still
available. available.
Additionally, on links with no statelessly configured addresses, the Additionally, on links with no statelessly configured addresses, the
host may make use of DHCPv6 procedures to identify an operable host may make use of DHCPv6 procedures to identify an operable
address. address.
2.5. Working Assumptions 2.5. Working Assumptions
There are a series of assumptions about the network environment which There are a series of assumptions about the network environment which
skipping to change at page 6, line 32 skipping to change at page 6, line 32
Simple DNA address table (SDAT). This data structure is maintained Simple DNA address table (SDAT). This data structure is maintained
by the host on a per interface basis. Each entry in the SDAT table by the host on a per interface basis. Each entry in the SDAT table
consists of at least the following parameters. consists of at least the following parameters.
o IPv6 address and its related parameters like valid lifetime. o IPv6 address and its related parameters like valid lifetime.
o Prefix from which the address was formed. o Prefix from which the address was formed.
o Link-local IPv6 address of the router that advertised the prefix. o Link-local IPv6 address of the router that advertised the prefix.
o Link layer (MAC) address of the router that advertised the prefix. o Link-layer (MAC) address of the router that advertised the prefix.
o DHCP Unique IDentifier (DUID) in case DHCPv6 was used to acquire o DHCP Unique IDentifier (DUID) in case DHCPv6 was used to acquire
the address [RFC3315]. the address [RFC3315].
4.2. Steps involved in detecting link change 4.2. Steps involved in detecting link change
The steps involved in basic detection of network attachment are: The steps involved in basic detection of network attachment are:
o Link-Layer Indication o Link-Layer Indication
o Sending of neighbour discovery or DHCPv6 probes o Sending of neighbor discovery or DHCPv6 probes
o Response gathering and assessment o Response gathering and assessment
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].
skipping to change at page 7, line 43 skipping to change at page 7, line 43
these addresses in the candidate set for NS based probing. 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 Neighbor 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.
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.
skipping to change at page 8, line 25 skipping to change at page 8, line 25
Destination Address: The link-local address of the router being Destination Address: The link-local address of the router being
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 Link Layer Header:
the probe messages if the address was obtained using DHCPv6 and the
lease has not expired. Otherwise the probing node SHOULD NOT include Destination Address: The link-layer (MAC) address of the router
the Source link-layer address option in the probe messages. being probed as learnt from the SDAT.
The probing node SHOULD NOT include 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.
skipping to change at page 9, line 8 skipping to change at page 9, line 8
Hop Limit: 255 Hop Limit: 255
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 address was obtained using DHCPv6 and the the probe messages if the address was obtained using DHCPv6 and the
lease has not expired. Otherwise the probing node SHOULD NOT include lease has not expired. Otherwise the probing node SHOULD NOT include
the Source link-layer address option in the probe messages. 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 probe messages
before or simultanously with Neighbour Discovery probing. in parallel with the Neighbor Discovery probing. The DHCPv6 probing
procedures described in this document do not imply any changes to the
DHCPv6 protocol or state machine.
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 Association 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.
skipping to change at page 9, line 36 skipping to change at page 9, line 38
contained in the Identity Association (IA_TA or IA_NA) will contain contained in the Identity Association (IA_TA or IA_NA) will contain
an IP Address which is operable for the link. an IP Address which is operable for the link.
Where Rapid-Commit option has been sent, a DHCPv6 server will respond Where Rapid-Commit option has been sent, a DHCPv6 server will respond
with REPLY. In addition to being operable, this address is allocated with REPLY. In addition to being operable, this address is allocated
to the host for the lease duration indicated in the Identity to the host for the lease duration indicated in the Identity
Association. Association.
4.7. Response Gathering 4.7. Response Gathering
When a responding Neighbour Advertisement is received from a test When a responding Neighbor Advertisement is received from a test
node, the host MUST verify that both the IPv6 and link layer (MAC) node, the host MUST verify that both the IPv6 and link layer (MAC)
addresses of the test node match the expected values before utilizing addresses of the test node match the expected values before utilizing
the configuration associated with the detected network (prefixes, MTU the configuration associated with the detected network (prefixes, MTU
etc.). etc.).
On reception of a Router Advertisement or advertising DHCPv6 message On reception of a Router Advertisement or advertising DHCPv6 message
(a REPLY or ADVERTISE) which contains prefixes that intersect with (a REPLY or ADVERTISE) which contains prefixes that intersect with
those previously advertised by a known router, the host utilizes the those previously advertised by a known router, the host utilizes the
configuration associated with the detected network. configuration associated with the detected network.
skipping to change at page 10, line 18 skipping to change at page 10, line 20
same router differ, the results obtained from the RS/RA will be same router differ, the results obtained from the RS/RA will be
considered definitive. considered definitive.
When the host receives a Router Advertisement in reply to the Router When the host receives a Router Advertisement in reply to the Router
Solicitation it sent, the host SHOULD look for a Neighbor Cache entry Solicitation it sent, the host SHOULD look for a Neighbor Cache entry
for the sending router and SHOULD mark that router's Neighbor Cache for the sending router and SHOULD mark that router's Neighbor Cache
Entry as REACHABLE if one was found. The host SHOULD add a new Entry as REACHABLE if one was found. The host SHOULD add a new
Neighbor Cache Entry in the REACHABLE state for the sending router if Neighbor Cache Entry in the REACHABLE state for the sending router if
one does not currently exist. one does not currently exist.
4.7.1. Conflicting results
It is possible that the DHCPv6 based probes and the neighbor
discovery based probes complete with conflicting results. In this
case, the host SHOULD use the following rules to determine the final
result.
o If the DHCPv6 exchange was authenticated, use the result from the
DHCPv6 probe.
o If the DHCPv6 exchange was not authenticated and the neighbor
discovery exchange was protected by SEND [RFC3971], use the result
from the neighbor discovery probe.
o If both the DHCPv6 and neighbor discovery exchanges were not
authenticated, use the result from the DHCPv6 probe
4.8. Further Host Operations 4.8. Further Host Operations
Operations subsequent to detecting network attachment depend upon Operations subsequent to detecting network attachment depend upon
whether change was detected. whether change was detected.
After confirming the reachability of the associated router using an After confirming the reachability of the associated router using an
NS/NA pair, the host performs the following steps. NS/NA pair, the host performs the following steps.
o The host SHOULD rejoin any solicited nodes' multicast groups for o The host SHOULD rejoin any solicited nodes' multicast groups for
addresses it continues to use. addresses it continues to use.
skipping to change at page 14, line 9 skipping to change at page 14, line 9
{ {
/* Address is operable. Configure on Interface */ /* Address is operable. Configure on Interface */
} }
Figure 1: Pseudocode for Simple DNA Figure 1: Pseudocode for Simple DNA
6. Constants 6. Constants
SEND_NA_GRACE_TIME SEND_NA_GRACE_TIME
Definition: An optional period to wait after Neighbour Definition: An optional period to wait after Neighbor
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
7. 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)
skipping to change at page 14, line 33 skipping to change at page 14, line 33
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.
8. IANA Considerations 8. IANA Considerations
There are no changes to IANA registries required in this document. There are no changes to IANA registries required in this document.
9. Security Considerations 9. Security Considerations
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 Neighbor Solicitation to the existing
existing SEND router upon link-up indication as described above in 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.
If the current default router is a SEND-secured router, the host If the current default router is a SEND-secured router, the host
SHOULD wait SEND_NA_GRACE_TIME after transmission before adopting a SHOULD wait SEND_NA_GRACE_TIME after transmission before adopting a
new default router. 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.
10. Acknowledgments 10. Acknowledgments
This document is the product of a discussion between the authors had This document is the product of a discussion the authors had with
with Bernard Aboba, Thomas Narten, Erik Nordmark and Dave Thaler at Bernard Aboba, Thomas Narten, Erik Nordmark and Dave Thaler at IETF
IETF 69. The authors would like to thank them for clearly detailing 69. The authors would like to thank them for clearly detailing the
the requirements of the solution and the goals it needed to meet and requirements of the solution and the goals it needed to meet and for
for helping to explore the solution space. The authors would like to 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, Jari Arkko, Sathya Narayan, Julien Laganier, Aboba, Thomas Narten, Jari Arkko, Sathya Narayan, Julien Laganier,
Domagoj 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.
11. References 11. References
11.1. Normative References 11.1. Normative References
[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.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[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
(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.
11.2. Informative References 11.2. Informative References
[I-D.ietf-dna-protocol] [I-D.ietf-dna-protocol]
skipping to change at page 16, line 17 skipping to change at page 16, line 17
[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.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
Appendix A. Issues with confirming manually assigned addresses
Even though DNAv4 [RFC4436] supports verification of manually
assigned addresses this feature of DNAv4 has not been widely
implemented or used. There are two major issues that come up with
confirming manually assigned addresses using Simple DNA.
o When DHCPv6 or SLAAC addresses are used for probing, there is no
need to aggressively retransmit lost probes. This is because the
address configuration falls back to vanilla DHCPv6 or SLAAC and
the host will eventually obtain an address. This is not the case
with manually assigned addresses. If the probes are lost, the
host runs the risk of ending up with no addresses at all. Hence
agressive retransmissions are mandated.
o Another issue comes up when the host moves between two networks,
one where manual addressing is being used (say NET1)and the other
where dynamic addressing (DHCPv6) is being used (say NET2). When
the host moves to NET1 from NET2 it tries to confirm both the
manual address and the dynamic address in parallel. If the probe
for the manually assigned address is lost, the DHCPv6 probe will
succeed and the host will incorrectly end up using the DHCPv6
assigned address (from NET2) on NET1.
Given these issues, it is NOT RECOMMENDED to use manual addressing
with Simple DNA.
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
Email: suresh.krishnan@ericsson.com Email: suresh.krishnan@ericsson.com
 End of changes. 24 change blocks. 
30 lines changed or deleted 86 lines changed or added

This html diff was produced by rfcdiff 1.36. The latest version is available from http://tools.ietf.org/tools/rfcdiff/