MANET Autoconfiguration (AUTOCONF) K. Mase Internet-Draft Information and Communication Expires: May 4, 2006 Network Lab., Niigata University C. Adjih Information and Communication Network Lab., Niigata University. (Permanent address: INRIA Domaine de Voluceau, Rocquencourt, France) October 31, 2005 A common framework for autoconfiguration of stand-alone ad hoc networks draft-mase-autoconf-framework-00 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 May 4, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract We consider the unique local address autoconfiguration problem for Mase & Adjih Expires May 4, 2006 [Page 1] Internet-Draft Framework October 2005 stand-alone ad hoc networks (MANETs). Specifically, we consider two cases. First, a node without a pre-assigned and valid MANET-local address acquires a new MANET-local address and becomes a member of a new or existing MANET. Second, two or more MANETs merge. In the first case, a mechanism of IP address generation based on a stateful or stateless method is needed. We also should have MANET-wide duplicate address detection (MANET-DAD) on newly generated address (tentative address) for suppressing occurrence of duplicate addresses regardless of whether stateful or stateless method is employed for address generation (pre-service MANET-DAD). In the second case, duplicate address may occur as the result of a merger of two formerly independent networks. We should have MANET-DAD on addresses in use for resolving duplicate addresses and suppressing routing information contamination due to existence of duplicate addresses (in-service MANET-DAD). To realize pre-service MANET-DAD and in-service MANET- DAD, we define autoconfiguration states for both proactive and reactive routing protocol. Each node exists in one of the autoconfiguration states at any time. The specific MANET-DAD algorithm is beyond the scope of this document. Mase & Adjih Expires May 4, 2006 [Page 2] Internet-Draft Framework October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology [2],[3] . . . . . . . . . . . . . . . . . . . . . 6 2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Autoconfiguration states . . . . . . . . . . . . . . . . . . . 10 4.1. Autoconfiguration states for reactive routing protocol . . 10 4.2. Autoconfiguration states for proactive routing protocol . 13 5. Effect of autoconfiguration states . . . . . . . . . . . . . . 16 6. Proposed Values for Constants . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . . . 24 Mase & Adjih Expires May 4, 2006 [Page 3] Internet-Draft Framework October 2005 1. Introduction This document discusses autoconfiguration of unique local (MANET- local) address for stand-alone MANET. Autoconfiguration methods are generally classified into stateless and stateful methods. Conventional statefull and stateless autoconfiguration methods cannot be used for stand-alone mobile ad hoc networks (MANETs), since such networks do not depend on a central server and multihop communication is involved. A number of autoconfiguration solutions to prevent address conflict have been proposed for stand-alone MANETs [1],[6]-[21]. Some of these proposals discuss MANET-wide duplicated address detection (MANET-DAD) only in initial address generation and do not discuss potential occurrence of address conflict when network mergers occur. Some of these proposals discuss MANET-DAD to deal with address conflict in case of a merger. The aim of this document is not to provide another solution for the MANET autoconfiguration problem, but to give a common framework, that may be useful for designing solutions regardless of wether the underlying routing protocol is proactive or reactive. The baselines of this framework are as follows: - Each node should perform MANET-DAD both before and after assignment of a valid address in a MANET. This is termed "pre- service MANET-DAD" and "in-service MANET-DAD" respectively. - MANET-DAD functions should be embedded in routing control messages regardless of pre-service MANET-DAD or in-service MANET- DAD. With regard to the first baseline above, pre-service MANET-DAD is useful to suppress occurrences of an address conflict regardless of whether stateless or stateful address assignment methods are employed and in-service MANET-DAD is useful to suppress occurrences of address conflict in case of network mergers. To realize pre-service and in- service MANET-DAD systematically, we use the concept of autoconfiguration states. This was first proposed in [6] and is extended in this document. The second baseline is useful to reduce pre-service MANET-DAD and in-service MANET-DAD overhead, even when nodes in pre-service MANET-DAD state and those in in-service MANET- DAD state coexist. A pioneering example of pre-service MANET-DAD for a reactive routing MANET was proposed in [7]. A pioneering example of in-service MANET-DAD for both proactive and reactive routing protocols was proposed in [1]. These useful but individual schemes can be systematically included as the elements in the proposed framework. A functionality and mechanism of "Duplicate address detection(DAD)" for link-local address are defined in the traditional IETF terms-RFC(2461/2462) [3] and [4]. The mechanisms defined in this document, i.e., "pre-service MANET-DAD" is identical in Mase & Adjih Expires May 4, 2006 [Page 4] Internet-Draft Framework October 2005 functionality (but not mechanism) to DAD, and "in-service MANET-DAD" is a fundamentally new-to IETF functionality, necessary for MANETs. Mase & Adjih Expires May 4, 2006 [Page 5] Internet-Draft Framework October 2005 2. Terminology [2],[3] 2.1. General This section provides definitions for terms that have a specific meaning to the protocol specified in this document and that are used throughout the text. Some fundamental definitions are taken from [3], [4]. IP - Internet Protocol Version 4 or 6. node - a device that implements IP. link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP. interface - a node's attachment to a link. neighbors - nodes attached to the same link. address - an IP-layer identifier for an interface. MANET-local address - a unique-local address having scope that is limited to the MANET. Tentative address - an address whose uniqueness in a MANET is being verified, prior to its assignment to an interface. A tentative address is not considered assigned to an interface in the usual sense. An interface discards received packets addressed to a tentative address, but accepts Routing Control packets related to MANET-wide Duplicate Address Detection for the tentative address. Address Generation - Adress generation is a procedure for a node, that has currently no address, to obtain a tentative address in the MANET -either of its own accord or with support of other nodes. Address Conflict - When two nodes in the same MANET network share the same address or tentative address, the situation is described as an "Address Conflict". The nodes involved are "conflicting nodes" and their shared address is called the "conflicting address". Conflicting nodes may each send a message with the identical sequence number and message type: such messages are denoted "conflicting messages". Mase & Adjih Expires May 4, 2006 [Page 6] Internet-Draft Framework October 2005 MANET-wide Duplicate Address Detection (MANET-DAD) - MAENT-wide Duplicate address detection is the action of detecting address conflict in the MANET, the situation where some nodes are going to use or using the same address in the same MANET network. Pre-Service MANET-DAD - Pre-service MANET-DAD is the procedure to verify that a tentative address is out of address conflict with other MANET nodes. In-Service MANET-DAD - In-service MANET-DAD is the procedure to continuously verify a used address is out of address conflict with other MANET nodes. Autoconfiguration State - The current autoconfiguration state of the node, one of NO_ADDRESS, INQUIRY, and NORMAL for reactive routing protocols and one of HELLO, TOPOLOGY, and NORMAL for proactive routing protocols, which indicates what messages it should (or should not) generate and what processing it should (or should not) do. Familiar Address (Node) - An address is familiar to a node, if the node has seen it in control messages for a sufficiently long period of time. A node recognizes the other node with a familiar address as the familiar node. An address or a node which is not familiar is denoted "unfamiliar". Routing Table Contamination Avoidance - Routing table contamination avoidance is the idea of preserving the routing table from incorrect information due to address conflicts. This is achieved by using the autoconfiguration states. Sequence Number Consistency - All control messages have a sequence number. One trademark of duplicate addresses is sequence numbers of different messages, which could not result from a correct implementation of the routing protocol (such as decrease in sequence numbers, etc.). The properties of sequence numbers, which would result from the normal routing protocol implementation, are termed "Sequence number consistency". 2.2. Requirements The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [2]. Mase & Adjih Expires May 4, 2006 [Page 7] Internet-Draft Framework October 2005 3. Overview We consider the MANET-local address autoconfiguration problem for stand-alone MANETs. Specifically, we consider two cases. - In the first case, a node without a pre-assigned address acquires an address and becomes a member of a new or existing MANET. - In the second case, two or more MANETs merge. For the first case, a mechanism of address generation is needed, and a number of address generation methods have been proposed in literature. These are classified into stateful and stateless methods. In this case, a node first obtains an address (tentative address) using a proper address generation method, - be that either a stateful or stateless method. It then verifies that the tentative address is not part of an address conflict with (not currently used by) other nodes. This procedure is termed "pre-service MANET-DAD" in this document. We SHOULD have pre-service MANET-DAD on a tentative address for suppressing occurrence of duplicate addresses in the address assignment regardless of whether stateful or stateless methods is employed. Note that the necessity of pre-service MANET- DAD for MANETs with reactive routing protocol has been well known [7], while that for MANETs with proactive routing protocol was identified only recently [6]. In the second case, duplicate address may occur as a result of two already configured networks merging. To cope with this situation, a node in an existing MANET SHOULD continuously verify possible address conflict with other MANET nodes. This procedure is termed "in- service MANET-DAD" in this document. "Weak DAD" [13] and "passive DAD" [1] are examples of in-service MANET-DAD. When an address conflict is detected, a node with a duplicate address MUST obtain a new address to resolve the address conflict. This is accomplished using the address generation mentioned before. During duplicate address detection and resolution in the above case, some nodes may share the same address transiently and, therefore, routing information may not be correctly maintained. Specifically, a route entry may erroneously be updated based on control messages including information from different nodes with the same duplicate address. We call this problem "routing information contamination". We SHOULD have in-service MANET-DAD for detecting duplicate addresses as well as for suppressing routing contamination due to existence of duplicate addresses. To systematically realize pre-service MANET-DAD and in-service MANET-DAD, we define autoconfiguration states for both proactive and reactive routing protocols. Each node is in one of the autoconfiguration states at any time. The proposed framework covers Mase & Adjih Expires May 4, 2006 [Page 8] Internet-Draft Framework October 2005 both proactive and reactive routing protocols. Specific pre-service and in-service MANET-DAD algorithms are beyond the scope of this document. Mase & Adjih Expires May 4, 2006 [Page 9] Internet-Draft Framework October 2005 4. Autoconfiguration states A set of autoconfiguration states are defined, for both reactive and proactive routing protocols in order to realize pre-service MANET-DAD and in-service MANET-DAD. Each node has an "autoconfiguration state". This state is an indicator of how long the node has been in the network. The central idea is that each time a node generates a new address, it should enter the network gradually, i.e. be in a pre- service autoconfiguration state and running a restrained version of the routing protocol. This way, the node can detect which addresses are being used, checking for duplicates of its own address, while avoiding disrupting the routing tables of the other nodes in the MANET in the event that its address is actually found to be in conflict. 4.1. Autoconfiguration states for reactive routing protocol There are exactly 3 autoconfiguration states for reactive routing protocols, which define the behavior of the node as follows: NO_ADDRESS_STATE : In this state a node does not have its own address, and it MUST NOT process and forward RREQ and RREP messages generated by other nodes. It MUST NOT participate in data forwarding. It MAY generate a tentative address by means of a pre-determined address generation method. When it generates its tentative address, it enters the INQUIRY_STATE. INQUIRY_STATE - In this state, a node MUST NOT process and forward RREQ and RREP messages generated by other nodes. It MUST NOT participate in data forwarding. It SHOULD perform pre-service MANET-DAD using the same control messages such as route request (RREQ) and route reply (RREP) messages defined for the reactive routing protocol in the MANET. Specific pre-service MANET-DAD methods for reactive routing protocols are beyond the scope of this document. One of these methods is termed as "Strong DAD" in the literature, e.g. [13],[14]. To distinguish between normal control messages and those of autoconfiguration, a flag in the control message MAY be used to represent autoconfiguration state. For example, 0/1 in a RREQ indicates that the originating node is in NORMAL_STATE /INQUIRY_STATE, respectively. When the node detects that it has an address conflict with other nodes, it MUST re-enter NO_ADDRESS_STATE. When a pre-determined time has elapsed in INQUIRY_STATE without an address conflict being detected, the node enters the NORMAL_STATE. Mase & Adjih Expires May 4, 2006 [Page 10] Internet-Draft Framework October 2005 NORMAL_STATE : In this state, the node is running the "normal" reactive routing protocol without message processing/generation restrictions associated to the state. More precisely, the node generates both RREQ messages and RREP messages as usual. It processes RREQ and RREP messages generated by other nodes and forwards these as specified by the routing protocol. It also participates in data forwarding. Only nodes in NORMAL_STATE are selected as the intermediary nodes (forwarders) during route discovery and route maintenance. A node in this state SHOULD perform in-service MANET-DAD using the same control messages, such as route request (RREQ) and route reply (RREP) messages, as are defined for the reactive routing protocol in the MANET. Specific in-service MANET-DAD method for reactive routing protocols is beyond the scope of this document. When the node detects that it has an address conflict with other nodes, it MUST return the NO_ADDRESS_STATE. The behavior in each state is summarized in Table I and the state transition diagram is given in Fig.1 Mase & Adjih Expires May 4, 2006 [Page 11] Internet-Draft Framework October 2005 Table I. Autoconfiguration states for reactive routing protocol. +----------------+----------------+----------------+----------------+ | State | NO_ADDRESS_ | INQUIRY_STATE | NORMAL_STATE | | | STATE | | | +----------------+----------------+----------------+----------------+ | Address | yes | no | no | | Generation | | | | | | | | | | RREQ/RREP | no | no | yes | | forwarding | | | | | | | | | | RREQ/RREP | no | yes | yes | | processing | | | | | | | | | | RREQ/RREP | no | yes | yes | | generation | | | | | | | | | | Routing table | no | no | yes | | (and | | | | | forwarding) | | | | | | | | | | State duration | as long as |INQUIRY_ STATE_ | forever | | (if no address | no address | DURATION | | | change) | | | | +----------------+----------------+----------------+----------------+ Dupulicate (Address generation) address detected +-------------------+ Dupulicate +----------------->| NO_ADDRESS | address detected | +---------------+ _STATE |<---------------+ | | Address +-------------------+ | | | Generated | | | | | v | +--------------+ +---------------+ | INQUIRY | Time-out | NORMAL | | _STATE +-------------------------------->| _STATE | +--------------+ +---------------+ (Pre-service MANET-DAD) (In-service MANET-DAD) Fig.1 Autoconfiguration state transition diagram for reactive routing protocol. Mase & Adjih Expires May 4, 2006 [Page 12] Internet-Draft Framework October 2005 4.2. Autoconfiguration states for proactive routing protocol In the following descriptions we assume OLSR as an example of the proactive routing protocols. We point out that this is without loss of generality of the proposed framework. There are exactly 4 autoconfiguration states, in each of which the behavior of the node is: NO_ADDRESS_STATE : In this state a node does not have its own address, and it MUST NOT process and forward HELLO and TC (Topology Control) messages generated by other nodes. It MUST NOT participate in data forwarding. It generate a tentative address by means of a pre-determined address generation method. When it generate a tentative address, it enters the HELLO_STATE. HELLO_STATE : In this state, a node generates HELLO messages, but not TC messages. It MUST NOT participate in MPR selection nor MPR flooding, and MUST NOT participate in data packet forwarding either. It doesn't populate the topology set nor the routing table. It SHOULD perform pre-service MANET-DAD using the same HELLO messages defined for the proactive routing protocol in the MANET. When it detects that it has an address conflict with other nodes, it MUST re-enter NO_ADDRESS_STATE. When a pre-determined time has elapsed in HELLO_STATE without detecting address conflict, the node enters the TOPOLOGY_STATE. TOPOLOGY_STATE : In this state, a node generates HELLO messages, but not TC messages. It processes TC messages, and performs MPR selection, but MUST NOT be MPR itself (i.e. in OLSR-willingness will-never) and hence, MUST NOT forward TC messages. It populates its topology set but not its routing table, and MUST NOT participate in data packet forwarding. It performs pre-service MANET-DAD using the same HELLO and TC messages defined for the proactive routing protocol in the MANET. When the node detects that it has an address conflict with another node, it MUST re- enter NO_ADDRESS_STATE. When a pre-determined time elapses in TOPOLOGY_STATE without detecting address conflict, node enters the NORMAL_STATE. NORMAL_STATE : In this state, the node is running the "normal" OLSR protocol without message processing/generation restrictions associated to the state. More precisely, the node generates both HELLO messages and TC messages as specified by the routing protocol specification. It processes TC messages generated by other nodes and forwards these as usual based on MPR flooding. The node populates its topology set, calculates routing tables and participates in data forwarding. Only nodes in the NORMAL_STATE are selected as intermediary nodes (forwarders) in the routing Mase & Adjih Expires May 4, 2006 [Page 13] Internet-Draft Framework October 2005 table calculation. A node in this state SHOULD perform pre- service MANET-DAD using the same HELLO and TC messages defined for the proactive routing protocol in the MANET. When a node detects that it has an address conflict with another node, it MUST re- enter NO_ADDRESS_STATE. The behavior in each state is summarized in Table II and the state transition diagram is given in Fig.2. Table II. Autoconfiguration states for proactive routing protocol. +----------------+-------------+-------------+------------+------------+ | State | NO_ADDRESS_ | HELLO_STATE | TOPOLOGY_ | NORMAL_ | | | STATE | | STATE | STATE | +----------------+-------------+-------------+------------+------------+ | Address | yes | no | no | no | | Generation | | | | | | | | | | | | Selectable as | no | no | no | yes | | MPR | | | | | | | | | | | | MPR selection | no | no | yes | yes | | | | | | | | TC message | no | no | no | yes | | forwarding | | | | | | | | | | | | TC message | no | no | yes | yes | | processing | | | | | | | | | | | | | | | | | | TC message | no | no | no | yes | | generation | | | | | | | | | | | | Routing table | no | no | no | yes | | calculation | | | | | |(and forwarding)| | | | | | | | | | | | State duration | as long as | HELLO_ | TOPOLOGY_ | forever | | (if no address | no address | STATE_ | STATE_ | | | change) | | DURATION | DURATION | | +----------------+-------------+-------------+------------+------------+ Mase & Adjih Expires May 4, 2006 [Page 14] Internet-Draft Framework October 2005 (Address generation) (In-service MANET-DAD) +------------+ Duplicate address +------------+ | NO_ADDRESS | detected | NORMAL | +-+ _STATE |<---------------------+ _STATE |<---+ | +------------+ +------------+ | | ^ ^ | | | | Duplicate address | | | | detected | Address | | +---------------------------+ | generated | | | Time-out | | | Dupulicate | | | | address | | | | detected | | | | | | | +-+----------+ +-+----------+ | | | HELLO | Time-out | TOPOLOGY | | +->| _STEATE +--------------------->| _STATE +---+ +------------+ +------------+ (Pre-service MANET-DAD) Fig.2 Autoconfiguration state transition diagram for proactive routing protocol. Mase & Adjih Expires May 4, 2006 [Page 15] Internet-Draft Framework October 2005 5. Effect of autoconfiguration states Pre-service MANET-DAD is performed when a node is in the INQUIRY_STATE in case of reactive routing protocols and in the HELLO_STATE or TOPOLOGY_STATE in case of proactive routing protocols. Pre-service MANET-DAD is effective at reducing potential address conflicts and the resulting routing table contamination when a new node joins a MANET. These states are, however, not only effective for enabling pre-service MANET-DAD. When a node is in one of these states, other nodes in the MANET have a chance to learn information about the node, such as address and sequence number. Specifically, we assume that each node continuously collects information about other nodes, regardless of their states. As a result, each node is "familiar" with other nodes in NORMAL_STATE within the connected MANET. When network merger occurs, a node may find unfamiliar nodes, allowing it to detect the network merger. Thus, network merger of multiple different MANETs can be detected without a sophisticated network merger detection method such as based on network ID as proposed in the literature [9]. This learning mechanism may be useful for easing the design of an in-service MANET-DAD algorithm. Specific in-service MANET-DAD algorithms are beyond the scope of this document. Mase & Adjih Expires May 4, 2006 [Page 16] Internet-Draft Framework October 2005 6. Proposed Values for Constants The proposed values of the specification are documented here[6]. Parameter Name Value ----------------------- -------------------------------------- INQUIRY_STATE_DURATION NET_TRAVERSAL_TIME NET_TRAVERSAL_TIME 2 * NODE_TRAVERSAL_TIME * NET_DIAMETER NODE_TRAVERSAL_TIME 40 millisecond NET_DIAMETER 35 HELLO_STATE_DURATION HELLO_INTERVAL * 3 TOPOLOGY_STATE_DURATION TC_INTERVAL * 3 Mase & Adjih Expires May 4, 2006 [Page 17] Internet-Draft Framework October 2005 7. IANA Considerations This document has no actions for IANA. Mase & Adjih Expires May 4, 2006 [Page 18] Internet-Draft Framework October 2005 8. Security Considerations This document presents only framwork of autoconfiguration for stand- alone MANETs and does therefore not specify any special security measure. However, introduction of autoconfiguration states may be useful to realize some security measures. For example, node authentification may be done during the INQUIRY_STATE in a MANET with reactive routing protocols and during the HELLO_STATE and TOPOLOGY_STATE in a MANET with proactive routing protocols. Mase & Adjih Expires May 4, 2006 [Page 19] Internet-Draft Framework October 2005 9. Acknowledgements This work was funded by Strategic Information and Communications R&D Promotion Programme (SCOPE), Ministry of Internal Affairs and Communications, Japan. The authors would like to gratefully acknowledge Thomas Clausen (Ecole Polytechnique) for intense technical discussions, early reviews and comments on this work. Mase & Adjih Expires May 4, 2006 [Page 20] Internet-Draft Framework October 2005 10. References 10.1. Normative References [1] Weniger, K., "Passive Duplicate Address Detection in Mobile Ad Hoc Networks," in Proceedings of IEEE WCNC 2003, New Orleans, USA, Mar. 2003. [2] Brander, S. "Key words for use in RFCs to Indicate Requirement Levels," RFC2119, Mar. 1997. [3] Narten, T., E. Nordmark and W. Simpson,"Neighbor Discovery for IP Version 6 (IPv6)," RFC2461, Dec. 1998. [4] Thomson, S. and T. Narten,"IPv6 Stateless Address Autoconfiguration," RFC2462, Dec. 1998. [5] Perkins, C. E., E. Belding-Royer and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing," RFC3561, July 2003. 10.2. Informative References [6] Mase, K. and C. Adjih, "No Ovrhead Autoconfiguration OLSR", draft-mase-manet-atuoconf-noaolsr-00 (work in progress), May 2005. [7] Perkins, C. E., J. T. Malinen, R. Wakikawa, E. M. Belding- Royer, and Y. Sun, "IP Address Autoconfiguration for Ad Hoc Networks," draft-ietf-manet-autoconf-01.txt, Nov. 2001, work in progress. [8] Mohsin, M. and R. Prakash, "IP Address Assignment in a Mobile Ad Hoc Network," MILCOM 2002. [9] Nesargi, S. and R. Prakash, "MANETconf: Configuration of Hosts in a Mobile Ad Hoc Network," in Proc. of IEEE INFOCOM 2002, New York, June 2002. [10] Boleng, J., "Efficient Network Layer Addressing for Mobile Ad Hoc Networks," in Proc. of Int. Conf. on Wireless Networks (ICWN '02), pp. 271-277, Las Vegas, June 2002. [11] Weniger, K. and M. Zitterbart, "IPv6 Autoconfiguration in Large Scale Mobile Ad-Hoc Networks," in Proc. of European Wireless 2002, vol. 1, pp. 142-148, Florence, Feb. 2002. [12] Zhou, H., L. M. Ni, and M. W. Mutka, "Prophet Address Allocation for Large Scale MANETs," INFOCOM 2003. Mase & Adjih Expires May 4, 2006 [Page 21] Internet-Draft Framework October 2005 [13] Vaidya N. H., "Weak Duplicate Address Detection in Mobile Ad Hoc Networks," in Proc. of ACM MobiHoc 2002, pp. 206-216, Lausanne, Switzerland, June 2002. [14] Jeong, J., "Ad Hoc IP Address Autoconfiguration," Internet Draft, draft-jeong-adhoc-ip-addr-autoconf-00.txt, Nov. 2003, work in progress. [15] Mase, K., S. Narita, and S. Yoshida, "Efficient IP address Assignment in Mobile Ad Hoc Networks," pp. 504-508, WPMC, 2003. [16] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003. [17] Perkins, C. E., Belding-Royer, E., and S. Das, "Ad hoc On- Demand Distance Vector (AODV) Routing", RFC 3561, July 2003. [18] 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. [19] Weniger, K., "Passive Duplicate Address Detection in Mobile Ad hoc Networks", March 2003. [20] Singh, S., J. Kim, C. E. Perkins, P. M. Ruiz, and T. Clausen, "Ad Hoc Network Autoconfiguration: Definition and Problem Statement", draft-singh-autoconf-adp-00.txt (work in progress), Feb. 2005. [21] Bernardos, C. and M. Calderon, "Survey of IP address autoconfiguration mechnisms ofr MANETs", draft-bernardos-manet-autoconf-survey-00 (work in progress), July 2005. Mase & Adjih Expires May 4, 2006 [Page 22] Internet-Draft Framework October 2005 Authors' Addresses Kenichi Mase Information and Communication Network Lab., Niigata University Phone: +81 25 262 7446 Email: mase@ie.niigata-u.ac.jp URI: http://www.net.ie.niigata-u.ac.jp/ Cedric Adjih Information and Communication Network Lab., Niigata University. (Permanent address: INRIA Domaine de Voluceau, Rocquencourt, France) Email: cedric@net.ie.niigata-u.ac.jp, cedric.adjih@inria.fr Mase & Adjih Expires May 4, 2006 [Page 23] Internet-Draft Framework October 2005 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 (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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Mase & Adjih Expires May 4, 2006 [Page 24]