Network Working Group S. Krishnan Internet-Draft Ericsson Updates: 4861 (if approved) G. Daley Intended status: Standards Track NetStar Networks Expires: April 29, 2010 October 26, 2009 Simple procedures for Detecting Network Attachment in IPv6 draft-ietf-dna-simple-11 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 April 29, 2010. 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). 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 addressing or routing configuration is valid for a newly connected Krishnan & Daley Expires April 29, 2010 [Page 1] Internet-Draft Simple DNA October 2009 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 . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Link Identification model . . . . . . . . . . . . . . . . 4 2.4. DNA Overview . . . . . . . . . . . . . . . . . . . . . . . 4 2.5. Working Assumptions . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Host data structures . . . . . . . . . . . . . . . . . . . 6 4.2. Steps involved in detecting link change . . . . . . . . . 6 4.3. Link-Layer Indication . . . . . . . . . . . . . . . . . . 7 4.4. Sending Neighbor Discovery probes . . . . . . . . . . . . 7 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. DHCPv6 operation . . . . . . . . . . . . . . . . . . . . . 9 4.7. Response Gathering . . . . . . . . . . . . . . . . . . . . 9 4.7.1. Conflicting results . . . . . . . . . . . . . . . . . 10 4.8. Further Host Operations . . . . . . . . . . . . . . . . . 11 4.9. Recommended retransmission behavior . . . . . . . . . . . 11 5. Pseudocode for Simple DNA . . . . . . . . . . . . . . . . . . 13 6. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Relationship to DNAv4 . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 Appendix A. Issues with confirming manually assigned addresses . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Krishnan & Daley Expires April 29, 2010 [Page 2] Internet-Draft Simple DNA October 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 than the one to which they have been recently connected. In order to detect change, router and neighbor 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 The most common use cases are optimized. 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 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. Krishnan & Daley Expires April 29, 2010 [Page 3] Internet-Draft Simple DNA October 2009 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 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 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 Overview Detecting Network Attachment is performed by hosts after detecting a link-layer "up" indication. The host simultaneously sends multicast Router Solicitations (RSs) and unicast Neighbor Solicitations (NSs) in order to determine whether previously encountered routers are present on the link. Hosts implementing simple DNA may also send DHCPv6 packets, as described in Section 4.6. Since simple DNA does not modify the DHCPv6 protocol or state machine, the operation of DHCPv6 is unchanged. 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]. Hosts implementing simple DNA can detect the presence of a previously encountered router Krishnan & Daley Expires April 29, 2010 [Page 4] Internet-Draft Simple DNA October 2009 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. As a result, in addition to implementing simple DNA, it is desirable that routers adopt procedures which allow for fast unicast Router Advertisement (RA) messages. 2.5. Working Assumptions There are a series of assumptions about the network environment which underpin these procedures. 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]. 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 Krishnan & Daley Expires April 29, 2010 [Page 5] Internet-Draft Simple DNA October 2009 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. 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 neighbor discovery or DHCPv6 probes o Response gathering and assessment These steps are described below. Krishnan & Daley Expires April 29, 2010 [Page 6] Internet-Draft Simple DNA October 2009 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 be 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 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 identifies the set of operable IPv6 addresses (candidate set) that it wishes to use. 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 Neighbor 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. Krishnan & Daley Expires April 29, 2010 [Page 7] Internet-Draft Simple DNA October 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. Link Layer Header: Destination Address: The link-layer (MAC) 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 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 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 the Source link-layer address option in the probe messages. Krishnan & Daley Expires April 29, 2010 [Page 8] Internet-Draft Simple DNA October 2009 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. 4.7. Response Gathering When a responding Neighbor 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.). Krishnan & Daley Expires April 29, 2010 [Page 9] Internet-Draft Simple DNA October 2009 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. 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.7.1. Conflicting results It is possible that the DHCPv6 exchanges 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 DHCPv6. 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 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 Krishnan & Daley Expires April 29, 2010 [Page 10] Internet-Draft Simple DNA October 2009 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 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 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 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 Krishnan & Daley Expires April 29, 2010 [Page 11] Internet-Draft Simple DNA October 2009 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. Krishnan & Daley Expires April 29, 2010 [Page 12] Internet-Draft Simple DNA October 2009 5. 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 */ /* 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)); Krishnan & Daley Expires April 29, 2010 [Page 13] Internet-Draft Simple DNA October 2009 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)); foreach SDAT_Entry in SDAT_Entry_List { /* Address is operable. Configure on Interface */ } Figure 1: Pseudocode for Simple DNA Krishnan & Daley Expires April 29, 2010 [Page 14] Internet-Draft Simple DNA October 2009 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 SEND_NA_GRACE_TIME Definition: An optional period to wait after Neighbor Solicitation before adopting a non-SEND RA's link change information. Value: 40 milliseconds 7. 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 goal. Another difference is that this document also supports stateless autoconfiguration of addresses in addition to addresses configured using DHCPv6. 8. IANA Considerations There are no changes to IANA registries required in this document. 9. Security Considerations 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 Neighbor 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 April 29, 2010 [Page 15] Internet-Draft Simple DNA October 2009 respond. If the current default router is a SEND-secured router, the host SHOULD wait SEND_NA_GRACE_TIME after transmission before adopting a new default router. 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. 10. Acknowledgments This document is the product of a discussion 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, Jari Arkko, 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. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 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., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [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, Krishnan & Daley Expires April 29, 2010 [Page 16] Internet-Draft Simple DNA October 2009 September 2007. 11.2. Informative References [I-D.ietf-dna-protocol] Narayanan, S., "Detecting Network Attachment in IPv6 Networks (DNAv6)", draft-ietf-dna-protocol (work in progress), June 2007. [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. 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 necessary. 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 (stateless autoconfig or DHCPv6) is being used (say NET2). Since the host can obtain a dynamic address in some situations, it will need to send simple DNA probes and may also engage in a DHCPv6 exchange. In a situation where the host moves to NET1 and the NS probes are lost and in addition an RA is 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 Krishnan & Daley Expires April 29, 2010 [Page 17] Internet-Draft Simple DNA October 2009 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 with Simple DNA. 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 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 April 29, 2010 [Page 18]