| TOC |
|
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 January 12, 2006.
Copyright © The Internet Society (2005).
This Internet Draft aims at describing some of the already proposed mechanisms for the autoconfiguration of IP addresses in MANET networks, trying to provide a useful reference in the standardisation process. Solutions proposed in research papers and submitted as I-Ds are presented and classified by a simple criteria. The analysis of the solutions includes a brief description of the mechanism and also a summary of the key characteristics.
1.
Introduction and problem statement
2.
IP address auto-configuration protocols
2.1
Conflict-detection allocation mechanisms
2.1.1
IP address Autoconfiguration for Ad Hoc
Networks (Perkins et al.)
2.1.2
IPv6 Autoconfiguration in Large Scale Mobile
Ad-Hoc Networks (Weniger et al.)
2.1.3
Weak Duplicate Address Detection in Mobile
Ad Hoc Networks (Vaidya)
2.1.4
Global connectivity for IPv6 Mobile Ad Hoc
Networks (Wakikawa et al.)
2.1.5
Ad Hoc IP Address Autoconfiguration (Jeong
et al.)
2.1.6
Automatic configuration of IPv6 addresses for
nodes in a MANET with multiple gateways (Ruffino et al.)
2.1.7
Address autoconfiguration in Optimized Link
State Routing Protocol (Adjih et al.)
2.1.8
MANETconf: Configuration of Hosts in a
Mobile Ad Hoc Network (Nesargi et al.)
2.1.9
Extended Support for Global Connectivity for
IPv6 Mobile Ad Hoc Networks (Cha et al.)
2.2
Conflict-free allocation mechanisms
2.2.1
Prophet Address Allocation for Large Scale
MANETs (Zhou et al.)
2.2.2
Self-Configuring Networks. DRCP and DAAP
(McAuley et al.)
2.2.2.1
DRCP
2.2.2.2
DAAP
2.2.3
Autoconfiguration, Registration, and Mobility
Management for Pervasive Computing. DDCP (Misra et al.)
2.2.4
IP Address Assignment in a Mobile Ad Hoc
Network (Mohsin et al.)
2.2.5
An address assignment for the automatic
configuration of mobile ad hoc networks (Tayal et al.)
2.2.6
Simple MANET Address Autoconfiguration
(Clausen et al.)
2.2.7
Gateway and address autoconfiguration for IPv6
adhoc networks (Jelger et al.)
3.
Conclusions
4.
Security Considerations
5.
References
5.1
Normative References
5.2
Informative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
A group of mobile wireless nodes capable of spontaneously forming a network and support multi-hop communications constitutes a Mobile Ad Hoc Network (MANET). This kind of multi-hop network presents some interesting advantages, such as not requiring any infrastructure to work, e.g., allowing the extension of coverage areas or providing connectivity to nodes that not have the suitable access technologies. Several manet routing protocol specifications have been developed by the IETF MANET WG. In order to enable these networks to support IP services, address configuration of the nodes is a requirement. However, currently there is no standard specification that can be used by manet nodes to autoconfigure their IP addresses.
Existing solutions for IP infrastructure-based networks (e.g., RFCs 2461, 2462, 3315 etc.) cannot be directly used by nodes constituting an ad hoc network. These protocols assume the availability of a multicast capable link for signalling, but there is not such a link in ad-hoc multi-hop networks.
The main goal of the AUTOCONF group is to develop solutions for IPv4 and IPv6 address auto-configuration (both manet-local and global scoped). The group has identified three possible scenarios of MANET where IP address auto-configuration is required:
Ad hoc networks present a particular characteristic that should be taken into account when designing address auto-configuration protocols: two or more ad hoc network may get merged (the problem of having two or more nodes with the same IP address may arise) or single ad hoc network may get partitioned into two or more separate networks, at any moment of time.
This Internet Draft aims at describing some of the already proposed mechanisms for the autoconfiguration of IP addresses in MANET networks, trying to provide a useful reference in the standardisation process. Solutions proposed in research papers and submitted as I-Ds are presented and classified by a simple criteria. The analysis of the solutions includes a brief description of the mechanism and also a summary of the key characteristics.
| TOC |
In this section we briefly describe some of the existing proposals for IP address autoconfiguration, classifying them into two different categories: conflict-detection and conflict-free allocation. Some of the mechanisms included in this document are not complete autoconfiguration protocols, but just pieces (e.g., Duplicate Address Detection in the MANET) required in a more general autoconfiguration protocol. We also include them for completeness.
-----------------------------
| |
| Pool of |
| addresses |
| |
| |
| addrX |
| A |
-----+----------------------- -----
| | |
(1) | Node x picks an ----->| z |
| address (addrX) / | |
V / -----
----- ----- / (2) is addrX OK?
| | (2) | |/
Node x | x |----------------->| y |\
(3) waits | | is addrX OK? | | \ (2) is addrX OK?
for an ----- ----- \ -----
answer \ A \ | |
\ | ----->| t |
(2) is addrX OK? \ _/ | |
| __/ -----
V __/
----- __/
| | __/ (2) is addrX OK?
| w |_/
| |
-----
| Figure 1: Conflict-detection
allocation scheme |
These methods are based on picking an IP address from a pool of available addresses, configuring it as tentative address and asking the rest of the nodes of the network, checking the address uniqueness and requesting for approval from all the nodes of the network. In case of conflict (e.g., the address has been already configured by another node), the node should pick a new address and repeat the procedure (sort-of "trial and error" method). An example of conflict-detection allocation general mechanism is shown in Figure 1 (Conflict-detection allocation scheme).
This ad hoc address autoconfiguration mechanism, proposed in [1] (Perkins, C., Wakikawa, R., Malinen, J., Belding-Royer, E., and Y. Suan, “IP Address Autoconfiguration for Ad Hoc Networks,” November 2001.) and [14] (Suan, Y., Belding-Royer, E., and C. Perkins, “Internet Connectivity for Ad hoc Mobile Networks,” 2002.), basically consists in choosing an address randomly belonging to a network prefix available to the MANET and performing a Duplicate Address Detection procedure within the MANET (that we can called MANET-DAD to avoid confusing it with the DAD performed in IPv6 single-hop networks). The mechanism is defined both for IPv4 ([14] (Suan, Y., Belding-Royer, E., and C. Perkins, “Internet Connectivity for Ad hoc Mobile Networks,” 2002.), [1] (Perkins, C., Wakikawa, R., Malinen, J., Belding-Royer, E., and Y. Suan, “IP Address Autoconfiguration for Ad Hoc Networks,” November 2001.)) and IPv6 ([1] (Perkins, C., Wakikawa, R., Malinen, J., Belding-Royer, E., and Y. Suan, “IP Address Autoconfiguration for Ad Hoc Networks,” November 2001.)).
This mechanism works (for IPv4) as follows: when a node requires a unique IP address, it first selects a random host ID from the range [2048, (2^(32-n)-1)], where n is the number of significant bits in the network prefix available for the MANET. The node then appends that host ID to the prefix, thus forming the tentative IP address for which it performs MANET-DAD. The node also selects a random host ID in the range [0, 2047] and appends this value to the available network prefix, forming an address that is used as a temporary source IP address for the short period while the node performs MANET-DAD. The MANET-DAD is performed by creating an Address Request (AREQ) message, including its tentative IP address, which is broadcasted to its neighbours (using the randomly selected source address). When a node receives an AREQ message, it creates a reverse route entry for the node indicated by the random originator IP address. If the tentative address contained in the AREQ message does not match the address of the receiving node, it rebroadcasts the message to its neighbours. If the IP address of the receiving node matches the tentative address contained in the AREQ message it sends an Address Reply (AREP) message to the sender, indicating that the address is already in use. The route created by the AREQ messages is used to route the message back to the source node.
A requesting node sends an AREQ message, waits for the reception of an AREP message during a timer and retries the process several times. If no AREP is received, it assumes that the tentative address included in the AREQ messages is not in use and takes it for its own. If an AREP message is received, then it picks up a different host ID and begins the MANET-DAD process again.
For IPv6, the mechanism is similar. The tentative address belongs to a non-link-local prefix (a prefix obtained by other means or a default MANET_PREFIX reserved for MANET autoconfiguration). The source address belongs to a different non-overlapping prefix (or part of the prefix, if the same prefix is used for both tentative and source addresses). The protocol is basically the same, but using different message formats. For IPv4, ICMP messages are used, whereas in IPv6 modified Neighbour Solicitation and Advertisement messages are used.
In [15] (Nesargi, S. and R. Prakash, “MANETconf: Configuration of Hosts in a Mobile Ad Hoc Network,” 2002.) some limitations of this solution are presented.
Summary of some other characteristics:
The solution described in [16] (Weniger, K. and M. Zitterbart, “IPv6 Autoconfiguration in Large Scale Mobile Ad-Hoc Networks,” 2002.) extends the Neighbour Discovery and IPv6 Stateless Address Autoconfiguration mechanisms to work in multi-hop wireless networks. To do so, some modifications are needed:
It should be noted that because of the nature of the solution, it would be possible to have multihomed nodes (if a node is within the scope of more than one leader node).
Summary of some other characteristics:
The mechanism described in [17] (Vaidya, N., “Weak Duplicate Address Detection in Mobile Ad Hoc Networks,” 2002.) is not by itself an IP address autoconfiguration protocol, but a mechanism to ensure that packets ``meant for'' one node are not routed to another node, even if the two nodes have chosen the same address.
The authors follow an approach to solve the IP address autoconfiguration problem in ad Hoc networks, that is pretty common. The node just picks a tentative address randomly and performs a MANET-DAD procedure to detect if that address is already in use. Typically, these MANET-DAD mechanisms make use of timeouts and the author of [17] (Vaidya, N., “Weak Duplicate Address Detection in Mobile Ad Hoc Networks,” 2002.) says that message delays cannot be bounded in an ad hoc network (or if possible, determining the delays is non-trivial). Therefore, he proposes a 'weak' DAD, that prevents a packet to be delivered to a ``wrong'' destination node (even if two nodes have the same IP address). To do that, it is assumed that each node is pre-assigned a unique ``key'' (MAC addresses can be used as keys if they are guaranteed to be unique). Information about {IP address, key} pairs is included in the routing protocols (they assume that it is not possible to embed the key in the IP address), so address duplication can be detected. The authors describe how to do that with Link State Routing (proactive routing protocol) and Dynamic Source Routing (reactive routing protocol). The weak DAD cannot be used when flooding is used as the routing protocol.
Summary of some other characteristics:
This mechanism [2] (Wakikawa, R., “Global Connectivity for IPv6 Mobile Ad Hoc Networks,” October 2003.) is similar to [3] (Jelger, C., “Gateway and address autoconfiguration for IPv6 adhoc networks,” April 2004.) from the point of view of how IPv6 addresses are configured. Global prefix information is obtained from Internet gateways. They propose two methods for the Internet gateway discovery: one method periodically disseminates gateway advertisements to all nodes in the MANET; the other method utilises solicitation and advertisement signalling between a MANET node and the gateway. Extended router solicitation and advertisements of the Neighbour Discovery Protocol (NDP) or extended control message of each MANET routing protocol can be used for this signalling. The proposed methods target all MANET protocols regardless of whether they are reactive and proactive. Internet gateways supply their own global prefix information and IPv6 global address to MANET nodes somehow, either proactively or reactively. In this way, the reactive and proactive route discovery features of each MANET routing protocol are not disturbed.
Once the MANET node has obtained the prefix information from the Internet gateway, it uses the 64-bit interface ID in order to construct a valid address with the acquired prefix. It is assumed than before configuring a global IPv6 address, the node has configured a link local address, and MANET-DAD has been performed for that link-local address (using the mechanism defined in [1] (Perkins, C., Wakikawa, R., Malinen, J., Belding-Royer, E., and Y. Suan, “IP Address Autoconfiguration for Ad Hoc Networks,” November 2001.) and [14] (Suan, Y., Belding-Royer, E., and C. Perkins, “Internet Connectivity for Ad hoc Mobile Networks,” 2002.)), so it is assumed that the global address would be also unique. If not, the node may perform another MANET-DAD for this global address.
Summary of some other characteristics:
The IP address autoconfiguration mechanism described in [4] (Jeong, J., “Ad Hoc IP Address Autoconfiguration,” February 2005.) is comprised of three steps:
The MANET-DAD procedure follows an hybrid approach, consisting of two phases:
Summary of some other characteristics:
This mechanism [6] (Ruffino, S. and P. Stupar, “Automatic configuration of IPv6 addresses for nodes in a MANET with multiple gateways,” June 2005.) describes a mechanism to enable nodes of a MANET connected to the infrastructure - by means of one or more gateways - to configure IP addresses.
Each of the gateways available at the MANET has a global IPv6 prefix that is announced using a new OSLR message type, called Prefix Advertisement (PA). The nodes of the MANET can configure addresses belonging to each of the prefixes received (a generic MANET DAD procedure, such as [1] (Perkins, C., Wakikawa, R., Malinen, J., Belding-Royer, E., and Y. Suan, “IP Address Autoconfiguration for Ad Hoc Networks,” November 2001.), has to performed in order to verify uniqueness of MANET-local and global addresses).
The mechanism basically works as follows: at boostrap, a node configures a Primary Address (PADD) that is MANET-scoped and is used as main address in OLSR messages. The node then is able to start participating to OLSR and receiving topology information. With the prefix information received in the PA messages, the node is able to build a set of global IPv6 addresses (called Secondary Addresses: SADDs). Among them, the node chooses the "best" prefix and starts using the address formed from this prefix (called, Designated Secondary Address: DSADD). The node introduces all (or a subset) of the SADDs (including the DSADD) in OLSR messages and starts broadcasting them, enabling these addresses to be routable and reachable within the MANET.
Summary of some other characteristics:
This draft [7] (Laouiti, A., “Address autoconfiguration in Optimized Link State Routing Protocol,” February 2005.) describes a mechanism to perform MANET-DAD by extending the OLSR routing protocol. Basically, the MANET-DAD algorithm uses an special control packet called ``Multiple Address Declaration'' (MAD), that includes the node address and a node identifier (that must be globally unique). This packet is broadcast in the network, so all the nodes receive this packet. If a node receives a MAD message containing an address that matches its own address and a node identifier that does not, this implies that the address is duplicated. To spare the channel bandwidth, it is proposed to send MAD packets using the MPR (Multi-Point Relay) flooding.
Summary of some other characteristics:
Nesargi et al. propose in [15] (Nesargi, S. and R. Prakash, “MANETconf: Configuration of Hosts in a Mobile Ad Hoc Network,” 2002.) a Distributed Dynamic Host Configuration Protocol (DDHCP) designed to configure nodes in a MANET.
It basically operates as follows: a node proposes a candidate IP address for assignment to a newly arriving node. If the proposal is accepted by all the nodes that are part of the MANET, the proposed address is assigned to the newly arrived node. Otherwise, another candidate IP address is chosen and the process is repeated.
When a node (called requester) joins the MANET it broadcasts a request message to all its neighbours, waiting for a reply from a node willing to act as the initiator for the assignment of an IP address to the requester. If it is the first node of the MANET (no replies are received) it configures itself an IP address and the MANET its initialised. If the requester receives a reply message (or more than one), it then selects one of the reachable nodes that answered as the initiator, which will be the one that performs the address allocation on its behalf. All other nodes know a route to the initiator and can forward their responses to it. Ultimately, the initiator conveys the result of the address allocation operations to the requester.
The proposed protocol has some other interesting features, such as releasing unused IP addresses, soft state maintenance, concurrent IP address allocation and partition/merging support.
Summary of some other characteristics:
[8] (Cha, H., Park, J., and H. Kim, “Extended Support for Global Connectivity for IPv6 Mobile Ad Hoc Networks,” October 2003.) describes how to provide enhanced Internet connectivity to mobile ad-hoc networks. The protocol is devised as an extension to AODV, but the concept may be applicable to other proactive routing protocols.
The protocol basically consists in nodes requesting global addresses to a gateway (GW), which assigns a non-used address to the requesting node. More details can be found in [8] (Cha, H., Park, J., and H. Kim, “Extended Support for Global Connectivity for IPv6 Mobile Ad Hoc Networks,” October 2003.).
Summary of some other characteristics:
These methods assume that the addresses that are delegated are not being used by any node in the network. This can be achieved, for example, by ensuring that the nodes that participate in the delegation have disjoint address pools. In this way, there is no need of performing MANET-DAD. An example of a conflict-free allocation general mechanism is shown in Figure 2 (Conflict-free allocation scheme).
------------------------------
| |
| Pool of |
| addresses |
| |
-----+------------------------
|
(1) | Node x (first node) picks the
| pool and configures its interfaces
|
-+--- -----
| | (3) Node y requests | | (2) Node y joins
| x |<--------------------| y | the network
| | some addresses | |
-+--- ---+-
| \ ^ |
| \___________________/ |
| |
| (4) Node x gives half |
| its pool of |
| addresses |
| |
-------+------- ------------+--
| | | |
| Pool of | | Pool of |
| Node x | | Node y |
| | | |
--------------- ---------------
(5) Both Node x and Node y ?
can give addresses to --+--
new arriving nodes that | |
request IP addresses | z |
| |
-----
| Figure 2: Conflict-free allocation
scheme |
The mechanism defined in [18] (Zhou, H., Ni, L., and M. Mutka, “Prophet Address Allocation for Large Scale MANETs,” 2003.) is based on using an stateful function f(n) (where the initial state of f(n) is the seed) that produces as output an integer sequence of numbers. Different seeds lead to different sequences, and the state of f(n) is updated. This function can be used to derive IP addresses if it satisfies certain properties:
This properties may be satisfied if the space of available addresses is large, so it is easier to achieve in IPv6 than in IPv4.
The mechanism basically work as follows: the first node chooses a random number as its IP address and uses a random or default state value as the seed for its f(n). When a different node approaches, the first node uses its f(n) to obtain a different number and state. This number is used by the second node as its IP address, and the state is used as the seed for its f(n). After that both nodes are able to assign IP addresses to other nodes.
Summary of some other characteristics:
In [19] (McAuley, A. and K. Manousakis, “Self-Configuring Networks,” 2000.) the Dynamic Registration and Configuration Protocol (DRCP) and Dynamic Address Allocation Protocol (DAAP) are described. These two protocols together may provide autoconfiguration to entire networks. The authors state that their proposal is concerned with registration and autoconfiguration in 'quasi-dynamic networks'. They define quasi-dynamic networks as those that require rapid deployment, but are relatively stable except for some incremental deployment and losses.
Their goal is to allow all hosts and routers in the quasi-dynamic domain to be plug and play, being the only restriction on the number of nodes the size of the address space (paper focused in IPv4, but solution would be also applicable to IPv6).
The Dynamic Registration and Configuration Protocol (DRCP) is heavily based on DHCP, but aims at being faster and more suited to the quasi-dynamic network scenario (e.g., by using efficiently the scarce wireless bandwidth).
DRCP adds some new messages to DHCP. It uses a client-server model. The server sends periodic ADVERTISEMENT messages. The client transmits DISCOVER (or REQUEST) messages - requesting an IP address - until it gets an OFFER message - that carries a configuration message - (or ACK). The server keeps retransmitting the OFFER (or ACK) message until it gets an ACCEPT or DECLINE message.
The Dynamic Address Allocation Protocol (DAAP) is a new protocol that basically distributes address-pools among nodes in a domain. This allows any node to act as a new DRCP server, using a part of the addresses of the pool for allocation to new arriving nodes. The protocol is very simple and defines only two messages: one to request an address pool (POOL_REQUEST) and one to convey the response (POOL_RESPONSE).
The combination of DRCP and DAAP allows a rapid configuration of IP addresses in a network. Basically the first node has configured, by some other means (e.g., statically), an address pool. It then configures its interfaces using DRCP. After that, it starts sending DRCP ADVERTISEMENT messages. When a new node arrives, and discover the server, it configures an IP address in the interface that connects to that server, using DRCP. Then, it requests an address pool using DAAP. The initial node sends to the new node half of its address pool. The new node configures then the rest of its interfaces using DRCP and may start acting as a new DRCP server on the network.
Summary of some other characteristics:
The Dynamic Configuration Distribution Protocol (DDCP) proposed in [20] (Misra, A., Das, S., McAuley, A., and S. Das, “Autoconfiguration, Registration, and Mobility Management for Pervasive Computing,” 2001.) is quite similar to the DAAP proposal [19] (McAuley, A. and K. Manousakis, “Self-Configuring Networks,” 2000.). Actually DDCP just automates the distribution of address pools to other nodes, that can then run any link configuration protocol (LCP), like DHCP or DRCP to configure addresses of incoming nodes. The main difference with DAAP is that DDCP provides also autoconfiguration of additional IP-related parameters and capabilities, such as the location of DNS and SIP servers. Another difference is that DDCP explicitly states that nodes, when requested, split their address pools into two parts, forwarding the second part to the requester node (in DAAP, there is not such detail about how the address pool has to be split, although in the examples, the pool is halved in two as well).
Summary of some other characteristics:
The solution described in [21] (Mohsin, M. and R. Prakash, “IP Address Assignment in a Mobile Ad Hoc Network,” 2002.) is based on the concept of binary split, but address also the issue of partitioning, merging and abrupt departure of nodes from the MANET. This is done by associating a Partition ID, which should be universally unique, to every partition. If a MANET gets partitioned into two, as long as they do not run out of IP addresses, they do not generate new Partition IDs, so if they merge later there is no duplicated address. If one of the portions runs out of addresses, it generates a new Partition ID and acquires the IP address block that belongs to the other portion. If this portions merge later (the case of two MANETs that had not been previously part of the same MANET is analogous), one of the portions has to give up its IP address block. In this mechanism, the one with the larger address block is the one that gives up it addresses and has to acquire a new one.
Summary of some other characteristics:
The solution described in [22] (Tayal, A. and L. Patnaik, “An address assignment for the automatic configuration of mobile ad hoc networks,” 2004.) is very similar to the previous one ([21] (Mohsin, M. and R. Prakash, “IP Address Assignment in a Mobile Ad Hoc Network,” 2002.)), sharing the idea (also used by others) of having nodes assigning half of their address pools to newly arrived nodes that request IP addresses.
Summary of some other characteristics:
This draft [9] (Clausen, T. and E. Baccelli, “Simple MANET Address Autoconfiguration,” February 2005.) defines a simple autoconfiguration mechanism, based on partitioning a local scoped address space among the nodes of the MANET. This address space is used for assigning ``temporary addresses'' (also called ``local''). The nodes periodically signals their address space in ADDR_BEACON messages, in order to detect and solve conflicts.
When a new arriving node wants to configure a global IPv6 address, it first has to acquire a temporary address. To do this, it first listens to ADDR_BEACON messages sent by those nodes that may act as 'configuring nodes'. The new node selects a node as its configuring node and sends to it an ADDR_CONFIG message in order to request a local address. The configuring node, upon the reception of this request, assigns a local address to the new node and signals this assignment trough another ADDR_CONFIG message (additionally, this address is marked as ``used'' in the ADDR_BEACON messages it sends afterwards). Once the new node has configured a local address it can start participating in the routing protocol and it can start acquiring a global IP address. The configuring node is in charge of acting on behalf of the new node, and different mechanisms may be used, as acting as a proxy DHCP server and transmitting a request to an existing DHCP server or consulting the topology table (in case of proactive routing protocols as OLSR) and picking an non-used address.
Summary of some other characteristics:
This solution [3] (Jelger, C., “Gateway and address autoconfiguration for IPv6 adhoc networks,” April 2004.), combines the problem of IP address configuration and gateway discovery (needed to obtain global connectivity).
Basically, each gateway (it could be more than one in the same MANET) sends periodically GW_INFO messages to its one-hop neighbours. This information includes its IPv6 global address and prefix length. If a receiving node decides to use this information, it has to forward this message (updating some fields) to its neighbours (this leads to the so-called 'prefix continuity': any node A that selected a given prefix P has at least one neighbour on its path to the selected gateway G). The prefix information obtained from these GW_INFO messages is used in the creation of the global IPv6 address of the node, by adding the EUI64 of the interface from which the GW_INFO message has been received (padding with zeros if needed). [3] (Jelger, C., “Gateway and address autoconfiguration for IPv6 adhoc networks,” April 2004.) states that the MANET-DAD procedure must not be performed.
Summary of some other characteristics:
| TOC |
This draft has presented some of the solutions for the problem of the autoconfiguration of IP addresses in Mobile Ad Hoc Networks that have been proposed so far. This document tries to provide a reference that could help in the discussions of the AUTOCONF group, just presenting the already available mechanisms that tackle the autoconfiguration problem.
A detailed analysis of the characteristics (i.e., complexity, communication overhead, latency, scalability, network requirements, etc.) of each proposal, as well as a more extensive problem statement, are not included yet.
| TOC |
This documents does not raise any security issue. The possible security considerations of the described proposals have not been addressed in this I-D.
| TOC |
| TOC |
| [1] | Perkins, C., Wakikawa, R., Malinen, J., Belding-Royer, E., and Y. Suan, “IP Address Autoconfiguration for Ad Hoc Networks,” draft-ietf-manet-autoconf-01.txt (work in progress), November 2001. |
| [2] | Wakikawa, R., “Global Connectivity for IPv6 Mobile Ad Hoc Networks,” draft-wakikawa-manet-globalv6-03 (work in progress), October 2003. |
| [3] | Jelger, C., “Gateway and address autoconfiguration for IPv6 adhoc networks,” draft-jelger-manet-gateway-autoconf-v6-02 (work in progress), April 2004. |
| [4] | Jeong, J., “Ad Hoc IP Address Autoconfiguration,” draft-jeong-adhoc-ip-addr-autoconf-04 (work in progress), February 2005. |
| [5] | Jeong, J., “Ad Hoc IP Address Autoconfiguration for AODV,” draft-jeong-manet-aodv-addr-autoconf-01 (work in progress), July 2004. |
| [6] | Ruffino, S. and P. Stupar, “Automatic configuration of IPv6 addresses for nodes in a MANET with multiple gateways,” draft-ruffino-manet-autoconf-multigw-00 (work in progress), June 2005. |
| [7] | Laouiti, A., “Address autoconfiguration in Optimized Link State Routing Protocol,” draft-laouiti-manet-olsr-address-autoconf-00 (work in progress), February 2005 (TXT, PS). |
| [8] | Cha, H., Park, J., and H. Kim, “Extended Support for Global Connectivity for IPv6 Mobile Ad Hoc Networks,” draft-cha-manet-extended-support-globalv6-00 (work in progress), October 2003. |
| [9] | Clausen, T. and E. Baccelli, “Simple MANET Address Autoconfiguration,” draft-clausen-manet-address-autoconf-00 (work in progress), February 2005. |
| [10] | Jeong, J., “Requirements for Ad Hoc IP Address Autoconfiguration,” draft-jeong-manet-addr-autoconf-reqts-04 (work in progress), February 2005. |
| [11] | Ruffino, S., Stupar, P., and T. Clausen, “Autoconfiguration in a MANET: connectivity scenarios and technical issues,” draft-ruffino-manet-autoconf-scenarios-00 (work in progress), October 2004. |
| [12] | Ruffino, S., “Connectivity Scenarios for MANET,” draft-ruffino-conn-scenarios-00 (work in progress), February 2005. |
| [13] | Wakikawa, R., “IPv6 Support on Mobile Ad-hoc Network,” draft-wakikawa-manet-ipv6-support-00 (work in progress), February 2005. |
| TOC |
| [14] | Suan, Y., Belding-Royer, E., and C. Perkins, “Internet Connectivity for Ad hoc Mobile Networks,” International Journal of Wireless Information Networks special issue on 'Mobile Ad Hoc Networks (MANETs): Standards, Research, Applications' , 2002. |
| [15] | Nesargi, S. and R. Prakash, “MANETconf: Configuration of Hosts in a Mobile Ad Hoc Network,” IEEE INFOCOM 2002 , 2002. |
| [16] | Weniger, K. and M. Zitterbart, “IPv6 Autoconfiguration in Large Scale Mobile Ad-Hoc Networks,” European Wireless 2002 , 2002. |
| [17] | Vaidya, N., “Weak Duplicate Address Detection in Mobile Ad Hoc Networks,” MOBIHOC'02 , 2002. |
| [18] | Zhou, H., Ni, L., and M. Mutka, “Prophet Address Allocation for Large Scale MANETs,” Proceedings of INFOCOM 2003 , 2003. |
| [19] | McAuley, A. and K. Manousakis, “Self-Configuring Networks,” 21st Century Military Communications Conference Proceedings , 2000. |
| [20] | Misra, A., Das, S., McAuley, A., and S. Das, “Autoconfiguration, Registration, and Mobility Management for Pervasive Computing,” IEEE Personal Communications , 2001. |
| [21] | Mohsin, M. and R. Prakash, “IP Address Assignment in a Mobile Ad Hoc Network,” MILCOM 2002 , 2002. |
| [22] | Tayal, A. and L. Patnaik, “An address assignment for the automatic configuration of mobile ad hoc networks,” Personal Ubiquitous Computing , 2004. |
| [23] | Zhou, Z. and A. Seneviratne, “A Survey of Zero and Auto Configurations for Wireless Networks,” ATNAC 2003 , 2003. |
| TOC |
| Carlos J. Bernardos | |
| Universidad Carlos III de Madrid | |
| Av. Universidad, 30 | |
| Leganes, Madrid 28911 | |
| Spain | |
| Phone: | +34 91624 8859 |
| Email: | cjbc@it.uc3m.es |
| María Calderón | |
| Universidad Carlos III de Madrid | |
| Av. Universidad, 30 | |
| Leganes, Madrid 28911 | |
| Spain | |
| Phone: | +34 91624 8780 |
| Email: | maria@it.uc3m.es |
| TOC |
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.
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 © The Internet Society (2005). 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.
Funding for the RFC Editor function is currently provided by the Internet Society.