Internet-Draft J. Jeong
J. Park
H. Kim
ETRI
D. Kim
KNU
Expires: January 2005 19 July 2004
Ad Hoc IP Address Autoconfiguration for AODV
draft-jeong-manet-aodv-addr-autoconf-01.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which we become aware will be disclosed, in accordance
with RFC3668.
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 18, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document specifies the steps a node running AODV in ad hoc
network takes in deciding how to autoconfigure its IPv4 or IPv6
Jeong, et al. Expires - January 2005 [Page 1]
Internet-Draft Ad Hoc IP Address Autoconf for AODV July 2004
address in network interface. Because the ad hoc IP address
autoconfiguration in this document considers ad hoc network's
partition and mergence, the address duplication caused by ad hoc
network's mergence can be resolved through 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.
Conventions used in this document
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 RFC 2119 [3].
Table of Contents
1. Introduction...................................................3
2. Terminology....................................................3
3. Overview.......................................................4
4. Message Formats................................................5
4.1 Message Format for Ad Hoc IP Address Autoconfiguration.....5
4.1.1 Message Format for IPv4 Address Autoconfiguration....5
4.1.2 Message Format for IPv6 Address Autoconfiguration....6
4.2 Message Formats for AODV...................................6
4.2.1 Route Request (RREQ) Message Format..................6
4.2.2 Route Reply (RREP) Message Format....................7
4.2.3 Route Error (RERR) Message Format....................7
4.2.4 Route Reply Acknowledgment (RREP-ACK) Message Format.8
4.2.5 Interface-Key Extension Format.......................8
5. AODV Extension.................................................9
6. Ad Hoc IP Address Autoconfiguration............................9
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........................10
6.2 Ad Hoc IPv6 Address Autoconfiguration.....................13
6.2.1 Network Prefix for IPv6 Ad Hoc Network..............13
6.2.2 Procedure of Ad Hoc IPv6 DAD........................13
7. Maintenance of Upper-layer Session under Address Duplication..13
7.1 Detection of Address Duplication during Weak DAD Phase....13
7.2 Address Duplication Resolution............................14
7.3 Data Packet Delivery after resolving Address Duplication..15
8. Open Issues...................................................16
9. Security Considerations.......................................16
10. Acknowledgements.............................................16
11. Normative References.........................................16
12. Informative References.......................................17
13. Authors' Addresses...........................................17
Intellectual Property Statement..................................18
Jeong, et al. Expires - January 2005 [Page 2]
Internet-Draft Ad Hoc IP Address Autoconf for AODV July 2004
Full Copyright Statement.........................................19
Acknowledgement..................................................19
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 has dynamic network topology. Ad hoc networks
become partitioned and merged as intermediate nodes move. In this
environment, IP address autoconfiguration should be able to process
the address duplication not only within a connected ad hoc partition,
but also in the case where two partitions having duplicate addresses
respectively become merged. This document provides ad hoc IP address
autoconfiguration in ad hoc network on the basis of AODV [6].
As we know from birthday paradox, there frequently happens an address
conflict when each node choose 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 address conflict, detection and resolution
is important in Ad Hoc IP address autoconfiguraion based on random
address selection. Because the ad hoc IP address autoconfiguration
in this document considers ad hoc network's partition and mergence,
the address duplication that can be caused by ad hoc network's
mergence can be resolved through 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. Terminology
This document uses the terminology described in [4][5]. In addition,
nine new terms are defined below:
Duplicate Address Detection (DAD)
The process by which a node, which lacks an IP address,
determines address, determines whether a candidate address it
has selected is available or not. A node already equipped with
an IP address takes part in DAD in order to protect its IP
address from being accidentally used by another node.
Strong DAD
The timed-based DAD for the purpose of checking if there is
address duplication in a connected MANET partition within a
finite bounded time interval [7].
Jeong, et al. Expires - January 2005 [Page 3]
Internet-Draft Ad Hoc IP Address Autoconf for AODV July 2004
Weak DAD
The DAD for the purpose of detecting address duplication during
ad hoc routing. 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 [7].
Address Request (AREQ)
The message used during Strong DAD for the purpose of checking
if there is another node having the requested address.
Address Reply (AREP)
The message used during Strong DAD for the purpose of indicating
the requested address has already been utilized.
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.
Route Request and Address Request (RREQ-AREQ)
AODV Route Request (RREQ) message containing Address Request
(AREQ) message.
Route Reply and Address Reply (RREP-AREP)
AODV Route Reply (RREP) message containing Address Reply (AREP)
message.
Route Reply and Address Error (RREP-AERR)
AODV Route Reply (RREP) message containing Address Error (AERR)
message.
3. Overview
IPv4 or IPv6 unicast address of ad hoc node running AODV can be
autoconfigured by IP address autoconfiguration for ad hoc networks.
The configuration of address is comprised of three steps: (a)
selection of random address, (b) verification of the address
uniqueness, and (c) assignment of the address into network interface.
Jeong, et al. Expires - January 2005 [Page 4]
Internet-Draft Ad Hoc IP Address Autoconf for AODV July 2004
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 address duplication has occurred or not, when two
or more MANET partitions having duplicate addresses are merged.
4. Message Formats
4.1 Message Format for Ad Hoc IP Address Autoconfiguration
4.1.1 Message Format for 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)
Jeong, et al. Expires - January 2005 [Page 5]
Internet-Draft Ad Hoc IP Address Autoconf for AODV July 2004
Code 8-bit unsigned integer. As the code for message
type, the valid value is either 0 or 1. Code
value 1 in AERR message indicates that the peer
node's address has been changed. In the other
cases, code value is always 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.
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.
4.1.2 Message Format for IPv6 Address Autoconfiguration
For Ad Hoc IPv6 address autoconfiguration, 128-bit IPv6 address is
substituted for 32-bit IPv4 address [7].
4.2 Message Formats for AODV
For the support of Strong-DAD and Weak-DAD in AODV, two new flags,
S (Strong-DAD) flag and W (Weak-DAD) flag, are defined. Also, for
the delivery of key for each network-interface in Weak-DAD,
Interface-Key Extension is defined.
4.2.1 Route Request (RREQ) Message Format
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 |J|R|G|D|U|S|W| Reserved | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RREQ ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jeong, et al. Expires - January 2005 [Page 6]
Internet-Draft Ad Hoc IP Address Autoconf for AODV July 2004
| Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Route Request (RREQ) Message Format
Fields:
S Strong-DAD flag; used for Strong DAD.
W Weak-DAD flag; used for Weak DAD.
4.2.2 Route Reply (RREP) Message Format
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 |R|A|S|W| Reserved |Prefix Sz| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. Route Reply (RREP) Message Format
Fields:
S Strong-DAD flag; used for Strong DAD.
W Weak-DAD flag; used for Weak DAD.
4.2.3 Route Error (RERR) Message Format
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 |N|W| Reserved | DestCount |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jeong, et al. Expires - January 2005 [Page 7]
Internet-Draft Ad Hoc IP Address Autoconf for AODV July 2004
| Unreachable Destination IP Address (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreachable Destination Sequence Number (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Additional Unreachable Destination IP Addresses (if needed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Additional Unreachable Destination Sequence Numbers (if needed)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. Route Error (RERR) Message Format
Fields:
W Weak-DAD flag; used for Weak DAD.
4.2.4 Route Reply Acknowledgment (RREP-ACK) Message Format
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |W| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. Route Reply Acknowledgment (RREP-ACK) Message Format
Fields:
W Weak-DAD flag; used for Weak DAD.
4.2.5 Interface-Key Extension Format
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 6. Interface-Key Extension Format
Fields:
Jeong, et al. Expires - January 2005 [Page 8]
Internet-Draft Ad Hoc IP Address Autoconf for AODV July 2004
Type (TBD)
Length 18
Interface-Key
128-bit Interface Key for each network interface, used in
Weak-DAD.
An Interface-Key can be selected as a 128-bit number which is
generated by concatenating four integers generated by a uniform
distribution function, which is initialized with a random seed.
The Interface-Key extension MAY be appended to RREQ or RREP message
to be used by a receiver in determining whether or not there is IP
address duplication.
5. AODV Extension
Each entry in AODV routing table MUST have to maintain a "Key" field
for each address for supporting Weak DAD during route discovery.
6. Ad Hoc IP Address Autoconfiguration
The procedure of ad hoc IP address autoconfiguration in an ad hoc
node running AODV 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, the field of "Originator Sequence Number" included in
AODV control message is also used for the purpose of detecting
address duplication by Weak DAD [7].
Because this document does not consider the global connectivity to
the Internet, it assumes that MANET is temporary network isolated
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
For IPv4 address, "169.254/16" is used as IPv4 MANET exclusive prefix
, IPV4_MANET_PREFIX [9]. Among IPV4_MANET_PREFIX, 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
Jeong, et al. Expires - January 2005 [Page 9]
Internet-Draft Ad Hoc IP Address Autoconf for AODV July 2004
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 running AODV autoconfigures a
unique IPv4 address, using the mechanism of AODV's route discovery,
in its network interface within a limited scope of a connected MANET
partition and during Weak DAD phase, the node participates in both
AODV routing and Weak DAD as follows:
Step (a) : A 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, into 0. The node
makes an RREQ-AREQ message with the following field configuration;
assume that the temporary address of the originator of RREQ-AREQ
message is Tm, the tentative address of the originator is Tn, Tm's
sequence number is Sn, Tm's key is Key, RREQ_ID is rreq_id and
Identification of AREQ message is set to rreq_id.
- RREQ message
S flag(=1), Hop Count(=0), RREQ ID(=rreq_id),
Destination IP Address(=Tn), Destination Sequence Number(=0),
Originator IP Address(=Tm), Originator Sequence Number(=Sn)
- AREQ message
Identification(=rreq_id),
Originator's IPv4 Address(=Tm),
Requested IPv4 Address(=Tn)
- Interface-Key extension
Interface-Key(=Key)
Step (c) : The node broadcasts the RREQ-AREQ message in IPv4 MANET
broadcast address, 255.255.255.255, and increases the count for
transmission of AREQ message, retrans_count by 1. It waits for RREP-
AREP message until the timer for Strong DAD expires. If an RREP-AREP
message for the sent RREQ-AREQ message arrives before the timer expi-
res, the node executes Step (e). Otherwise, it executes Step (d).
Step (d) : If retrans_count is equal to DAD_RETRIES (e.g., 3), the
node goes to Step (f). Otherwise, it goes to Step (c).
Jeong, et al. Expires - January 2005 [Page 10]
Internet-Draft Ad Hoc IP Address Autoconf for AODV July 2004
Step (e) : If the received RREP-AREP message is associated with the
sent RREQ-AREQ message, the node returns to Step (a) in order to
restart Strong DAD for another address.
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 is ready to receive AODV control packet that may
include address autoconfiguration message. If the packet received
contains address autoconfiguration message, it executes Step (h). If
the packet received is RREQ message with W flag set on, it executes
Step (l). If the packet is RREP message with W flag set on, it
executes Step (m). Otherwise, it processes the control packet
according to AODV routing protocol [6].
Step (h) : First of all, it is checked during the processing of IP
header of the message whether the received message 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 RREP-AREP, it executes Step (j). If the
message is RREP-AERR, it executes Step (k). If the message is RREQ-
AREQ, the node compares its own address with the requested address in
the AREQ message. If two addresses are the same, it sends in unicast
the originator node an RREP-AREP message, indicating address
duplication, returning to Step (g). Otherwise, it rebroadcasts the
message to neighbors, returning to Step (g).
Step (j) : If Destination IP address of IP header of the RREP-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, which indicates address conflict,
the node starts Strong DAD procedure again, namely returning to Step
(a). For some reasons, if Destination IP address of IP header of the
RREP-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 towards Destination IP address of the RREP-AREP message,
returning to Step (g). Notice that nodes under tentative state of
Strong DAD for its address configuration SHOULD NOT participate in
Jeong, et al. Expires - January 2005 [Page 11]
Internet-Draft Ad Hoc IP Address Autoconf for AODV July 2004
Strong DAD, namely not relaying or forwarding other nodes' RREQ-AREP
messages.
Step (k) : If Destination IP address of the RREP-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, which indicates address
duplication during Weak DAD phase, the node starts Strong DAD
procedure in order to autoconfigure a new address again, namely
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. If
Destination IP address 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,
node discards the message, returning to Step (g). Otherwise, it only
relays the message in unicast towards Destination IP address of the
AERR message, returning to Step (g). Notice that nodes under
tentative state of Strong DAD for its address configuration SHOULD
NOT relay or forward other nodes' AERR messages.
Step (l) : The node investigates "Originator's IPv4 Address" of
contained in RREQ message 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 RREP-AERR message,
indicating address conflict, to the originator of the RREQ message,
using the duplicate address, returning to Step (g). Otherwise, it
executes the rest of the procedure related to processing ad hoc
routing control packets, returning to Step (g). Notice that there is
not any protection against accidental cases where the two contenders
for an IP address happen to select the same value for "Key", though
it is a very rare case. Also, 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 "Originator Sequence
Number" field of RREQ message, which it assumes that each node's
sequence starts from a different number [7][10].
Step (m) : If Destination IP address of the RREP message is the
node's own IP address and the message is related to its current route
discovery, the node handles the message. If Destination IP address
of the RREP message is not the node's own IP address, the node
forwards the message toward the destination.
When an intermediate or destination node sends an RREP message to an
originator of the RREQ message, it informs the originator of a key
associated with "Destination IP address" of the RREP message through
Interface-Key extension. When an intermediate node sends a
gratuituous RREP to another node, it does the same thing.
Jeong, et al. Expires - January 2005 [Page 12]
Internet-Draft Ad Hoc IP Address Autoconf for AODV July 2004
6.2 Ad Hoc IPv6 Address Autoconfiguration
6.2.1 Network Prefix for IPv6 Ad Hoc Network
For IPv6 address, "fec0:0:0:ffff::/64" is used as IPv6 MANET exclu-
sive prefix, IPV6_MANET_PREFIX [9]. Among the IPV6_MANET_PREFIX,
"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.
Recently, IPv6 site-local address has been deprecated by IPv6 working
group. Since IETF-56 meeting, IPv6 working group has been discussing
local prefix for local networks separated from the Internet, such as
ad hoc network [11]. If ad hoc prefix is determined by IPv6 working
group, IPV6_MANET_PREFIX will have the new one for ad hoc network.
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 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, RREP-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
Jeong, et al. Expires - January 2005 [Page 13]
Internet-Draft Ad Hoc IP Address Autoconf for AODV July 2004
entries than one associated with duplicate address of which keys are
different each other, the intermediate nodes drop the on-the-fly data
packets so that the data packets may not reach wrong destination.
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 7, 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, 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.
+------+ +------+ +------+ +------+ +------+
|Node A|----|Node B|----|Node C|----|Node D|----|Node E|
+------+ +------+ +------+ +------+ +------+
===> (X->Y)
on-the-fly data packet
of node A
Figure 7. Delivery of On-the-fly Data Packet under Address
Conflict
Assume that the originator of RREP-AERR message is Node1, the
receiver of the message is Node2, Node1's sequence number is SN1 and
Node1's key is Key1.
- RREP message
W flag(=1), Prefix Size(=0), Hop Count(=0),
Destination IP Address(=Node1), Destination Sequence Number(=SN1)
, Originator IP Address(=Node2),
Lifetime(=lifetime)
- AERR message
Code(=0),
Identification(=rreq_id),
Originator's IPv4 Address(=Node2),
Duplicate IPv4 Address(=Node2)
- Interface-Key extension
Interface-Key(=Key1)
7.2 Address Duplication Resolution
The node that receives an RREP-AERR message SHOULD autoconfigure a
new IPv6 address through Strong DAD. Also, it SHOULD simultaneously
Jeong, et al. Expires - January 2005 [Page 14]
Internet-Draft Ad Hoc IP Address Autoconf for AODV July 2004
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 the
change of address by sending an RREP-AERR message with code 1 as
follow; assume that the originator of RREP-AERR message is Node1, the
receiver of the message is Node2 (i.e., peer node), Node1's sequence
number is SN1, Node1's old address is A_old, Node1's new address is
A_new, Node2's address Node2 and Node1's key is Key1.
- RREP message
W flag(=1), Prefix Size(=0), Hop Count(=0),
Destination IP Address(=A_new), Destination Sequence Number(=SN1)
, Originator IP Address(=Node2),
Lifetime(=lifetime)
- AERR message
Code(=1),
Identification(=rreq_id),
Originator's IPv4 Address(=A_old),
Requested IPv4 Address(=A_new)
- Interface-Key extension
Interface-Key(=Key1)
The "Originator's IPv4 Address" field contains the duplicate address
and the "Requested IPv4 Address" field contains a new address to be
used for the further communication.
After receiving the RREP-AERR message with code field of AERR message
set to one, the peer node send the originator of the RREP-AERR
message an RREP-ACK message with W flag set on, indicating that the
peer node has received the RREP-AERR message and is ready to data
packets through the new address of the originator.
7.3 Data Packet Delivery after resolving Address Duplication
When the originator receives the RREP-ACK from its peer node, 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. When the peer node receives tunneled packet from the
sender, it decapsulates the packet and delivers the payload in the
packet to upper-layer 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 in a
binding cache of Mobile IP [12][13] and use it for processing IP
tunneling.
Jeong, et al. Expires - January 2005 [Page 15]
Internet-Draft Ad Hoc IP Address Autoconf for AODV July 2004
8. Open Issues
There might be some issues regarding Ad Hoc IP Address
Autoconfiguration for AODV as follows:
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?
9. 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.
10. 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.
11. Normative References
[1] S. Bradner, "Intellectual Property Rights in IETF Technology",
RFC 3668, February 2004.
[2] S. Bradner, "IETF Rights in Contributions", RFC 3667,
February 2004.
[3] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] T. Narten, E. Nordmark and W. Simpson, "Neighbor Discovery for
IP version 6", RFC 2461, December 1998.
[5] S. Thomson and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
Jeong, et al. Expires - January 2005 [Page 16]
Internet-Draft Ad Hoc IP Address Autoconf for AODV July 2004
[6] C. Perkins, E. Belding-Royer and S. Das, "Ad hoc On-Demand
Distance Vector (AODV) Routing", RFC 3561, July 2003.
12. Informative References
[7] J. Jeong et al., "Ad Hoc IP Address Autoconfiguration",
draft-jeong-adhoc-ip-addr-autoconf-03.txt, July 2004.
[8] N. Vaidya, "Weak Duplicate Address Detection in Mobile Ad Hoc
Networks", MobiHoc 2002, June 2002.
[9] C. Perkins et al., "IP Address Autoconfiguration for Ad Hoc
Networks", draft-ietf-manet-autoconf-01.txt, November 2001.
[10] K. Weniger, "Passive Duplicate Address Detection in Mobile Ad
Hoc Networks", IEEE WCNC 2003, March 2003.
[11] R. Hinden and B. Haberman, "Unique Local IPv6 Unicast
Addresses", draft-ietf-ipv6-unique-local-addr-05.txt, June 2004.
[12] C. Perkins, "IP Mobility Support", RFC 2002, October 1996.
[13] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6",
RFC 3775, June 2004.
13. Authors' Addresses
Jaehoon Paul Jeong
ETRI / PEC
161 Gajong-Dong, Yusong-Gu
Daejeon 305-350
Korea
Phone: +82 42 860 1664
Fax: +82 42 861 5404
EMail: paul@etri.re.kr
Jungsoo Park
ETRI / PEC
161 Gajong-Dong, Yusong-Gu
Daejeon 305-350
Korea
Phone: +82 42 860 6514
Fax: +82 42 861 5404
EMail: pjs@etri.re.kr
Jeong, et al. Expires - January 2005 [Page 17]
Internet-Draft Ad Hoc IP Address Autoconf for AODV July 2004
Hyoungjun Kim
ETRI / PEC
161 Gajong-Dong, Yusong-Gu
Daejeon 305-350
Korea
Phone: +82 42 860 6576
Fax: +82 42 861 5404
EMail: khj@etri.re.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
Intellectual Property Statement
The following intellectual property notice is copied from RFC3668,
Section 5.
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.
Jeong, et al. Expires - January 2005 [Page 18]
Internet-Draft Ad Hoc IP Address Autoconf for AODV July 2004
Full Copyright Statement
The following copyright notice is copied from RFC3667, Section 5.4.
It describes the applicable copyright for this document.
Copyright (C) The Internet Society (2004). 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 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jeong, et al. Expires - January 2005 [Page 19]