Internet DRAFT - draft-jeong-adhoc-ip-addr-autoconf
draft-jeong-adhoc-ip-addr-autoconf
Autoconf WG J. Jeong
Internet-Draft ETRI/University of Minnesota
Expires: July 21, 2006 J. Park
H. Kim
ETRI
H. Jeong
D. Kim
KNU
January 17, 2006
Ad Hoc IP Address Autoconfiguration
draft-jeong-adhoc-ip-addr-autoconf-06.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/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 July 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document specifies the steps which a mobile node in the ad hoc
network takes in deciding how to autoconfigure its IPv4 or IPv6
address in its network interface. Because the ad hoc IP address
Jeong, et al. Expires July 21, 2006 [Page 1]
Internet-Draft Ad Hoc IP Address Autoconfiguration January 2006
autoconfiguration in this document considers the ad hoc network's
partition and mergence, the address duplication caused by the ad hoc
network's mergence can be resolved through an address resolution
protocol. Also, this document specifies how to resolve the address
duplication in order to guarantee the maintenance of upper-layer
sessions, such as TCP session.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 5
5.1 Message Format for Ad Hoc IPv4 Address
Autoconfiguration . . . . . . . . . . . . . . . . . . . . 5
5.2 Message Format for Ad Hoc IPv6 Address
Autoconfiguration . . . . . . . . . . . . . . . . . . . . 6
5.3 Interface-Key Extension Format . . . . . . . . . . . . . . 7
6. Ad Hoc IP Address Autoconfiguration . . . . . . . . . . . . . 8
6.1 Ad Hoc IPv4 Address Autoconfiguration . . . . . . . . . . 9
6.1.1 Network Prefix for IPv4 Ad Hoc Network . . . . . . . . 9
6.1.2 Procedure of Ad Hoc IPv4 DAD . . . . . . . . . . . . . 9
6.2 Ad Hoc IPv6 Address Autoconfiguration . . . . . . . . . . 11
6.2.1 Network Prefix for IPv6 Ad Hoc Network . . . . . . . . 12
6.2.2 Procedure of Ad Hoc IPv6 DAD . . . . . . . . . . . . . 12
7. Maintenance of Upper-layer Session under Address
Duplication . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1 Detection of Address Duplication during Weak DAD Phase . . 12
7.2 Address Duplication Resolution . . . . . . . . . . . . . . 13
7.3 Data Packet Delivery after Address Duplication
Resolution . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Considerations for Global Addressing . . . . . . . . . . . . . 14
9. Parameter Configurations . . . . . . . . . . . . . . . . . . . 14
10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . 15
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
14.1 Normative References . . . . . . . . . . . . . . . . . . . 15
14.2 Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . 18
Jeong, et al. Expires July 21, 2006 [Page 2]
Internet-Draft Ad Hoc IP Address Autoconfiguration January 2006
1. Introduction
IPv6 stateless address autoconfiguration [4][5] provides a way to
autoconfigure either fixed or mobile nodes with one or more IPv6
addresses and default routes. But this is not suitable for multi-hop
ad hoc networks that have dynamic network topology. Ad hoc networks
can become partitioned and merged frequently as intermediate nodes
move. In this environment, IP address autoconfiguration should be
able to deal with the address duplication not only within a connected
ad hoc partition, but also in the case where two or more partitions
having duplicate addresses respectively become merged. This document
provides the ad hoc IP address autoconfiguration in IPv4 ad hoc
network as well as in IPv6 ad hoc network.
As we know from birthday paradox, there frequently happens an address
conflict when each node chooses its address by random address
selection in ad hoc network, especially in IPv4. In addition, due to
network partitioning and merging, more address conflicts may occur.
Therefore, the handling of the address conflict, detection and
resolution is very important in the ad hoc IP address
autoconfiguraion based on the random address selection. Because the
ad hoc IP address autoconfiguration in this document considers the ad
hoc network's partition and mergence, the address duplication that
can be caused by the ad hoc network's mergence can be resolved
through an address resolution protocol. Also, this document
specifies how to resolve the address duplication in order to
guarantee the maintenance of upper-layer sessions, such as TCP
session, with a minimum of packet loss.
2. Definitions
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 [3].
3. Terminology
This document uses the terminology described in [4][5]. In addition,
seven new terms are defined below:
o Mobile Ad Hoc Network (MANET): The network where mobile nodes can
communicate with one another without preexisting communication
infrastructure, such as base station or access point.
o Duplicate Address Detection (DAD): The process by which a node,
which lacks an IP address, determines an address, determines
whether the candidate address it has selected is available or not.
A node already equipped with an IP address takes part in DAD in
Jeong, et al. Expires July 21, 2006 [Page 3]
Internet-Draft Ad Hoc IP Address Autoconfiguration January 2006
order to protect its IP address from being accidentally used by
another node.
o Strong DAD: The timed-based DAD for the purpose of checking if
there is an address duplication in a connected MANET partition
within a finite bounded time interval [6].
o Weak DAD: The DAD for the purpose of detecting address duplication
during ad hoc routing. A key is used for the purpose of detecting
duplicate IP addresses, which is selected to be unique by mobile
node. When mobile node receives a routing control packet, it
compares the pairs of address and key contained in the packet with
those in the routing table or cache [6].
o Address Request (AREQ): The message used during Strong DAD for the
purpose of checking if there is another node having the requested
address [7].
o Address Reply (AREP): The message used during Strong DAD for the
purpose of indicating the requested address has already been
utilized [7].
o Address Error (AERR): The message used during Weak DAD for the
purpose of indicating that an address duplication happened or that
the address of peer node has been changed.
4. Overview
IPv4 or IPv6 unicast address of ad hoc node can be autoconfigured by
IP address autoconfiguration protocol for ad hoc networks. The
configuration of address is comprised of three steps: (a) selection
of a random address, (b) verification of the address uniqueness and
(c) assignment of the address into network interface.
The duplication address detection (DAD) proposed in this document not
only checks address duplication during the initialization of address
configuration, but also checks and resolves address duplication
detected by intermediate nodes during ad hoc routing. Also, even
during the resolution of address conflict, the sessions using the
conflicted address can still continue until the sessions are closed.
The DAD for ad hoc network in this document is a hybrid scheme
consisting of two phases: (a) Strong DAD and (b) Weak DAD. Within a
connected ad hoc partition, Strong DAD can check quickly if there is
any address duplication or not. During ad hoc routing, Weak DAD can
find out if there is address duplication or not in the case where two
or more MANET partitions having duplicate addresses are merged.
Jeong, et al. Expires July 21, 2006 [Page 4]
Internet-Draft Ad Hoc IP Address Autoconfiguration January 2006
5. Message Formats
5.1 Message Format for Ad Hoc IPv4 Address Autoconfiguration
The mechanism of this document needs new ICMPv4 types for ad hoc IPv4
address autoconfiguration. Figure 1 shows the format of the messages
related to IPv4 address autoconfiguration.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator's IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested or Duplicate IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Message Format for Ad Hoc IPv4 Address Autoconfiguration
Fields:
Type 8-bit identifier of the type of ICMPv4 message.
Message Name Type
AREQ (TBD)
AREP (TBD)
AERR (TBD)
Code 8-bit unsigned integer. As the code for message
type, the valid value is 0, 1, or 2. Code value
1 in AERR message indicates that a node's IP
address has been changed. Code value 2 in AERR
message indicates the acknowledgement for address
change from the peer node. In the other cases,
code value is always set to 0.
Checksum 16-bit unsigned integer. The checksum for the
ICMPv4 message and parts of the IPv4 header.
Identification 32-bit unsigned integer. The identification for
ad hoc address autoconfiguration message is used
to prevent duplicate AREQ message from being
rebroadcast.
Jeong, et al. Expires July 21, 2006 [Page 5]
Internet-Draft Ad Hoc IP Address Autoconfiguration January 2006
Originator's IPv4 Address
The IPv4 address of the sender of ad hoc address
autoconfiguration message.
Requested or Duplicate IPv4 Address
The requested IPv4 address in AREQ and AREP
messages, or the duplicate IPv4 address in AERR
message.
AREQ and AREP messages are used during Strong DAD and AERR message
during Weak DAD. Because AREQ message is forwarded by higher layer
than network layer through local broadcasting, "Identification" field
is necessary in order not to rebroadcast the message sent previously.
5.2 Message Format for Ad Hoc IPv6 Address Autoconfiguration
The mechanism of this document needs new ICMPv6 types for ad hoc IPv6
address autoconfiguration. Figure 2 shows the format of the messages
related to IPv6 address autoconfiguration.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Originator's IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Requested or Duplicate IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Message Format for Ad Hoc IPv6 Address Autoconfiguration
Jeong, et al. Expires July 21, 2006 [Page 6]
Internet-Draft Ad Hoc IP Address Autoconfiguration January 2006
Fields:
Type 8-bit identifier of the type of ICMPv6 message.
Message Name Type
AREQ (TBD)
AREP (TBD)
AERR (TBD)
Code 8-bit unsigned integer. As the code for message
type, the valid value is 0, 1, or 2. Code value
1 in AERR message indicates that a node's IP
address has been changed. Code value 2 in AERR
message indicates the acknowledgement for address
change from the peer node. In the other cases,
code value is always set to 0.
Checksum 16-bit unsigned integer. The checksum for the
ICMPv6 message and parts of the IPv6 header.
Identification 32-bit unsigned integer. The identification for
ad hoc address autoconfiguration message is used
to prevent duplicate AREQ message from being
rebroadcast.
Originator's IPv6 Address
The IPv6 address of the sender of ad hoc address
autoconfiguration message.
Requested or Duplicate IPv6 Address
The requested IPv6 address in AREQ and AREP
messages, or the duplicate IPv6 address in AERR
message.
5.3 Interface-Key Extension Format
A key for Weak DAD is contained in Interface-Key Extension of Figure
3, which is assigned to each network interface.
The Interface-Key extension is appended to control packets of ad hoc
routing protocol for Weak DAD, such as route discovery message or
hello message. Intermediate routing points MUST maintain the "Key"
value for each address in routing table or cache.
Jeong, et al. Expires July 21, 2006 [Page 7]
Internet-Draft Ad Hoc IP Address Autoconfiguration January 2006
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 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface-Key +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Interface-Key Extension Format
Fields:
Type 8-bit identifier of the type of extension (TBD).
Length 8-bit unsigned integer. The length of the
extension (including the type and length
fields) in units of 1 octet.
Interface-Key Interface key field for each network interface
used in Weak-DAD. The size of Interface-Key is
is equal to (Length - 4).
6. Ad Hoc IP Address Autoconfiguration
The procedure of ad hoc IP address autoconfiguration in an ad hoc
node is comprised of two phases: (a) Strong DAD phase and (b) Weak
DAD phase. Especially, for Weak DAD, "Virtual IP Address" is used,
which is the combination of "IP Address" and "Key". During ad hoc
routing, with the value of Key, Weak DAD can detect IP address
duplication. Therefore, Weak DAD places a requirement for a new
field in the routing table -- namely, the inclusion of a "Key" field.
Also, most of routing control packets of ad hoc routing protocols
(e.g., link state packet) contain "Sequence Number" or
"Identification" field in order to allow a receiving node of the
control packets to determine whether it has recently seen copies of
the packets. This field is also used for the purpose of detecting
address duplication by Weak DAD.
Because this document does not consider the global connectivity to
the Internet, it assumes that MANET is temporary network isolated
Jeong, et al. Expires July 21, 2006 [Page 8]
Internet-Draft Ad Hoc IP Address Autoconfiguration January 2006
from the Internet and the scope of addresses used in MANET is not
global, but local.
6.1 Ad Hoc IPv4 Address Autoconfiguration
6.1.1 Network Prefix for IPv4 Ad Hoc Network
Among IPV4_MANET_PREFIX [7], IPv4 addresses in the range 1 ~ 2047
(TMP_ADDR) in the low-order 16 bits are used for temporary IPv4
unicast address during Strong DAD. The rest of addresses in the
range TMP_ADDR + 1 ~ 65534 in the low-order 16 bits are used as
tentative IPv4 address for actual IPv4 unicast address. After
successful Strong DAD, the temporary address is replaced with the
tentative address. In the future, this prefix can be replaced with
another one for ad hoc network.
6.1.2 Procedure of Ad Hoc IPv4 DAD
During Strong DAD phase, an ad hoc node autoconfigures a unique IPv4
address in its network interface within a limited scope of a
connected MANET partition and during Weak DAD phase, the node
participates in Weak DAD which detects and deals with address
duplication while ad hoc nodes exchange each other routing
information, such as link state packet or route discovery packet, or
broadcast their hello messages periodically.
The DAD procedure is as follows:
First of all, a node sets a variable for counting the number of
Strong DAD's failures, dad_count, to zero.
Step (a): The node selects a temporary address and configures it
in network interface.
Step (b): The node selects a tentative address and makes an AREQ
message for the address. It initializes a variable for
retransmission of AREQ message, retrans_count, with zero. TTL of
IP datagram for Strong DAD is set to TTL_STRONG_DAD. In proactive
routing protocol, TTL of IP datagram MAY be set to one, one-hop
distance.
Step (c): The node broadcasts the AREQ message in IPV4_MANET_
BROADCAST_ADDRESS and increases retrans_count by one. It waits
for AREP message until the timer for Strong DAD expires. If an
AREP message for the sent AREQ message arrives before the timer
expires, the node executes Step (e). Otherwise, it executes Step
(d). Notice that nodes under tentative state of Strong DAD for
its address configuration SHOULD NOT participate in Strong DAD or
Jeong, et al. Expires July 21, 2006 [Page 9]
Internet-Draft Ad Hoc IP Address Autoconfiguration January 2006
routing.
Step (d): If retrans_count is equal to DAD_RETRIES, indicating
successful Strong DAD, the node goes to Step (f). Otherwise, it
goes to Step (c).
Step (e): If the AREP message received is associated with the AREQ
message sent before and dad_count is unequal to DAD_FAILURE, the
node increments dad_count by one and returns to Step (a) in order
to restart Strong DAD for another address. Otherwise, the node
reports error message and gives up its address autoconfiguration.
Step (f): Because the requested address that is tentative is
unique in the connected partition, the node replaces the temporary
address with the tentatively selected address as a permanent IPv4
unicast address of its network interface.
Step (g): The node waits for receiving address autoconfiguration
messages or ad hoc routing control packets such as link state
packet, route discovery packet and hello message. If the packet
is address autoconfiguration message, it executes Step (h). If
the received packet is ad hoc routing control packet, it executes
Step (l).
Step (h): First of all, it is checked during the processing of IP
header of the message whether the message received is what was
received previously on the basis of "Source IP Address" field of
IP datagram containing the message and "Identification" field
within the message or not. If the packet is what was received
previously, the node discards the message, returning to Step (g).
Otherwise, the node executes Step (i).
Step (i): If the message is AREP, it executes Step (j). If the
message is AERR, it executes Step (k). If the message is AREQ,
the node compares the requested address in the AREQ message with
its own address and active addresses in its routing table or
cache. If an address duplication happens, it sends in unicast the
originator node of the AREQ message an AREP message, indicating
address duplication, returning to Step (g). Otherwise, it
decrements the value of TTL of IP datagram, containing the AREQ
message, by one and then rebroadcasts the message to neighbors,
returning to Step (g).
Step (j): If Destination IP address of the AREP message is the
same as its own IP address and the duplicate address in the AREP
message is corresponding to its own IP address under tentative
state during Strong DAD, the node starts Strong DAD procedure
again, that is returning to Step (a). For some reasons, if
Jeong, et al. Expires July 21, 2006 [Page 10]
Internet-Draft Ad Hoc IP Address Autoconfiguration January 2006
Destination IP address of IP header of the AREP message is the
same as its own but the duplicate address in the AREP message is
not corresponding to its own under tentative state during Strong
DAD, it discards the message as error handling, returning to Step
(g). Otherwise, it only relays the message in unicast to next-hop
node towards Destination IP address of the AREP message, returning
to Step (g).
Step (k): If Destination IP address of the AERR message is the
same as its own IP address and the duplicate address in the AERR
message is the same as its own IP address, the node starts Strong
DAD procedure in order to autoconfigure a new address again, that
is returning to Step (a). In addition, in order to maintain the
current upper-layer sessions related to the duplicate address, it
MAY inform its peer nodes of address change. Refer to Section 7.
For some reasons, if Destination IP address of IP header of the
AERR message is the same as its own but the duplicate address in
the AERR message is not the same as its own, it discards the
message as error handling returning to Step (g). Otherwise, it
only relays the message in unicast to next-hop node towards
Destination IP address of the AERR message, returning to Step (g).
Step (l): The node investigates each IP address contained in
control packet with Interface-Key extension to see whether for IP
address, there is a matching entry in routing table or cache. If
there is a matching entry and the values of Key associated with
each address are different, which means that an IP address
conflict has happened, the node sends in unicast an AERR message,
indicating address conflict, to another node using the duplicate
address associated with less key value, returning to Step (g).
Otherwise, it executes the rest of the procedure related to
processing ad hoc routing control packets, returning to Step (g).
Even in the accidental cases where the two contenders for an IP
address happen to select the same value for "Key", address
duplication MAY be detected with "Sequence Number" or
"Identification" field of the control packet. Assume that a node
receives a routing control packet (e.g., link state packet). If the
values of "IP Address" and "Key" fields within the packet are the
same as its own and the value of "Sequence Number" field within the
packet is higher than the counter value for its own "Sequence Number"
except sequence number wrap-around, the node MAY decide that address
duplication with the same key has happened and resolve the
duplication [8].
6.2 Ad Hoc IPv6 Address Autoconfiguration
Jeong, et al. Expires July 21, 2006 [Page 11]
Internet-Draft Ad Hoc IP Address Autoconfiguration January 2006
6.2.1 Network Prefix for IPv6 Ad Hoc Network
Among the IPV6_MANET_PREFIX [7], "fec0:0:0:ffff::/96" is used as
IPV6_MANET_INIT_PREFIX for temporary unicast address during Strong
DAD. The low-order 32 bits of the temporary address are configured
with 32-bit pseudo random number. The rest of address range of
IPV6_MANET_PREFIX except IPV6_MANET_INIT_PREFIX is used for actual
unicast address. The address is tentative address until the
uniqueness of it is verified by Strong DAD. AREQ message for Strong
DAD is broadcast in site-local scoped all node multicast address,
IPV6_MANET_BROADCAST_ADDRESS.
Recently, IPv6 site-local address has been deprecated by IPv6 working
group. The IPv6 working group has developed the standard for Unique
Local IPv6 Unicast Addresses for local networks separated from the
Internet, such as ad hoc networks [9]. If the ad hoc prefix is
determined by the IPv6 working group, IPV6_MANET_PREFIX will have
another for ad hoc networks. IPV6_MANET_BROADCAST_ADDRESS will also
be replaced with another for ad hoc networks.
6.2.2 Procedure of Ad Hoc IPv6 DAD
An IPv6 ad hoc node autoconfigures a unique IPv6 address in its
network interface in the same way as an IPv4 ad hoc node like in
section 6.1.2.
7. Maintenance of Upper-layer Session under Address Duplication
When address duplication happens and the duplicate address is
replaced with another, the sessions above network layer, such as TCP
session, can be broken. So, for the survivability of upper-layer
sessions using the duplicate address, the notification of address
change between the peer nodes is necessary. This resolution of
duplicate address is more important than the detection of duplicate
address from the viewpoint of network service; e.g., the maintenance
of upper-layer sessions with a minimum of packet loss and delay.
7.1 Detection of Address Duplication during Weak DAD Phase
In order to allow data packets related to the sessions using the
duplicate address to be forwarded to destination nodes for a while,
after sending an error message (AERR) to the node related to the
duplicate address, the intermediate nodes that have perceived address
duplication SHOULD continue to forward on-the-fly data packets
associated with the sessions using the duplicate address until the
route entry for the duplicate address expires, only if there is one
route entry towards the duplicate address. When there are more route
entries than one associated with duplicate address of which keys are
Jeong, et al. Expires July 21, 2006 [Page 12]
Internet-Draft Ad Hoc IP Address Autoconfiguration January 2006
different each other, the intermediate nodes drop all the on-the-fly
data packets so that the data packets may not reach a wrong
destination and not perturb it.
+------+ +------+ +------+ +------+ +------+
|Node A|----|Node B|----|Node C|----|Node D|----|Node E|
+------+ +------+ +------+ +------+ +------+
===> (X->Y)
on-the-fly data packet
of node A
Figure 4: Delivery of On-the-fly Data Packet under Address Conflict
Through this forwarding, the on-the-fly data packets of the node with
duplicate address can be delivered to the destination without packet
loss. For example, like in Figure 4, let's assume that five nodes
are connected to compose a MANET and node A is sending data packets
to node E via node B, C and D. Even when the destination node E
changes its address from X to Y due to address conflict, the on-the-
fly data packets of the source node A can be delivered to node E
without packet loss because the intermediate nodes can forward them
because a route for node E's duplicate address in each intermediate
node is still valid.
7.2 Address Duplication Resolution
The node that receives an AERR message SHOULD autoconfigure a new
IPv6 address through Strong DAD. Also, it SHOULD simultaneously
allows the new address be used by the old upper-layer sessions using
the duplicate address as well as by new upper-layer sessions from
this time forward. The node SHOULD inform each peer node of its new
address by sending an AERR message with code 1, which indicates its
address change. The "Originator's IPv4 Address" field of AERR
message contains the duplicate address and the "Requested IPv4
Address" field contains a new address to be used for the further
communication.
7.3 Data Packet Delivery after Address Duplication Resolution
When the originator becomes to know that the AERR sent with code 1
has arrived at its peer node well after receiving an AERR with code 2
from the peer, it starts to send data packets to its peer node again
with the new address through IP tunneling. The destination address
in outer IP header is the new IP address of the node that announced
duplicate address and that in inner IP header is the duplicate IP
address of the node, i.e., the old address of the node. When the
peer node receives tunneled packet from the sender, it decapsulates
the packet and delivers the payload in the packet to upper-layer
Jeong, et al. Expires July 21, 2006 [Page 13]
Internet-Draft Ad Hoc IP Address Autoconfiguration January 2006
session associated with the duplicate address. Both the node and its
peer node maintain the information of pairs of duplicate address and
new address in Address Mapping Cache like a binding cache of Mobile
IP [10][11] and use it for processing IP tunneling.
8. Considerations for Global Addressing
MANET nodes desiring to communicate with the global Internet should
have a set of global IPv4/IPv6 address(es) to allow the packets to be
originated from an Internet node. In addition, in order to access
the Internet, MANETs need to one or more gateways, which enable each
node's interface to have auto-configured global address(es). For the
purpose of announcing the gateway prefix information, route
advertisement and route solicitation messages should be processed in
multi-hop fashion at each gateway and node. Along with the prefix
information, the stateless mechanisms for IP address auto-
configuration and duplicate address detection for valid global IP
addresses should be executed. In the case of multiple gateways, each
node's interface can be assigned multiple global IP addresses due to
the presence of multiple gateways. However, since most ad hoc
routing protocols did not consider multiple addresses of one network
interface, they should be modified to support not only MANET local
address but also multiple global addresses.
9. Parameter Configurations
This section gives default values for some important parameters
associated with Ad Hoc IP Address Autoconfiguration.
Parameter Name Value
----------------------------- -----------------------
IPV4_MANET_PREFIX 169.254/16
IPV6_MANET_PREFIX fec0:0:0:ffff::/64
IPV6_MANET_INIT_PREFIX fec0:0:0:ffff::/96
IPV4_MANET_BROADCAST_ADDRESS 255.255.255.255
IPV6_MANET_BROADCAST_ADDRESS FF05::1
TTL_STRONG_DAD 3
DAD_RETRIES 3
DAD_FAILURE 3
10. Open Issues
There might be some issues regarding Ad Hoc IP Address Auto-
configuration as follows:
Jeong, et al. Expires July 21, 2006 [Page 14]
Internet-Draft Ad Hoc IP Address Autoconfiguration January 2006
o How to select victim node(s) under address conflict, considering
the number of on-going sessions and fairness? The selection of
victim node can affect network performance.
o How to implement data structure of the address mapping cache and
how to maintain it?
11. Security Considerations
In order to provide secure ad hoc IP address autoconfiguration in ad
hoc network, IPsec ESP MAY be used with a null-transform to
authenticate ad hoc IP autoconfiguration messages or control packets,
which can be easily accomplished through the configuration of a group
pre-shared secret key for the trusted nodes.
12. IANA Considerations
The IANA should assign new ICMPv4/ICMPv6 types for AREQ, AREP, and
AERR defined in this document.
13. Acknowledgements
The authors would like to acknowledge the previous contributions of
the following people; Charles E. Perkins, Jari T. Malinen, Ryuji
Wakikawa, Elizabeth M. Belding-Royer and Yuan Sun. In addition, the
important definitions (e.g., Strong DAD and Weak DAD) and mechanisms
for finding and resolving duplicate address have been derived from
Nitin H. Vaidya's work. Especially, we thank for his contribution.
For the suggestion of Passive DAD, in aid of Weak DAD, we thank
Kilian Weniger.
14. References
14.1 Normative References
[1] Bradner, S., "IETF Rights in Contributions", RFC 3978,
March 2005.
[2] Bradner, S., "Intellectual Property Rights in IETF Technology",
RFC 3668, February 2004.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[5] Thomson, S. and T. Narten, "IPv6 Stateless Address
Jeong, et al. Expires July 21, 2006 [Page 15]
Internet-Draft Ad Hoc IP Address Autoconfiguration January 2006
Autoconfiguration", RFC 2462, December 1998.
[6] Vaidya, N., "Weak Duplicate Address Detection in Mobile Ad Hoc
Networks", MobiHoc 2002, June 2002.
[7] Perkins, C., Ed., "IP Address Autoconfiguration for Ad Hoc
Networks", draft-ietf-manet-autoconf-01.txt (Work in Progress),
November 2001.
14.2 Informative References
[8] Weniger, K., "Passive Duplicate Address Detection in Mobile Ad
Hoc Networks", IEEE WCNC 2003, March 2003.
[9] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[10] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[11] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
Authors' Addresses
Jaehoon Paul Jeong
ETRI/Department of Computer Science and Engineering
University of Minnesota
117 Pleasant Street SE
Minneapolis, MN 55455
US
Phone: +1 651 587 7774
Fax: +1 612 625 2002
Email: jjeong@cs.umn.edu
URI: http://www.cs.umn.edu/~jjeong/
Jungsoo Park
ETRI / PEC
161 Gajeong-dong, Yuseong-gu
Daejeon 305-350
Korea
Phone: +82 42 860 6514
Fax: +82 42 861 5404
Email: pjs@etri.re.kr
Jeong, et al. Expires July 21, 2006 [Page 16]
Internet-Draft Ad Hoc IP Address Autoconfiguration January 2006
Hyoungjun Kim
ETRI / PEC
161 Gajeong-dong, Yuseong-gu
Daejeon 305-350
Korea
Phone: +82 42 860 6576
Fax: +82 42 861 5404
Email: khj@etri.re.kr
Hongjong Jeong
Kyungpook National University
1370 Sankyuk-dong, Puk-gu
Daegu 702-701
Korea
Phone: +82 53 940 8590
Fax: +82 53 957 4846
Email: hjjeong@monet.knu.ac.kr
Dongkyun Kim
Kyungpook National University
1370 Sankyuk-dong, Puk-gu
Daegu 702-701
Korea
Phone: +82 53 950 7571
Fax: +82 53 957 4846
Email: dongkyun@knu.ac.kr
Jeong, et al. Expires July 21, 2006 [Page 17]
Internet-Draft Ad Hoc IP Address Autoconfiguration January 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jeong, et al. Expires July 21, 2006 [Page 18]
