Network Working Group S. Park Internet-Draft Samsung Electronics June 7, 2004 Y. Han Samsung AIT G. Daley Monash University CTIE IPv6 DAD Optimization Goals and Requirements draft-park-dna-ipv6dadopt-requirement-03.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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 expires December 6, 2004. Abstract In order to generate a unique address, IPv6 nodes perform the Duplicate Address Detection (DAD) procedure. Payload packets can not be sent or received before this procedure is complete. In an environment where frequent movements are expected, this delay can be problematic. As the reduction or removal of the delay would be useful, an optimized version of DAD has been proposed. This document suggests the requirements for such "Optimized DAD" protocol as well as considerable solutions. Park, et al. [Expires: December 6,2004] [Page 1] Internet-Draft IPv6 DAD Optimization June 7, 2004 Table of Contents 1. Introduction..................................................2 2. Terminology...................................................3 3. Current Problem Statements in IPv6 DAD........................3 4. IPv6 DAD Optimization Goals and Requirements..................4 5. IANA Considerations...........................................7 6. Security Considerations.......................................7 7. References....................................................7 7.1 Informative Reference...................................7 7.2 Normative References....................................7 8. Authors Addresses.............................................8 9. Acknowledgements..............................................8 10. Full Copyright Statement.....................................9 1. Introduction The current specifications for detecting duplicate IPv6 addresses are described in [RFC 2461] with use of Neighbor Solicitation and Neighbor Advertisement messages [RFC 2462]. An IPv6 node has to perform a DAD procedure before it tries to assign its a unicast address to its interface, regardless of whether it is obtained through stateful, stateless or manual configuration. This utility is one of IPv6 advantages against IPv4, however, this procedure prevents an IPv6 node from transmitting and receiving a packet with a new address on a link within the first second of attachment. Real-time services require layer 3 handovers between IPv6 networks to be completed quickly and with minimal packet loss. However, the DAD described in [RFC 2461] is a time consuming process, particularly when nodes in need of seamless handover run it and all IPv6 nodes must perform DAD every time they handover between IPv6 networks. During DAD time, any active communications of nodes are interrupted, and this is especially unsuitable for real-time services. This document outlines the goals expected from IPv6 DAD Optimization support and defines the requirements that must be met by IPv6 DAD Optimization solutions. Park, et al. [Expires: December 6, 2004] [Page 2] Internet-Draft IPv6 DAD Optimization June 7, 2004 2. Terminology 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 RFC 2119 [KEYWORDS]. o DAD Duplicate Address Detection, detecting duplicated IPv6 addresses prior to assign its interface. o IPv6 DAD Optimization optimized procedure for DAD when an IPv6 node generates its own addresses. Most related terminologies in this document are described in [RFC 2461] [RFC 2462]. 3. Current Problem Statements in IPv6 DAD This section tries to clarify the problems in the current DAD. This document only considers the latency introduced by DAD. There are also other protocols that introduce additional network attachment latency such as Router Discovery, DHCP Server latency, AAA latency, etc., which will be discussed in a separate document and elsewhere. PS 1: Introduction of Random Start Delays If a node's interface is attached to a link, the Neighbor Solicitation is the first message to be sent from the interface. According to RFC 2462, the node should delay sending the message by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY (default: 1000 ms) as specified in [RFC 2462] to reduce congestion when many nodes start up on the link at the same time, such as after a power failure, and may help to avoid race conditions when more than one node is trying to solicit for the same address at the same time. The impact of this constraint on the performance of DAD can be severe. PS 2: Introduction of Delays through Response Windows An address is Tentative while it is tested for its uniqueness. It is considered unique if none of tests indicates the presence of a Park, et al. [Expires: December 6, 2004] [Page 3] Internet-Draft IPv6 DAD Optimization June 7, 2004 duplicate address within RetransTimer (default: 1000 ms) after having sent DupAddrDetectTransmits (default: one) Neighbor Solicitations. Once an address is determined to be unique, it may be assigned to an interface. A tentative address that is determined to be a duplicate address must not be assigned to an interface. If DupAddrDetectTransmits value is more than one, each Neighbor Solicitation message should be sent by RetransTimer time without assigning the address to its interface. When a node attaches to a link, consequently, it has to wait for 2000 ms at the worst case (with only defalt values for MAX_RTR_SOLICITATION_DELAY, RetransTimer, and DupAddrDetectTransmit). 4. IPv6 DAD Optimization Goals and Requirements This section defines a set of goals and requirements for IPv6 DAD Optimization. Within this section, future solutions which embody the goals presented here are referred to as DAD Optimization solutions. A proper support for a node to send or receive packets immediately after attaching to a link is undermined by the disruption imposed by the current DAD. The goal of this section is to make an offer some hints to develop a DAD Optimization protocol. As one of solutions, we can think that the RetransTimer value can be simply reduced in a constrained address domain with proper justification. Also, a node can leave out random delay if the implementation already has a behavior that desynchronizes the steps that happen before DAD in the case that multiple nodes experience handover at the same time. Such desynchronizing behaviors might be due to random delays in the L2 protocols or device drivers. A full-fledged DAD Optimization may reveal two distinct strategies: Stateless DAD and Stateful DAD, which may be used to develop new DAD schemes. Such classification of strategies is determined according to whether the DAD states of addresses are stored in a node until they are allocated. o Stateless DAD Optimization In this strategy, the DAD states of addresses are not stored in a node. This strategy attempt to detect duplicate addresses without relying on a centralized server or router to keep track of the DAD states of addresses, instead relying on the already configured nodes to cooperate in the DAD process. A DAD Optimization protocol can be developed based on the premise that DAD is far more likely to Park, et al. [Expires: December 6, 2004] [Page 4] Internet-Draft IPv6 DAD Optimization June 7, 2004 succeed than fail. Although an address is even randomly auto- configured, DAD is far more likely to succeed than fail by a factor of at least 10,000,000,000 to one [RANDOM]. So, a DAD Optimization protocol can make DupAddrDetectTransmit zero. But, it must propose a sophisticated recovery mechanism by way of precaution against the address collision. o Stateful DAD Optimization Stateful DAD Optimization can maintain knowledge of the DAD states of addresses by monitoring or brokering address usages. Nodes which centrally store the states are then queried by other nodes which desire a quick resolution to DAD procedures. In order to support this strategy, the mechanism which is used to collect the DAD states must therefore be supported by all nodes on the link, even if they do not support the DAD Optimization protocol. o Requirements for IPv6 DAD Optimization RQ 1: Backwards Compatibility with Original DAD The optimized DAD mechanism MUST NOT break the RFC 2462 DAD mechanism, if used on the link by other nodes. RQ 2: IPv6 Neighbor Cache Changes to peers' Neighbor Caches which are due to DAD Optimization MUST be repaired in the case of a collision. Additionally, cache state created by DAD Optimization SHOULD be updated upon completion of DAD procedures if the created state could cause inconsistent neighbor discovery behavior. RQ 3: Host Modifications The DAD Optimization SHOULD allow for the use of original DAD and ND(Neighbor Discovery) to a host even if a host wants to be modified for DAD Optimization. For DAD Optimization, a host including neighbor MUST recognize modifications such as specific fields, flags, values, etc. RQ 4: Router Modifications Park, et al. [Expires: December 6, 2004] [Page 5] Internet-Draft IPv6 DAD Optimization June 7, 2004 A router which has been modified for DAD Optimization should interoperate with both the host modification for DAD Optimization as well as unmodified nodes. RQ 5: Interoperability with SEND The optimized DAD mechanism SHOULD work when SEND (Secure Neighbor Discovery) is used. It is desirable that the SEND and DAD Optimization work are closely coordinated so that it DAD Optimization could benefit from SEND and vice versa. RQ 6: Simultaneous Operation with DNA It SHOULD be possible to use optimized DAD addresses even before the DNA (Detecting Network Attachment) [DNAWG] process has been completed. In other words, the hosts SHOULD be allowed to send packets to a newly attached link with the assumption that the link may be the same one that was previously used, without needing to wait for the DAD and/or DNA procedures to complete. Such practice MAY result in packet loss, and it MUST NOT cause packet storms or excessive traffic in the case the newly attached link is not the previously used one and steal service from another node in the case that there is a collision, in a way which is not recoverable using [RFC 2462] DAD defense. RQ 7: Address Duplication Considerations In the case that collision occurs, the configuring node MUST inform the owner (or simultaneously configuring node) that the configuration attempt has occurred. In [RFC 2462], this occurs through the sending of the original Neighbor Solicitation packet. Additionally, if intermediate neighbor cache state on peers has been created, it MUST be repaired in conformance to RQ2. RQ 8: Layer 2 Considerations Generally, address duplication is happened to the same Interface ID which is composed of 48bit/64bit MAC address. Therefore, when same MAC address is existed in the same link, one of these nodes can not make its IPv6 address using address autoconfiguration mechanism. At this case, all nodes MUST be allowed to generate new addresses by another mechanism. It should be clarified that the mechanisms should be more discussed in the near future. Park, et al. [Expires: December 6, 2004] [Page 6] Internet-Draft IPv6 DAD Optimization June 7, 2004 5. IANA Considerations There are no IANA considerations in this document. 6. Security Considerations The DAD Optimization scheme SHOULD NOT introduce any new attacks on Neighbor Discovery and the resulting schemes should be no worse than existing DAD [RFC 2462]. There are existing security concerns with Neighbor Discovery and Stateless Address Autoconfiguration. These schemes SHOULD interoperate with Secure Neighbor DAD mechanisms as defined in SEND Working Group. 7. References 7.1 Informative Reference [RFC 2462] Thomson, S., Narten, T., "IPv6 Stateless Address Autoconfiguration" RFC 2462, December 1998. [RFC 2461] Narten, T. et. al., "Neighbor Discovery for IPv6" RFC 2461, December 1998. [RANDOM] M. Bagnulo, I. Soto, A. Garcia-Martinez, A. Azcorra, Ramdon generation of interface identifier, January 2002. 7.2 Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [DNAWG] "http://www.ietf.org/html.charters/dna-charter.html", Charter of DNA Working Group, IETF. Park, et al. [Expires: December 6, 2004] [Page 7] Internet-Draft IPv6 DAD Optimization June 7, 2004 8. Authors' Addresses Soohong Daniel Park Mobile Platform Laboratory, Samsung Electronics Email: soohong.park@samsung.com Youn-Hee Han Samsung Advanced Institute of Technology i-Networking Laboratory Email: yh21.han@samsung.com Greg Daley Centre for Telecommunications and Information Engineering Department of Electrical and Computer Systems Engineering Monash University Email: greg.daley@eng.monash.edu.au 9. Acknowledgements Specially thanks are due to Pekka Nikander(Ericsson Research Nomadiclab), Pyungsoo Kim(Samsung Electronics), Jinhyeock Choi(Samsung AIT) and Jari Arkko(Ericsson) for their many useful comments. Park, et al. [Expires: December 6, 2004] [Page 8] Internet-Draft IPv6 DAD Optimization June 7, 2004 10. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC editor function is currently provided by the internet Society. Park, et al. [Expires: December 6, 2004] [Page 9]