draft-ietf-dna-simple-09.txt   draft-ietf-dna-simple-10.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: March 20, 2010 September 16, 2009 Expires: April 29, 2010 October 26, 2009
Simple procedures for Detecting Network Attachment in IPv6 Simple procedures for Detecting Network Attachment in IPv6
draft-ietf-dna-simple-09 draft-ietf-dna-simple-10
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 March 20, 2010. This Internet-Draft will expire on April 29, 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 17 skipping to change at page 2, line 17
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 . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Link Identification model . . . . . . . . . . . . . . . . 4 2.3. Link Identification model . . . . . . . . . . . . . . . . 4
2.4. DNA Roles . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. DNA Overview . . . . . . . . . . . . . . . . . . . . . . . 4
2.5. Working Assumptions . . . . . . . . . . . . . . . . . . . 5 2.5. Working Assumptions . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
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. DHCPv6 operation . . . . . . . . . . . . . . . . . . . . . 9
4.7. Response Gathering . . . . . . . . . . . . . . . . . . . . 9 4.7. Response Gathering . . . . . . . . . . . . . . . . . . . . 10
4.7.1. Conflicting results . . . . . . . . . . . . . . . . . 10 4.7.1. Conflicting results . . . . . . . . . . . . . . . . . 11
4.8. Further Host Operations . . . . . . . . . . . . . . . . . 10 4.8. Further Host Operations . . . . . . . . . . . . . . . . . 11
4.9. Recommended retransmission behavior . . . . . . . . . . . 11 4.9. Recommended retransmission behavior . . . . . . . . . . . 12
5. Pseudocode for Simple DNA . . . . . . . . . . . . . . . . . . 12 5. Pseudocode for Simple DNA . . . . . . . . . . . . . . . . . . 13
6. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Relationship to DNAv4 . . . . . . . . . . . . . . . . . . . . 14 7. Relationship to DNAv4 . . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Issues with confirming manually assigned addresses . 16 Appendix A. Issues with confirming manually assigned addresses . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
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 than the one to which they have been
recently connected. In order to detect change, router and neighbor 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
The goal of this document is to specify a simple procedure for The goal of this document is to specify a simple procedure for
detecting network attachment (Simple DNA) that has the following detecting network attachment (Simple DNA) that has the following
characteristics. characteristics.
o Routers do not have to be modified to support this scheme. o Routers do not have to be modified to support this scheme.
o Handle only the simplest and most likely use cases. o The most common use cases are optimized.
o Work at least as quickly as standard neighbor discovery. o In the worst case, detection latency is equal to that of standard
neighbor discovery so that performance is never degraded.
o False positives are not acceptable. A host should not conclude o False positives are not acceptable. A host should not conclude
that there is no link change when there is one. that there is no link change when there is one.
o False negatives are acceptable. A host can conclude that there is o False negatives are acceptable. A host can conclude that there is
a link change when there is none. a link change when there is none.
2.2. Applicability 2.2. Applicability
The Simple DNA protocol provides substantial benefits in some The Simple DNA protocol provides substantial benefits in some
skipping to change at page 4, line 35 skipping to change at page 4, line 35
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 Overview
Detecting Network Attachment is performed by hosts by sending IPv6 Detecting Network Attachment is performed by hosts after detecting a
neighbor discovery and router discovery messages to routers after link-layer "up" indication. The host simultaneously sends multicast
connecting to a network. Router Solicitations (RSs) and unicast Neighbor Solicitations (NSs)
in order to determine whether previously encountered routers are
present on the link.
It is desirable that routers adopt procedures which allow for fast Hosts implementing simple DNA may also send DHCPv6 packets, as
unicast Router Advertisement (RA) messages. Routers that follow the described in Section 4.6. Since simple DNA does not modify the
standard neighbor discovery procedure described in [RFC4861] will DHCPv6 protocol or state machine, the operation of DHCPv6 is
delay the router advertisement by a random period between 0 and unchanged.
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 Routers that follow the standard neighbor discovery procedure
simultaneously probes the network with Router Solicitations (RSs) and described in [RFC4861] will delay the router advertisement by a
Neighbor Solicitations (NSs). The host uses advertisements to random period between 0 and MAX_RA_DELAY_TIME (defined to be 500ms)
determine if the routers it currently has configured are still as described in Section 6.2.6 of [RFC4861]. Hosts implementing
available. simple DNA can detect the presence of a previously encountered router
using unicast Neighbor Solicitations. As a result, where the host
with a valid configuration is returning to a previously encountered
link, delays in the sending of a Router Advertisement (RA) will not
delay configuration as long as NS probing is successful. However in
situations where the host is attaching to a link for the first time,
or where it does not have a valid IP address on the link, it will be
dependent on the receipt of an RA for stateless auto-configuration.
In these situations delays in the receipt of an RA can be significant
and may result in service disruption.
Additionally, on links with no statelessly configured addresses, the As a result, in addition to implementing simple DNA, it is desirable
host may make use of DHCPv6 procedures to identify an operable that routers adopt procedures which allow for fast unicast Router
address. Advertisement (RA) messages.
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
underpin these procedures. underpin these procedures.
o The combination of the link layer address and the link local IPv6 o The combination of the link layer address and the link local IPv6
address of a router is unique across links. address of a router is unique across links.
o Hosts receive indications when a link-layer comes up. Without o Hosts receive indications when a link-layer comes up. Without
skipping to change at page 8, line 30 skipping to change at page 8, line 30
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.
Link Layer Header: Link Layer Header:
Destination Address: The link-layer (MAC) address of the router Destination Address: The link-layer (MAC) address of the router
being probed as learnt from the SDAT. being probed as learnt from the SDAT.
The probing node SHOULD NOT include the Source link-layer address The probing node SHOULD include a Source link-layer address option in
option in the probe messages. the probe messages if the address was obtained using DHCPv6 and the
lease has not expired. Otherwise 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.
Hop Limit: 255 Hop Limit: 255
The probing node SHOULD include a Source link-layer address option in The probing node SHOULD NOT include the Source link-layer address
the probe messages if the address was obtained using DHCPv6 and the option in the probe messages.
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. DHCPv6 operation
Simple DNA does not require a host to implement DHCPv6, nor does it
imply any changes to the DHCPv6 protocol or state machine. Hosts MAY
attempt to obtain IPv6 configuration via DHCPv6 in parallel with
simple DNA probing. This ensures that the simple DNA procedure will
not result in additional delay in the case where reachability tests
fail, or where a DHCPv6 exchange completes more quickly than the
reachability tests.
In situations where both simple DNA and DHCPv6 are used on the same
link, it is possible that simple DNA probing will complete
successfully, and then DHCPv6 will complete later with a different
result. If this happens, the procedure described in Section 4.7.1
are utilized.
Where the host attempts to obtain IPv6 configuration in parallel with
simple DNA, on receiving a link-layer "up" indication, it sends a
DHCPv6 SOLICIT to All_DHCP_Relay_Agents_and_Servers. This message
contains an Identity Association 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.
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 probe messages not have a global prefix, it MAY prefer to use DHCPv6 probe messages
in parallel with the Neighbor Discovery probing. The DHCPv6 probing in parallel with the Neighbor Discovery probing. The DHCPv6 probing
procedures described in this document do not imply any changes to the procedures described in this document do not imply any changes to the
DHCPv6 protocol or state machine. 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) . Where an existing
existing valid address is being tested for operability, this address valid address is being tested for operability, this address should be
should be placed in the Identity Association's IAADDR element, and placed in the Identity Association's IAADDR element, and the DUID
the DUID associated with that address should be copied to the DHCP associated with that address should be copied to the DHCP SOLICIT
SOLICIT from the SDAT. 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.
Where the Rapid-Commit option has not been used, a present DHCP Where the Rapid-Commit option has not been used, a present DHCP
server will respond with an ADVERTISE message. The IP address server will respond with an ADVERTISE message. The IP address
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.
skipping to change at page 10, line 22 skipping to change at page 11, line 12
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 4.7.1. Conflicting results
It is possible that the DHCPv6 based probes and the neighbor It is possible that the DHCPv6 exchanges and the neighbor discovery
discovery based probes complete with conflicting results. In this based probes complete with conflicting results. In this case, the
case, the host SHOULD use the following rules to determine the final host SHOULD use the following rules to determine the final result.
result.
o If the DHCPv6 exchange was authenticated, use the result from the o If the DHCPv6 exchange was authenticated, use the result from
DHCPv6 probe. DHCPv6.
o If the DHCPv6 exchange was not authenticated and the neighbor o If the DHCPv6 exchange was not authenticated and the neighbor
discovery exchange was protected by SEND [RFC3971], use the result discovery exchange was protected by SEND [RFC3971], use the result
from the neighbor discovery probe. from the neighbor discovery probe.
o If both the DHCPv6 and neighbor discovery exchanges were not o If both the DHCPv6 and neighbor discovery exchanges were not
authenticated, use the result from the DHCPv6 probe authenticated, use the result from DHCPv6.
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.
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
skipping to change at page 11, line 15 skipping to change at page 12, line 15
If the NS based probe with a router did not complete or if the RS If the NS based probe with a router did not complete or if the RS
based probe on the same router completed with different prefixes than based probe on the same router completed with different prefixes than
the ones in the SDAT the host MUST unconfigure all the existing the ones in the SDAT the host MUST unconfigure all the existing
addresses received from the given router, and MUST begin address addresses received from the given router, and MUST begin address
configuration techniques, as indicated in the received Router configuration techniques, as indicated in the received Router
Advertisement [RFC4861][RFC4862]. Advertisement [RFC4861][RFC4862].
4.9. Recommended retransmission behavior 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 Where the NS probe does not complete successfully, it usually implies
that the host is not attached to the network whose configuration is that the host is not attached to the network whose configuration is
being tested. In such circumstances, there is typically little value being tested. In such circumstances, there is typically little value
in aggressively retransmitting unicast neighbor solicitations that do in aggressively retransmitting unicast neighbor solicitations that do
not elicit a response. not elicit a response.
Where unicast Neighbor Solicitations and Router Solicitations are Where unicast Neighbor Solicitations and Router Solicitations are
sent in parallel, one strategy is to forsake retransmission of sent in parallel, one strategy is to forsake retransmission of
Neighbor Solicitations and to allow retransmission only of Router Neighbor Solicitations and to allow retransmission only of Router
Solicitations or DHCPv6. In order to reduce competition between Solicitations or DHCPv6. In order to reduce competition between
skipping to change at page 14, line 5 skipping to change at page 15, line 5
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
NOTE: This section does not include any pseudo-code for sending of
the DHCPv6 packets since the DHCPv6 exchange is orthogonal to the
simple DNA process.
6. Constants 6. Constants
SEND_NA_GRACE_TIME SEND_NA_GRACE_TIME
Definition: An optional period to wait after Neighbor 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
skipping to change at page 16, line 30 skipping to change at page 17, line 36
assigned addresses this feature of DNAv4 has not been widely assigned addresses this feature of DNAv4 has not been widely
implemented or used. There are two major issues that come up with implemented or used. There are two major issues that come up with
confirming manually assigned addresses using Simple DNA. confirming manually assigned addresses using Simple DNA.
o When DHCPv6 or SLAAC addresses are used for probing, there is no o When DHCPv6 or SLAAC addresses are used for probing, there is no
need to aggressively retransmit lost probes. This is because the need to aggressively retransmit lost probes. This is because the
address configuration falls back to vanilla DHCPv6 or SLAAC and address configuration falls back to vanilla DHCPv6 or SLAAC and
the host will eventually obtain an address. This is not the case the host will eventually obtain an address. This is not the case
with manually assigned addresses. If the probes are lost, the with manually assigned addresses. If the probes are lost, the
host runs the risk of ending up with no addresses at all. Hence host runs the risk of ending up with no addresses at all. Hence
agressive retransmissions are mandated. agressive retransmissions are necessary.
o Another issue comes up when the host moves between two networks, o Another issue comes up when the host moves between two networks,
one where manual addressing is being used (say NET1)and the other one where manual addressing is being used (say NET1)and the other
where dynamic addressing (DHCPv6) is being used (say NET2). When where dynamic addressing (stateless autoconfig or DHCPv6) is being
the host moves to NET1 from NET2 it tries to confirm both the used (say NET2). Since the host can obtain a dynamic address in
manual address and the dynamic address in parallel. If the probe some situations, it will need to send simple DNA probes and may
for the manually assigned address is lost, the DHCPv6 probe will also engage in a DHCPv6 exchange. In a situation where the host
succeed and the host will incorrectly end up using the DHCPv6 moves to NET1 and the NS probes are lost and in addition an RA is
assigned address (from NET2) on NET1. not received, the host will not be able to confirm that it
attached to NET1, and therefore that it should use the manual
configuration for that network. As a result, if DHCPv6 is enabled
on NET1, then the host could mistakenly obtain a dynamic address
and configuration instead of using the manual configuration. To
prevent this problem, simple DNA probing needs to continue even
after the DHCPv6 exchange has completed, and DNA probes need to
take precedence over DHCPv6, contrary to the advice provided in
Section 4.7.1
Given these issues, it is NOT RECOMMENDED to use manual addressing Given these issues, it is NOT RECOMMENDED to use manual addressing
with Simple DNA. 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
 End of changes. 24 change blocks. 
82 lines changed or deleted 137 lines changed or added

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