Network Working Group S. Krishnan Internet-Draft Ericsson Intended status: Standards Track G. Daley Expires: August 28, 2008 NetStar Networks February 25, 2008 Simple procedures for Detecting Network Attachment in IPv6 draft-krishnan-dna-simple-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 28, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract Detecting Network Attachment allows hosts to assess if its existing addressing or routing configuration is valid for a newly connected network. This document provides simple procedures for detecting network attachment in IPv6 hosts, and procedures for routers to support such services. Krishnan & Daley Expires August 28, 2008 [Page 1] Internet-Draft Simple procedures for DNAv6 February 2008 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. DNA Roles . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 3. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Host data structures . . . . . . . . . . . . . . . . . . . 5 3.2. Link-Layer Indication . . . . . . . . . . . . . . . . . . 5 3.3. Optimistic DAD . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Sending RS and NS probes . . . . . . . . . . . . . . . . . 6 3.5. Response Gathering . . . . . . . . . . . . . . . . . . . . 6 3.6. Further Host Operations . . . . . . . . . . . . . . . . . 7 3.6.1. Actions upon return to a link . . . . . . . . . . . . 7 3.6.2. Actions upon arrival at a new link . . . . . . . . . . 7 4. Router Operations . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Tentative Option Processing . . . . . . . . . . . . . . . 8 4.2. Fast Unicast Response to Router Solicitation . . . . . . . 8 4.2.1. Fast Router Advertisement Transmission . . . . . . . . 8 4.3. Additional Router Procedures . . . . . . . . . . . . . . . 8 4.4. Recommended retransmission behavior . . . . . . . . . . . 8 5. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Remaining Issues . . . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Krishnan & Daley Expires August 28, 2008 [Page 2] Internet-Draft Simple procedures for DNAv6 February 2008 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 [1]. 2. Introduction Hosts require procedures to simply and reliably identify if they have moved to a different IP network to the one which they have been recently connected. In order to detect change, router and neighbour discovery messages are used to collect reachability and configuration information. This information is used to detect whether the existing router and address prefixes are likely to be present. This document incorporates feedback from host and router operating systems implementors, which seeks to make implementation and adoption of IPv6 change detection procedures simple for general use. The goal of this document is to specify a simple procedure for detecting network attachment (Simple DNA) that has the following characteristics. o Routers do not have to be modified to support this scheme. o Handle only the simplest and most likely use cases. o Work at least as quickly as standard neighbor discovery. o False positives are not acceptable. A host should not conclude that there is no link change when there is one o False negatives are acceptable. A host can conclude that there is a link change when there is none 2.1. DNA Roles Detecting Network Attachment is performed by hosts by sending IPv6 neighbour discovery and router discovery messages to routers after connecting to a network. It is desirable that routers adopt procedures which allow for fast unicast Router Advertisement (RA) messages. Routers that follow the standard neighbor discovery procedure described in [2] 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 [2]. This delay can be significant and may result in service Krishnan & Daley Expires August 28, 2008 [Page 3] Internet-Draft Simple procedures for DNAv6 February 2008 disruption. Please note that support for fast unicast RAs is not necessary since the simple dna procedure can continue to work using the NS/NA exchange, which will complete earlier than the RA arrives. The host detects that the link-layer may have changed, and then simultaneously probes the network with Router Solicitations (RSs) and Neighbour Solicitations (NSs). The host uses advertisements to determine if the routers it currently has configured are still available. 2.2. Applicability 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 [2]. If systems do not meet these assumptions or if systems seek deterministic change detection operations they are directed to follow the complete dna procedure as defined in [6]. 3. Host Operations When a host has an existing configuration for IP address prefixes and next hop routing, it may be disconnected from its link-layer, and then subsequently reconnect the link-layer on the same interface. When the link-layer becomes available again, it is important to determine whether the existing addressing and routing configuration are still valid. In order to determine this, the host performs the detecting network attachment procedure. Krishnan & Daley Expires August 28, 2008 [Page 4] Internet-Draft Simple procedures for DNAv6 February 2008 3.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). 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 The steps involved in basic detection of network attachment are: o Link-Layer Indication o Optimistic DAD o Sending RS and NS probes o Response gathering and assessment These steps are described below. 3.2. 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 [7]. When the indication is received, the host marks all currently configured (non-tentative) IP addresses to Optimistic state [5]. 3.3. Optimistic DAD All Router Solicitations and unicast Neighbour Solicitations sent for DNA purposes while addresses are in optimistic state SHOULD include the Tentative Option [4]. This allows for DAD-safe transmission of unicast response to solicitation, even if the router has no existing Neighbour Cache entry for the solicitor. Krishnan & Daley Expires August 28, 2008 [Page 5] Internet-Draft Simple procedures for DNAv6 February 2008 3.4. Sending RS and NS 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 containing one of the host's optimistic unicast source address [2][5]. If the host is in possession of more than one valid IPv6 address, it MUST send only one router solicitation using any one of its valid IPv6 addresses as the source address.. For the purpose of sending neighbor solicitations to previous routers, the host first needs to pick a subset of operable IPv6 addresses (candidate set) that it wishes to use. How this subset of addresses is picked is based on host configuration. e.g. The host may select configured addresses from each of zero, one or two previously connected links. If the addresses obtained from a previous router are no longer valid, the host does include these addresses in the candidate set for NS based probing. For each of the addresses in the candidate set, the host looks up the SDAT to find out the link local and MAC addresses of the router that advertised the prefix used to form the address. It then sends an unicast Neighbor Solicitations to each router's link local address it obtained from the lookup on the SDAT. The host SHOULD NOT send unicast Neighbor Solicitations to a test node corresponding to an IPv6 address that is no longer valid. Please note that the Neighbour Solicitations SHOULD be sent in parallel with the Router Solicitations. Since sending NSs is just an optimization, doing the NSs and RSs in parallel ensures that the procedure does not run slower than it would if it only used an RS. Be aware that each unicast solicitation which is not successful may cause packet flooding in bridged networks, if the networks are not properly configured. This is further described in Section 6. Where flooding may cause performance issues within the LAN, host SHOULD limit the number of unicast solicitations. 3.5. Response Gathering When a responding Neighbour Advertisement is received from a test node, the host MUST verify that both the IPv6 and link layer (MAC) addresses of the test node match the expected values before utilizing the configuration associated with the detected network (prefixes, MTU etc.). On reception of a Router Advertisement which contains prefixes which Krishnan & Daley Expires August 28, 2008 [Page 6] Internet-Draft Simple procedures for DNAv6 February 2008 intersect with those previously advertised by a known router, the host utilizes the configuration associated with the detected network. If after sending an RS, a host receives a solicited router advertisement containing only prefixes which are disjoint from known advertised prefixes, the host SHOULD conclude that none of its operable IPv6 addresses are valid and that it has moved to a new link. Where the conclusions obtained from the Neighbor Solicitation/ Advertisement and the RS/RA exchange differ, the RS/RA will be considered definitive. 3.6. Further Host Operations Operations subsequent to detecting network attachment depend upon whether change was detected. 3.6.1. Actions upon return to a link Upon arrival at a previously visited link, the host should assess whether it can use the existing configured addresses using Optimistic Duplicate Address Detection [5]. Also, the host SHOULD rejoin any solicited nodes' multicast groups for addresses it continues to use, and select a default router [2]. 3.6.2. Actions upon arrival at a new link Upon arrival on a new link, the host should unconfigure its existing addresses and routers, and begin address configuration techniques, as indicated in the received Router Advertisement [2][8]. 4. Router Operations Routers wishing to support host change detection need to respond quickly to queries. Basic support for DNA for IPv6 requires: 1. Tentative Option processing 2. Fast Unicast Response to Solicitation with Token Buckets These procedures allow for a host to receive immediate response to a router solicitation, and may simplify a host's internal change detection operations. A detailed description is provided in the following sections. Krishnan & Daley Expires August 28, 2008 [Page 7] Internet-Draft Simple procedures for DNAv6 February 2008 4.1. Tentative Option Processing Hosts checking their network attachment are unsure of their address status, and may be using Tentative link-layer addressing information in their router or neighbour solicitations. A router which desires to support hosts' DNA operations MUST process Tentative Options from unicast source addressed Router and Neighbour Solicitations, as described in [4] . 4.2. Fast Unicast Response to Router Solicitation In order to provide fast response to router solicitation the router removes the random delay before sending a unicast response to a Router Solicitation. 4.2.1. Fast Router Advertisement Transmission To control the rate at which Router Advertisements are sent, the router maintains a token bucket per-interface, whereby fast RAs are only transmitted when a token is available [6]. The bucket receives a token every UNICAST_RA_INTERVAL, unless the bucket already contains MAX_UNICAST_RA_BURST tokens. When the router receives a Router Solicitation containing a unicast source address it SHOULD send a unicast router advertisement to the solicitor's address without delay if there are remaining tokens in the bucket. Each such transmission consumes one token. When there are no remaining tokens, the router SHOULD send a solicited Router Advertisement, as described in RFC 4861 [2]. 4.3. Additional Router Procedures As described, the system used here may not be applicable to all environments. Therefore the fast response advertisement mechanisms for simple IPv6 DNA MUST be configurable. When disabled the host would revert to existing IPv6 Neighbour discovery behaviour [2]. 4.4. 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 and use the results obtained from the RS probe instead, unless the Krishnan & Daley Expires August 28, 2008 [Page 8] Internet-Draft Simple procedures for DNAv6 February 2008 address confirmed via the NS probe was manually assigned. 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 [RFCDHCPv6], scheduling DNAv6 retransmissions between Router Solicitation or DHCPv6 retransmissions. If a response is received to any unicast Neighbor Solicitation, Router Solicitation or DHCPv6 message, pending retransmissions MUST be canceled. A Simple DNA implementation SHOULD NOT retransmit a Neighbor Solicitation no more than twice. To provide damping in the case of spurious Link Up indications, the host SHOULD NOT perform the the Simple DNA procedure more than once a second. 5. Constants These constants are described as in [6]. UNICAST_RA_INTERVAL Definition: The interval corresponding to the maximum average rate of Router Solicitations that the router is prepared to service with unicast responses. This is the interval at which the token bucket controlling the unicast responses is replenished. Value: 50 milliseconds MAX_UNICAST_RA_BURST Definition: The maximum size burst of Router Solicitations that the router is prepared to service with unicast responses. This is the maximum number of tokens allowed in the token bucket controlling the unicast responses. Krishnan & Daley Expires August 28, 2008 [Page 9] Internet-Draft Simple procedures for DNAv6 February 2008 Value: 20 SEND_NA_GRACE_TIME Definition: An optional period to wait after Neighbour Solicitation before adopting a non-SEND RA's link change information. Value: 40 milliseconds 6. Remaining Issues These issues are still outstanding within the document, and the simple DNA solution in general. Identification of Fast advertising Simple DNA routers to other routers. Other protocols attempt to desynchronize Router Advertisements while still allowing fast RA response [6]. In an environment where it is safe to use Simple DNA, it may not be necessary to worry about sending RAs at the same time as other routers. In the case where this specification's Fast Advertisements cause problems due to contention with more sophisticated RA delivery schemes, it SHOULD be turned off as described in Section 4.3. Rate limitation for solicitations. Hosts MAY implement hysteresis mechanisms to pace solicitations where necessary to prevent damage to a particular medium. Implementors should be aware that when such hysteresis is triggered, Detecting Network Attachment may be slowed, which may affect application traffic. 7. IANA Considerations There are no changes to IANA registries required in this document 8. Security Considerations When providing fast responses to router solicitations, it is possible Krishnan & Daley Expires August 28, 2008 [Page 10] Internet-Draft Simple procedures for DNAv6 February 2008 to cause collisions with other signaling packets on contention based media. This can cause repeated packet loss or delay when multiple routers are present on the link. As such the fast router advertisement system is NOT RECOMMENDED in this form for media which are susceptible to collision loss. Such environments may be better served using the procedures defined in [6]. 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 [3] router information is not replaced by an attacker which spoofs an RA and purports to change the link. As such, the host SHOULD send a Neighbour Solicitation to the existing SEND router upon link-up indication as described above in Section 3.2. 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 respond. The host MAY delay SEND_NA_GRACE_TIME after transmission before adopting a new default router, if it is operating on a network where there is significant threat of RA spoofing. Even if SEND signatures on RAs are used, it may not be immediately clear if the router is authorized to make such advertisements. As such, a host SHOULD NOT treat such devices as secure until and unless authorization delegation discovery is successful. It is easy for hosts soliciting without SEND to deplete a SEND router's fast advertisement token buckets, and consume additional bandwidth. As such, a router MAY choose to preserve a portion of their token bucket to serve solicitations with SEND signatures. 9. Acknowledgments This document is the product of a discussion between the authors had with Bernard Aboba, Thomas Narten, Erik Nordmark and Dave Thaler at IETF 69. The authors would like to thank them for clearly detailing the requirements of the solution and the goals it needed to meet and for helping to explore the solution space. The authors would like to thank the authors and editors of the complete DNA specification for detailing the overall problem space and solutions. The authors would like to thank Jari Arkko for driving the evolution of a simple and Krishnan & Daley Expires August 28, 2008 [Page 11] Internet-Draft Simple procedures for DNAv6 February 2008 probabilistic DNA solution. The authors would like to thank Bernard Aboba, Thomas Narten, Sathya Narayan and Frederic Rossi for performing reviews on the document and providing valuable comments to drive the document forward. 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, December 1998. [3] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [4] Daley, G., Nordmark, E., and N. Moore, "Tentative Options for IPv6 Neighbour Discovery", draft-ietf-dna-tentative-01 (work in progress), July 2007. [5] Moore, N., "Optimistic Duplicate Address Detection for IPv6", RFC RFC4429, April 2006. [6] Narayanan, S., "Detecting Network Attachment in IPv6 Networks (DNAv6)", draft-ietf-dna-protocol (work in progress), June 2007. 10.2. Informative References [7] Yegin, A., "Link-layer Event Notifications for Detecting Network Attachments", draft-ietf-dna-link-information-03 (work in progress), October 2005. [8] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 4862, December 1998. Krishnan & Daley Expires August 28, 2008 [Page 12] Internet-Draft Simple procedures for DNAv6 February 2008 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 405 494849 Email: gdaley@netstarnetworks.com Krishnan & Daley Expires August 28, 2008 [Page 13] Internet-Draft Simple procedures for DNAv6 February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Krishnan & Daley Expires August 28, 2008 [Page 14]