| TOC |
|
This document proposes an efficient method to speed the address auto-configuration and Duplicate Address Detection (DAD) in IPv6 network and thus greatly decrease the time spend on the address configuration and DAD. This is achieved by modifing the host and router's behaviour and related IPv6 messages.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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.”
This Internet-Draft will expire on November 17, 2010.
Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1.
Introduction
2.
Terminology
3.
Requirements
3.1.
Host's Requirements
3.2.
Access Router's Requirements
4.
General Fast DAD Procedure
5.
Message Format
5.1.
Overview
5.2.
Modified Router Advertisement Message Format
5.3.
Modified Neighbour Solicitation Message Format
5.4.
Modified Neighbour Advertisement Message Format
6.
Modified Host and Router Behaviour
6.1.
Modified Host Behaviour
6.2.
Modified Router Behaviour
7.
The Example Usage in 802.16 Network
8.
IANA Considerations
9.
Security Considerations
10.
References
10.1.
Normative References
10.2.
Informative References
§
Authors' Addresses
| TOC |
IPv6 (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.) [RFC2460] is the Internet Protocol designed for the next generation network. Compared with IPv4, some new features are introduced. Among these new features, Stateless Address Configuration [RFC2462] (Thomson, S. and T. Narten, “IPv6 Stateless Address Autoconfiguration,” December 1998.) allows a host to generate its own IPv6 addresses using a combination of locally available information and information advertised by routers. Routers advertise prefixes that identify the subnet(s) associated with a link, while hosts generate an "interface identifier" that uniquely identifies an interface on a subnet. An address is formed by combining the two. Router sends Router Advertisements (RA) periodically which contain two flags indicating what type of auto-configuration (if any) should be performed. A "managed address configuration" flag indicates whether hosts should use stateless auto-configuration to obtain addresses. The RA message also contains zero or more Prefix Information options that provide on-link prefixes for address auto-configuration.
Upon receiving the RA message, the host generates an IPv6 address based on the received Prefix Information by itself. Then the host performs Duplicate Address Detection (DAD) by sending out a Neighbor Solicitation (NS) message containing the newly generated address. If the address is already used by another host, that host replies with a Neighbor Advertisement (NA) defending the address. Once a defending NA is received, the address auto-configuration process is stopped, another address is re-generated or manual configuration is performed. Once it has sent the NS, the node waits for RetransTimer milliseconds (ms) for a defending NA, and this solicit-and-wait process is repeated DupAddrDetectTransmits times. The default value of RetransTimer is 1000ms and by default the process is done once, resulting in a default delay of 1000ms, i.e., 1 second (s) for DAD.
For Mobile IPv6 [RFC3775] enabled nodes, part of the Layer 3 handover delay is contributed by the configuration of the Care-of-Address (CoA) and DAD when the node moves into a visiting network. From the above analysis, the address configuration and DAD process may add up to 1s delay, which is significant for real-time applications such as VoIP. Hence if we could reduce the time spending on DAD procedure, the whole Mobile IPv6 handover procedure could be speed up.
Some methods have been proposed to reduce the duration time of DAD.
In [RFC4429], Optimistic Duplicate Address Detection is proposed by N. Moore. In this proposal, a new address state, 'Optimistic', is introduced. This state is used to mark an address that is available for use but that has not completed DAD. The use of Optimistic Address is limited, for example, it should not be used as a source address in new communications. However for MIPv6, if the Optimistic Address is used in the Binding Update message as the Care-of-Address before the DAD process is finished, the handover process may be disrupted when duplicated address is detected.
In [END], the Access Router maintains an Address Cache which contains a list of addresses of all connected hosts. To check an address, an MS sends Neighbor Solicitations per RFC2461 and RFC2462. Upon receiving the NS, the Access Router compares the tentative address in the NS against the entries in its Address Cache. If there is no match, the Access Router makes an entry for the (tentative) address in its Address Cache and sends a special Router Advertisement to the MS indicating the address's uniqueness. If there is a match that indicates that the address is conflict with another host, the Access Router relays the NS to the address owner without any modification. Upon receiving the NS, the address owner replies with an NA to defend its address. The Access Router relays the NA to the soliciting MS without any modification. Upon receiving the defending NA, the soliciting MS perceives the address conflict and refrains from assigning the tentative address to the interface. This mechanism reduces the DAD process significantly, however, there is still some delay introduced by the signaling exchange.
Some access networks are point-to-multipoint networks in which the hosts can not communicate with other hosts connected to the same access router and all communication should go through the access router first. For example, in IEEE 802.16 (WiMAX) network [RFC5154], the subscriber station is not capable of multicasting (e.g., for neighbor discovery, IP multicasting services, etc.) or direct communication to the other nodes attached to the same Base Station within the same subnet (prefix).
Proxy Neighbour Discovery (PND) is often used to handle the neighbour discovery problem in the above networks. The access router maintains an address table which contains a list of IPv6 addresses and corresponding link-layer addresses that are being used by all IPv6 hosts in the same subnet. Upon receiving NS, the router would relay the NS message to the solicited host or send back a NA message directly on behalf of the solicited host.
In this document, a fast Stateless Address Auto-configuration and DAD process is proposed, in which an Address Table is used to contain the addresses and their corresponding link-layer addresses of all hosts in the same link. Unlike the standard method as defined in [RFC2462], after the stateless address configuration, an explicit NS message is sent to notify the access router. In addition, since the probability of having a duplicate address is too small, the DAD process is omitted by the host. Instead, the access router performs the DAD on behalf of the host. If duplicate address is detected, then the access router notifies the host to re-generate a new address.
| TOC |
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 BCP 14 [STANDARDS].
| TOC |
| TOC |
The host should set the access router as the default gateway after receiving the RA message from it and all communication should go through the router; The host should be able to process the modified messages as defined below.
| TOC |
The access router should maintain an address table. This table contains the host's IPv6 address, link-layer address, life time and etc. Access routers should process all received NS with specified and unspecified source address and solicited-node-multicast destination address for DAD and address resolving.
| TOC |
When a host boots up or moves into a new network, it sends a Router Solicitation (RS) message to perform router and prefix discovery as defined in [RFC2461]. After receiving a valid RS message, the access router should send a special Router Advertisement (RA) as reply. The RA message is used to indicate the fast address configuration and DAD should be used by the host.
If the host could recognize the special RA message, it generates a stateless IPv6 address as described in RFC2462. Then the host would skip the normal DAD process and sends a special NS message immediately to the access router to notify its configured address.
After receiving the NS message, the access router compares the address in the message against the entries in its Address Table. If there is no match, the access router create an entry contains the address and the corresponding link-layer address of the host.
Otherwise, if there exists a match indicates that the address is duplicate, the access router sends a special NA message to notify the host that duplicate address is detected and another address needs to be generated. Before a new unique address is generated by the host, the access router does not forward the data packet from or to this host.
If the host receives the special NA message, it should abandon the duplicate address contained in the message. And it should re-generate a new stateless address automatically and repeat the above process.
| TOC |
| TOC |
In this document, the messages defined in IPv6 standards are reused and some modification are made as described below:
| TOC |
The fields in the message are as defined in RFC2461 RFC 2461 (Narten, T., Nordmark, E., and W. Simpson, “Neighbor Discovery for IP Version 6 (IPv6),” December 1998.) [RFC2461]except one bit (E bit) is added to the 'Reserved' field. If the access router wants to request the hosts to use the fast stateless address configuration, it must set the 'E' bit of the RA message sent to the hosts in order to indicate the fast address configuration and DAD may be used.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|E|Reserved | Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Information Option |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 1: Modified Router Advertisement Message |
| TOC |
The fields in the message are as defined in RFC2461 except two bits ('E' bit and 'D' bit) is added to the 'Reserved' field. The 'E' bit is set if the host want to register its auto-configured address with the access router explicitly. The 'D' bit is set if the host want to de-register its generated address with the access router explicitly. The 'Target Address' is set to the address auto-configured by the host.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
| Figure 2: Modified Neighbour Solicitation Message |
| TOC |
The fields in the message are as defined in RFC2461. One bit (E bit) is added to the 'Reserved' field. This message is sent to the host by the access router to indicate that duplicate address is detected. The 'Target Address' is the duplicated address detected by the access router.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|S|0|E| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
| Figure 3: Modified Neighbour Advertisement Message |
| TOC |
The host and access router behaviours should be modified to deal with these modified messages.
| TOC |
Upon receiving a RA message, the host should check the 'E' bit of the message to see if the fast stateless address auto-configuration is required. If the 'M' bit is not set and 'E' bit is set, a stateless IPv6 address is generated according to the procedure defined in RFC2462. In the proposed mechanism, the 'Tentative Address' is not used anymore. The generated address is assigned to the host's interface as an effective address and an explicit NS message is send to the access router immediately. In this message, the 'E' bit is set to indicate that this is an explicit registration message for fast DAD.
Afterwards, if a NA message is received and the 'E' bit is set in the message, the host compares the 'Target Address' with its own generated address. If the two addresses are the same, then a duplicate address is detected by the access router. The host must abandon the current assigned address and re-generated an address as defined in RFC2462. As described as above, the data packets sent before the NA message is received are discarded by the router. Because the router would send the NA message to the host immediately after the duplicated address is detected, the impact on the host is small.
When the host wants to move out of the subnet or stop using the address, it sends a NS message with 'D' bit set to the access router to de-register the address explicitly.
If the host can not recognize the 'E' and 'D' bit in the RA and NA message, its behavior is the same as defined in RFC2462.
| TOC |
In the proposed mechanism, the 'E' bit is set in the RA message to indicate the fast address configuration and DAD are used. The RA message is sent periodically or when a Router Solicitation message is received. Upon receiving a Neighbour Solicitation message, the router checks if the 'E' bit of the message is set. If the 'E' bit is set, the router compares the 'Target Address' field in the message against the Address Table. If there is a match, then the address is conflict with another host. The router must send the host a NA message with 'E' bit set to indicate the duplicate address is detected. Before a unique address is re-generated by the host, all messages sent from the host must not be forwarded to other nodes, so the duplicate address does not cause problems for other hosts. If there is no match in the Address Table, the router creates an entry in the Address Table to store the 'Target Address' and the corresponding link-layer address.
If the 'D' bit is set in the received NS message, the access router compares the 'Target Address' field in the message against the Address Table. If there is a match, then delete the entry that contains the address. If there is no match in the Address Table, just ignore the message.
After the entry is created, the updating and ageing of the contents of the entry could refer to the Neighbor Cache maintaining procedure described in RFC2461.
If the 'E' bit and 'D' bit are not set in the received NS message, the NS is treated as a normal address resolving message. The router compares the 'Target Address' field against the address list. If there is a match, then a normal NA message is sent to the soliciting host. In this NA message, the 'Target Address' field is set to the one in the NS message. If there is no match and the source address of the NS message is unspecified, then the NS message is sent out in the normal DAD process. Then an entry is created to contain the 'Target Address' and link-layer address in the NS message. So the router could support both modified hosts and un-modified hosts.
| TOC |
Let's suppose a mobile subscriber station (MS) is moving into a mobile WiMAX network (802.16e) in which Mobile IPv6 (MIPv6) is supported. As mentioned as above, the WiMAX IP network is a point-to-multipoint network. A MS can not communicate with another MS directly. All the traffic should go through an Access Router (ASN-GW) as shown in Figure 4. One thing to be noted is that in 802.16 networks sometimes the DAD process can be omitted, e.g., as described in [RFC5121] [RFC5154]. In these cases, the method described in the document is not necessary. The process when the MS roams into a new access network is described as the follow:
From the above procedure, we could see that the proposed mechanism can significantly decrease the overall handover delay by reducing the time spent in address configuration and DAD. So it could reduce the overall handover delay in Mobile IPv6 networks.
+-----+ +-----+ +----------+ +----+
| MS1 |-------| | | +-----+ | | CN |
+-----+ | |------| | HA | | +----+
+-----+ | AR1 | | +-----+ | |
| MS2 |-------| | | | |
| +-----+ +-----+ | | |
| | +-----+ |--------- Internet
| +-----+ +-----+ | | AAA | |
V | MS2 |-------| |------| +-----+ |
+-----+ | | | |
+-----+ | AR2 | +----------+
| MS3 |-------| |
+-----+ +-----+
| Figure 4: Handover in Mobile 802.16 Networks |
| TOC |
This document includes no request to IANA.
| TOC |
This document does not introduce any new vulnerabilities to IPv6 specifications or operation.
| TOC |
| TOC |
| [RFC2460] | Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” RFC 2460, December 1998 (TXT, HTML, XML). |
| [RFC2461] | Narten, T., Nordmark, E., and W. Simpson, “Neighbor Discovery for IP Version 6 (IPv6),” RFC 2461, December 1998 (TXT, HTML, XML). |
| [RFC2462] | Thomson, S. and T. Narten, “IPv6 Stateless Address Autoconfiguration,” RFC 2462, December 1998 (TXT, HTML, XML). |
| [RFC4429] | Moore, N., “Optimistic Duplicate Address Detection (DAD) for IPv6,” RFC 4429, April 2006 (TXT). |
| [RFC4968] | Madanapalli, S., “Analysis of IPv6 Link Models for 802.16 Based Networks,” RFC 4968, August 2007 (TXT). |
| [RFC5121] | Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. Madanapalli, “Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks,” RFC 5121, February 2008 (TXT). |
| [RFC5154] | Jee, J., Madanapalli, S., and J. Mandin, “IP over IEEE 802.16 Problem Statement and Goals,” RFC 5154, April 2008 (TXT). |
| TOC |
| [ADAD] | Han, Y., Choi, J., Jang, H., and S. Park, “Advance Duplicate Address Detection,” draft-han-mobileip-adad-01.txt (work in progress), 2003. |
| [END] | Xia, F. and B. Sarikaya, “Duplicate Address Detection Optimization Using Enhanced Neighbor Discovery,” draft-xia-16ng-end-01 (work in progress), December 2006 (TXT). |
| TOC |
| Fang Liu | |
| Alcatel-Lucent | |
| Beijing, | |
| China | |
| Phone: | +86 10 58605827 |
| Email: | christine.liu@alcatel-lucent.com |
| Caixia Chi | |
| Alcatel-Lucent | |
| Beijing, | |
| China | |
| Phone: | +86 10 58605828 |
| Email: | caixia.chi@alcatel-lucent.com |