Internet Draft H. Kitamura NEC Corporation S. Ata Osaka City University M. Murata Osaka University Expires June 2009 October 27, 2008 Harmless IPv6 Address State Extension (Uncertain State) 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 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 "Address Reservation" function. The other is to avoid a DAD (Duplicate Address Detection) time consuming problem for dynamically created addresses. "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 H. Kitamura Expires June 2009 [Page 1] Internet Draft IPv6 Uncertain Address State will enter to "Uncertain" address state. While an address stay at "Uncertain" address state, the address is behaved as if it is 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. 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 "Address Reservation" function. The other is to avoid a DAD (Duplicate Address Detection) time consuming problem for dynamically created addresses. "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 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 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]). H. Kitamura Expires June 2009 [Page 2] Internet Draft IPv6 Uncertain Address State One is DAD time consuming problem. The other is address reservation function missing problem. 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 Address reservation function missing problem In the IPv6 specifications, no 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 June 2009 [Page 3] 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 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 the reserved H. Kitamura Expires June 2009 [Page 4] Internet Draft IPv6 Uncertain Address State 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 | | | (Reserve in | to show | | | 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 June 2009 [Page 5] 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 unspecifed (::). 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 an 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 June 2009 [Page 6] 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 (address reserving function). 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, October 2008 H. Kitamura Expires June 2009 [Page 7] 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 June 2009 [Page 8] Internet Draft IPv6 Uncertain Address State 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. H. Kitamura Expires June 2009 [Page 9]