DNA BOF                                                S. Daniel Park 
  Internet-Draft                                    SAMSUNG Electronics 
  Category: Informational                                  Youn-Hee Han 
  Expires : 13 April 2004                                   SAMSUNG AIT 
                                                             Greg Daley 
                                                 Monash University CTIE 
                                                        14 October 2003 
   
                 IPv6 DAD Optimization Goals and Requirements 
                 draft-park-dna-ipv6dadopt-requirement-01.txt 
      
      
  Status of this Memo 
      
     This document is an Internet-Draft and is in full conformance with 
     all provisions of Section 10 of RFC2026 except that the right to 
     produce derivative works is not granted [RFC 2026]. 
      
     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. 
      
      
  Abstract 
      
     In order to generate unique address, an IPv6 node has to perform DAD 
     procedure when the IPv6 node tries to make its own IPv6 address 
     including link-local and global address.  The current procedure for 
     detecting duplicate addresses consumes time delays and does not 
     consider a node to have a fast handover in mobile environment.  A 
     proper support for a node to send or receive packets immediately 
     after attaching to a link is undermined by the disruption imposed by 


   
   
   
   
  Park, et. al.            [Expires: 13 April 2004]             [Page 1] 
   
  Internet-Draft            IPv6 DAD Optimization        14 October 2003 
   
   
   
   
   
     the current DAD.  Therefore, some considerations are required to be 
     suggested for reducing delay due to the detection of IPv6 address 
     collision.  This document outlines the goals expected from IPv6 DAD 
     Optimization support and defines the requirements that must be met 
     by IPv6 DAD Optimization solutions in DNA Working Group. 
      
      
  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..........................................8 
     6.  Security Considerations......................................8 
     7.  References...................................................8 
     8.  Authors Addresses............................................9 
     9.  Acknowledgements.............................................9 
     10. Change log...................................................9 
     11. Full Copyright Statement....................................10 
      
   
   
  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].  In the current 
     specifications, 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 



   
   
   
  Park, et. al.            [Expires: 13 April 2004]             [Page 2] 
   
  Internet-Draft            IPv6 DAD Optimization        14 October 2003 
   
   
   
   
   
     active communications of nodes are interrupted, and this is 
     especially unsuitable for real-time services. 
      
     Recently, some considerations and alternatives are being suggested 
     for DAD Optimization mechanisms to provide fast handover when a 
     mobile node is connected to the new networks in MOBILEIP Working 
     Group for a while and this issue will be discussed in DNA (Detecting 
     Network Attachment) Working Group as work item. 
      
     This document outlines the goals expected from IPv6 DAD Optimization  
     support and defines the requirements that must be met by IPv6 DAD 
     Optimization solutions in DNA Working Group. 
      
      
  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.  The 
     problems are restricted within the limits of the DNA Working Group  
     charter.  Note that this document is only considering the DAD 
     latency except other latencies involved in connecting to a new 




   
   
   
  Park, et. al.            [Expires: 13 April 2004]             [Page 3] 
   
  Internet-Draft            IPv6 DAD Optimization        14 October 2003 
   
   
   
   
   
     network such as Router Discovery, DHCP Server latency, AAA latency, 
     etc., which will be discussed in a separate document as well. 
      
      
     PS 1: Time consuming by Random Delay  
      
     If a node's interface is attached to a link, the Neighbor 
     Solicitation is the first message to be sent from the interface.  So, 
     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.  If a node 
     abides by this constraint, the completion of DAD is delayed by some 
     random amount, increasing the amount of time before a node sends or 
     receives packets immediately after attaching to a link. 
      
     PS 2: Time consuming by Autoconfiguration-related Variables 
      
     An address is Tentative while it is tested for its uniqueness.  It 
     is considered unique if none of tests indicates the presence of a 
     duplicate address within RetransTimer (default: 1000 ms) 
     milliseconds 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 



   
   
   
  Park, et. al.            [Expires: 13 April 2004]             [Page 4] 
   
  Internet-Draft            IPv6 DAD Optimization        14 October 2003 
   
   
   
   
   
     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 
     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 



   
   
   
  Park, et. al.            [Expires: 13 April 2004]             [Page 5] 
   
  Internet-Draft            IPv6 DAD Optimization        14 October 2003 
   
   
   
   
   
     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: Comparison with Original DAD 
      
     When an original DAD is performed to verify address duplication, 
     there happened to be some delays (is defined in [RFC 2462]) in this 
     case. In order to reduce delays, optimized DAD should be required to 
     provide faster handover in the IPv6 mobility. Though, at the same 
     time, it should be noted that the DAD Optimization MUST NOT break 
     the original DAD mechanism. 
      
      
     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 
     NDP (Neighbor Discovery Protocol) 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: 13 April 2004]             [Page 6] 
   
  Internet-Draft            IPv6 DAD Optimization        14 October 2003 
   
   
   
   
   
     A router which has been modified for DAD Optimization should not 
     interfere with hosts operating correctly.  In particular, a router 
     has to 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 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 
      



   
   
   
  Park, et. al.            [Expires: 13 April 2004]             [Page 7] 
   
  Internet-Draft            IPv6 DAD Optimization        14 October 2003 
   
   
   
   
   
     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. 
      
      
  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 
      
     [RFC 2026]  Bradner, S., "The Internet Standards Process - Revision 
                 3", BCP 9, RFC 2026, October 1996. 
      
     [KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate  
                 Requirement Levels", BCP 14, RFC 2119, March 1997. 
         
     [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. 



   
   
   
  Park, et. al.            [Expires: 13 April 2004]             [Page 8] 
   
  Internet-Draft            IPv6 DAD Optimization        14 October 2003 
   
   
   
   
   
      
      
  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 Greg Delay(Monash University), Pekka 
     Nikander(Ericsson), Pyungsoo Kim(Samsung Electronics) and Jinhyeock 
     Choi(Samsung AIT) for many useful comments. 
      
      
  10.  Change log 
      
      
     Draft <draft-park-dna-ipv6dadopt-requirement-01.txt> 
      
        o RQ 2, RQ 4 and RQ 7 text improvements by Greg Daley and added  
          him as an author 
        o Clarified RQ 4 through text improvements. 
        o Modified section 4 and general text improvements. 
        o Several editorial changes. 
      
      
     Draft <draft-park-dna-ipv6dadopt-requirement-00.txt> 



   
   
   
  Park, et. al.            [Expires: 13 April 2004]             [Page 9] 
   
  Internet-Draft            IPv6 DAD Optimization        14 October 2003 
   
   
   
   
   
      
        o Initial draft 
      
      
  11.  Full Copyright Statement 
      
     Copyright (C) The Internet Society (2003). 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. 
      
     Funding for the RFC editor function is currently provided by the 
     internet Society. 









   
   
   
  Park, et. al.            [Expires: 13 April 2004]            [Page 10]