Internet Draft H. Kitamura NEC Corporation S. Ata Osaka City University M. Murata Osaka University Expires January 2010 July 27, 2009 Harmless IPv6 Address State Extension (Uncertain State) 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 January 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. H. Kitamura Expires January 2010 [Page 1] Internet Draft IPv6 Uncertain Address State Abstract This document describes a new IPv6 address state called "Uncertain" address state as an extension of IPv6 address state specification. "Uncertain" address state is designed to introduce two functionalities. One is to achieve "Temporary Address Reservation" function. The other is to avoid a DAD (Duplicate Address Detection) time consuming problem for dynamically created addresses. New "Uncertain" Address State is inserted between "Tentative" address state and "Valid" address state. After "Tentative" address state (DAD operation has finished) for a newly created address, its state will enter to "Uncertain" address state. While an address stay at "Uncertain" address state, the address is behaved as if it is temporary reserved by the node exclusively. (The other nodes can not obtain such a reserved address.) When it becomes really necessary for the node to utilize the temporary reserved address, its address state is changed into "Valid" address state without accompanying time consuming DAD operation. By these procedures, we can avoid the DAD problem. H. Kitamura Expires January 2010 [Page 2] Internet Draft IPv6 Uncertain Address State 1. Introduction This document describes a new IPv6 address state called "Uncertain" address state as an extension of IPv6 address state specification. "Uncertain" address state is designed to introduce two functionalities. One is to achieve "Temporary Address Reservation" function. The other is to avoid a DAD (Duplicate Address Detection) time consuming problem for dynamically created addresses. New "Uncertain" Address State is inserted between "Tentative" address state and "Valid" address state. After "Tentative" address state (DAD operation has finished) for a newly created address, its state will enter to "Uncertain" address state. While an address stay at "Uncertain" address state, the address is behaved as if it is temporary reserved by the node exclusively. (The other nodes can not obtain such a reserved address.) When it becomes really necessary for the node to utilize the reserved address, its address state is changed into "Valid" address state without accompanying time consuming DAD operation. By these procedures, we can avoid the DAD problem. "Uncertain" address state is realized by not replying to NS (Neighbor Solicitation) query messages for L2 address resolving for temporary reserved addresses. Since this method is achieved by just only changing current NS messages handling implementation from reply to ignore (not reply), it is very simple and easy to implement. Furthermore, "Uncertain" address state extension is harmless and can coexist with current implementations without causing any problems, because it is realized by ignoring existing NS messages for L2 address queries. The Uncertain address state specification has been implemented, and its basic functionalities have been verified. 2. Problems on Dynamically Generated Addresses There are two types of problems on dynamically generated addresses (e.g., CoA (care of address) of Mobile IP [RFC3775], Ephemeral Address [Ephemeral]). One is DAD time consuming problem. The other is temporary address reservation function missing problem. H. Kitamura Expires January 2010 [Page 3] Internet Draft IPv6 Uncertain Address State 2.1 DAD time consuming problem In the IPv6 specifications [RFC4861][RFC4862], the DAD procedure is defined. All addresses verified their values' uniqueness before they become "Valid" address state by using the DAD operation. While the DAD operation is running, their address state is called "Tentative". So, state of all addresses are changed into "Tentative" -> "Valid" -> "Invalid". (See left figure of Fig.1.) Since the DAD operation adopts NO-reply type duplicate verification method, it takes long time. (In typical Ethernet situation, it takes one second.) This becomes a big problem for a user who would like to use dynamically generated addresses soon after they are generated. In order to meet this problem, two types of solution approaches are known. One is to "SKIP" DAD operation. It is based on an optimistic assumption that address collision rate is too low. Optimistic DAD method [RFC4429] is categorized into this type. This method is very effective from realistic viewpoints, but this method would not become a perfect solution. If address collision happens, we have to pay much cost to fix the case. The other is to "DO" DAD operation every time, but timing when DAD operation is done is changed. In this method, address collision never happens, and we don't have to worry about address collision cases. No bad effects to the existing implementations are found in this method. This document chooses the latter method, and DAD operation timing is changed. 2.2 Temporary address reservation function missing problem In the IPv6 specifications, no temporary address reservation function is defined. Therefore, it is impossible for nodes to reserve addresses for future use with current IPv6 specification. (In the DHCPv6, address pool function exists. However, addresses are not truly reserved in such a pool. Even if an address is located at the pool, it can be used (robbed) by a node that is not related with the pool.) It is required that true address reserving function is achieved. 3. Design and Definitions of Uncertain Address State In order to meet above described two problems, an idea "Uncertain" address state is introduced. "Uncertain" Address State is inserted H. Kitamura Expires January 2010 [Page 4] Internet Draft IPv6 Uncertain Address State between "Tentative" address state and "Valid" address state. Fig. 1 shows an overview of "Uncertain" Address State. ...............-----+--- . [ : . Tentative< : . [ : . [ V . ...............----+--- . . [ ->: ] . . +=========+ [ / : ] . . |Uncertain|< | : ] -----+---.. . +=========+ [ | : >(Preferred) [ : . [ \ : ] Tentative< : . [ \ : ] [ : . [ \: ] [ V . [ V ] Change -----+---.......................-------+--- State [ ->| ] [ ->| ] [ / | ] [ / | ] Valid< | | ] Valid< | | ] [ \ | >(Preferred) [ \ | >(Preferred) [ |\ | ] [ |\ | ] [ | \| ] |\ [ | \| ] [ | | ] +-------+ \ [ | | ] [ | | ] +-------+ / [ | | ] [ \ V--- |/ [ \ V --- [ \ | ] [ \ | ] [ \| ] [ \| ] [ | >(Deprecated) [ | >(Deprecated) [ | ] [ | ] [ V ] [ V ] ------+--- -------+--- [ : [ : Invalid< : Invalid< : [ : [ : [ V [ V Current Proposed Fig. 1 Overview of Uncertain Address State After "Tentative" address state (DAD operation has finished) for a newly created address, its state will enter to "Uncertain" address state. While an address stay at "Uncertain" address state, the address is behaved as if it is temporary reserved by the node exclusively. (The other nodes can not obtain such a reserved address.) When it becomes really necessary for a node to utilize H. Kitamura Expires January 2010 [Page 5] Internet Draft IPv6 Uncertain Address State the reserved address, its address state is changed into "Valid" address state without accompanying time consuming DAD operation. By these procedures, we can avoid the DAD problem and achieve address reserving function. 3.1 How to Implement "Uncertain" Address State +--------+ +----------+ +-----------+ |Node who| | Node who | | Node who | |reserves| +-------+ | wants to | | tries to | | and set| | Node | |set Addr.X| | talk with | | Addr.X | |on Link| | lately | |Addr.X Node| +--------+ +-------+ +----------+ +-----------+ |DAD Query | | | | NS | | | (Beginning) |(src = ::) | | | -----------+----------->|---------->|-------------------->| [ |<...........| | | [ |<.......................| | Tentative< |<.............................................| [ |No Reply NA | | | ----------+ | | | [ | | |DAD Query | ========= [ |<-----------+-----------|NS (src = ::) | Uncertain< |------------+---------->| | ==========[ | Reply NA | | | (Temp. Reserv | to show | | | in Pool) | duplication| | | ================= | | | !Important Point! | |L2 Address Query for | ================= | | Addr. X | [ * | | NS(src not= ::) | [ *@*<----------|<----------|<--------------------| [ *.............................................>| [ |!Not! Reply | | | [ | NA to tell | | | [ | L2 Address | | | (Pop from Pool| | |L2 Address Query for | and Set) | | | Addr. X | --------->+ | | NS(src not= ::) | [ |<-----------|<----------|<--------------------| [ |------------+-----------+-------------------->| Valid< | !!Reply!! | | | [ | NA to tell | | | [ | L2 Address | | | Fig. 2 ND messages handling sequences H. Kitamura Expires January 2010 [Page 6] Internet Draft IPv6 Uncertain Address State In order to implement "Uncertain" address state, we analyze behaviors and operations at Tentative and Valid address state and how Neighbor Discovery messages are handled with on nodes. Fig. 2 shows ND messages handling sequences. We notice that there are two types of NS (Neighbor Solicitation) messages. One is NS messages for DAD query. The other is NS messages for L2 Address query. These messages are distinguishable, because source address of the NS for DAD query message IS unspecified (::) and that of the NS for L2 Address query IS NOT unspecified (::). At Tentative address state: a node issues NS for DAD query message(s) only At "Uncertain" address state: a node receives NS for DAD query messages, and replies them by NA messages. a node receives NS for L2 Address query messages, but does NOT reply them. At Valid address state: a node receives NS for DAD query messages, and reply them by NA messages. a node receives NS for L2 Address query messages, and REPLY them by NA messages. Difference between "Uncertain" and Valid address states exist on behaviors when a node receives NS for L2 Address query messages. By replying to NS for DAD query message, an address is not obtained (robbed) by other nodes, and a temporary address reserving function is achieved. By NOT replying to NS for L2 Address query messages, an address is never utilized by any nodes. Essential part of the Uncertain State is achieved by not replying the NS for L2 Address query messages. Since the state is achieved by just not replying method, it does not cause any problems to communicate the existing nodes that do not implement the Uncertain State specifications. H. Kitamura Expires January 2010 [Page 7] Internet Draft IPv6 Uncertain Address State 4. Security Considerations Security Considerations of IPv6 address [RFC4861][RFC4862] can also be applied to Uncertain address state. There is nothing special on the Uncertain address state. However, Uncertain address state can provide new feature (temporary address reserving function). Temporary address reserving related considerations may be needed. 5. IANA Considerations This document has no actions for IANA. Appendix A. Implementations The Uncertain address state specification has been implemented under the following environments, and its basic functionalities have been verified OS: FreeBSD6.2R (32bit / 64bit) CPU: i386 / amd64 Acknowledgment A part of this work is supported by the program: SCOPE (Strategic Information and Communications R&D Promotion Programme) operated by Ministry of Internal Affairs and Communications of JAPAN. References Normative References [RFC4861] T. Narten, E. Nordmark, W. Simpson, and H. Soliman, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September 2007 [RFC4862] S. Thomson, T. Narten, and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007 Informative References [Ephemeral] H. Kitamura, S. Ata, and M. Murata, "IPv6 Ephemeral Addresses" work in progress, July 2009 H. Kitamura Expires January 2010 [Page 8] Internet Draft IPv6 Uncertain Address State [RFC4429] N. Moore, "Optimistic Duplicate Address Detection (DAD) for IPv6",RFC4429, April 2006 [RFC3775] D. Johnson, C. Perkins, and J. Arkko, "Mobility Support in IPv6", RFC3775, June 2004 Authors' Addresses Hiroshi Kitamura Common Platform Software Research Laboratories, NEC Corporation (Igarashi Building 4F) 11-5, Shibaura 2-Chome, Minato-Ku, Tokyo 108-8557, JAPAN Graduate School of Information Systems, University of Electro-Communications 5-1 Chofugaoka 1-Chome, Chofu-shi, Tokyo 182-8585, JAPAN Phone: +81 3 5476 9795 Fax: +81 3 5476 1005 Email: kitamura@da.jp.nec.com Shingo Ata Graduate School of Engineering, Osaka City University 3-3-138, Sugimoto, Sumiyoshi-Ku, Osaka 558-8585, JAPAN Phone: +81 6 6605 2191 Fax: +81 6 6605 2191 Email: ata@info.eng.osaka-cu.ac.jp Masayuki Murata Graduate School of Information Science and Technology, Osaka Univ. 1-5 Yamadaoka, Suita, Osaka 565-0871, JAPAN Phone: +81 6 6879 4542 Fax: +81 6 6879 4544 Email: murata@ist.osaka-u.ac.jp H. Kitamura Expires January 2010 [Page 9]