Internet Draft H. Kitamura
<draft-kitamura-ipv6-uncertain-address-state-00.txt> NEC Corporation
S. Ata
Osaka City University
M. Murata
Osaka University
Expires June 2009 October 27, 2008
Harmless IPv6 Address State Extension (Uncertain State)
<draft-kitamura-ipv6-uncertain-address-state-00.txt>
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" <draft-kitamura-ipv6-ephemeral-
address-00.txt> 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]