MANET Autoconfiguration (AUTOCONF) K. Mase Internet-Draft Niigata University Expires: March 21, 2008 C. Adjih INRIA Domaine de Voluceau, Rocquencourt, France E. Baccelli INRIA September 18, 2007 A common framework for autoconfiguration of ad hoc networks draft-mase-autoconf-framework-04 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 March 21, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Mase, et al. Expires March 21, 2008 [Page 1] Internet-Draft Framework September 2007 Abstract We consider the unique address/prefix autoconfiguration problem for MANETs. Specifically, we consider two cases. First, a node without a pre-assigned and valid local address/prefix acquires a new local address/prefix 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/prefix generation is needed. We may have MANET-wide duplicate address/prefix detection (DAD) on newly generated address/ prefix (tentative address/prefix) for suppressing occurrence of address/prefix conflict with existing address/prefixes (pre-service DAD). In the second case, duplicate address/prefix may occur as the result of a merger of two formerly independent networks. We may have DAD on addresses/prefixes in use for detecting and resolving duplicate addresses/prefixes and suppressing routing information contamination due to existence of duplicate addresses/prefixes (in- service DAD). To define pre-service DAD and in-service DAD, we use autoconfiguration phases that are common for both proactive and reactive routing protocol. Each node exists in one of the autoconfiguration phases at any time. A node, that detects duplicate address/prefix between other nodes, may advertise the detected duplicate address/prefix to all other nodes in the MANET. This is termed "Duplicate address/prefix advertisement" (DAA). The specific DAD and DAA algorithm is beyond the scope of this document. Mase, et al. Expires March 21, 2008 [Page 2] Internet-Draft Framework September 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 3. Autoconfiguration framework . . . . . . . . . . . . . . . . . 7 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Autoconfiguration phases . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Mase, et al. Expires March 21, 2008 [Page 3] Internet-Draft Framework September 2007 1. Introduction This document discusses autoconfiguration of local address/prefix for MANETs[5]. Autoconfiguration methods are generally classified into stateless and stateful methods. Conventional statefull and stateless autoconfiguration methods cannot be used for MANETs, since such networks do not depend on a central server and multihop communication is involved. A number of autoconfiguration solutions to prevent address/prefix conflict have been proposed for MANETs [6]-[22]. Some of these proposals discuss MANET-wide duplicated address/prefix detection (DAD) only in initial address/prefix generation and do not discuss potential occurrence of address/prefix conflict when network mergers occur. Some of these proposals discuss DAD to deal with address/prefix 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. We also consider the necessity and benefits of advertising duplicate addresses/prefixes to other nodes in the MANET, that is termed "Duplicate address/prefix advertisement" (DAA). A functionality and mechanism of "Duplicate address/prefix detection(DAD)" for link-local address/prefix are defined in the traditional IETF terms-RFC(2461/2462) [2] and [3]. The mechanisms defined in this document, i.e., "pre-service DAD" is identical in functionality (but not mechanism) to DAD, and "in-service DAD" is similar to functionality (but not mechanism),that is used in [4], necessary for MANETs. Mase, et al. Expires March 21, 2008 [Page 4] Internet-Draft Framework September 2007 2. Terminology 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 [2], [3]. IP - Internet Protocol Version 4 or 6. node - a MANET router. 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/prefix - an IP-layer identifier for an interface. local address/prefix - a local address/prefix having scope that is limited to the MANET. tentative address/prefix - an address/prefix whose uniqueness in a MANET is being verified, prior to its assignment to an interface. A tentative address/prefix is not considered assigned to an interface in the usual sense. An interface discards received packets addressed to a tentative address/prefix, but accepts routing control packets related to MANET-wide Duplicate Address/ prefix Detection for the tentative address/prefix. address/prefix generation - Adress generation is a procedure for a node, that has currently no address/prefix, to obtain a tentative address/prefix in the MANET -either of its own accord or with support of other nodes. address/prefix conflict - When two nodes in the same MANET network share the same address/prefix or tentative address/prefix, the situation is described as an "Address/prefix Conflict". The nodes involved are "conflicting nodes" and their shared address/prefix is called the "conflicting address/prefix". Mase, et al. Expires March 21, 2008 [Page 5] Internet-Draft Framework September 2007 MANET-wide Duplicate Address/prefix Detection (DAD) - MANET-wide Duplicate address/prefix detection is the action of detecting address/prefix conflict in the MANET, the situation where some nodes are going to use or using the same address/prefix in the same MANET network. pre-service DAD - Pre-service DAD is the procedure to verify that a tentative address/prefix is out of address/prefix conflict with other MANET nodes. in-service DAD - In-service DAD is the procedure to continuously verify that a used address/prefix is out of address/prefix conflict with other MANET nodes. DAA - DAA is the procedure for a node, that detects duplicate address/prefix between other nodes, to advertise the duplicate address/prefix to all other nodes. autoconfiguration phase - The current autoconfiguration phase of the node, one of NO ADDRESS, ADVERTISING and NORMAL, which indicates what messages it should (or should not) generate and what processing it should (or should not) do. routing information contamination - Erroneous updates of routing information due to address/prefix conflict. 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 [1]. Mase, et al. Expires March 21, 2008 [Page 6] Internet-Draft Framework September 2007 3. Autoconfiguration framework 3.1. Overview We consider the local address/prefix autoconfiguration problem for MANETs. Specifically, we consider two cases. - In the first case, a node without a pre-assigned address/prefix acquires an address/prefix 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/prefix generation is needed, and a number of address/prefix generation methods have been proposed in literature. These are classified into stateful and stateless methods. In this case, a node first obtains an address/ prefix (tentative address/prefix) using a proper address/prefix generation method, - be that either a stateful or stateless method. It then verifies that the tentative address/prefix is not part of an address/prefix conflict with (not currently used by) other nodes. This procedure is termed "pre-service DAD" in this document. We MAY have pre-service DAD on a tentative address/prefix for suppressing occurrence of duplicate address/prefixes in the address/prefix assignment regardless of whether stateful or stateless methods is employed. Note that the necessity of pre-service DAD for MANETs with reactive routing protocol has been well known [8] and this method can be applied to MANETs with proactive routing protocol. In this case, however, existing nodes in the MANET must process control messages, specific for pre-service DAD, in addition to those for routing, giving rise to additional overhead. A pre-service DAD function SHOULD be embeded in routing control messages for MANETs, regardless of whether reactive or proactive routing protocol is employed to minimize the overhead [7]. In the second case, two or more already configured MANETs merge resulting address/prefix conflict. To cope with this situation, a node in an existing MANET MAY continuously verify possible address/ prefix conflict with other MANET nodes. This procedure is termed "in-service DAD" in this document. "Weak DAD" [14] and "passive DAD" [6] are examples of in-service DAD. When an address/prefix conflict is detected, a node with a duplicate address/prefix MUST obtain a new address/prefix to resolve the address/prefix conflict. This is accomplished using the address/prefix generation mentioned before. During duplicate address/prefix detection and resolution, some nodes may share the same address/prefix transiently and, therefore, routing information may not be correctly maintained. Specifically, a route entry may erroneously be updated based on control messages including Mase, et al. Expires March 21, 2008 [Page 7] Internet-Draft Framework September 2007 information from different nodes with the same duplicate address/ prefix. We call this problem "routing information contamination". We MAY have in-service DAD for detecting duplicate addresses/prefixes as well as for suppressing routing information contamination due to existence of duplicate addresses/prefixes. To systematically define pre-service DAD and in-service DAD, we use autoconfiguration phases that are common for both proactive and reactive routing protocols [7]. Each node is in one of the autoconfiguration phases at any time. Specific pre-service and in-service DAD algorithms are beyond the scope of this document. In either case, a node, that detects address/prefix conflict between other nodes, MAY advertise the detected duplicate address/prefix throughout the MANET. This is termed "Duplicate address/prefix advertisement" (DAA). As the results, a node with duplicate address/ prefix becomes aware of the address/prefix conflict and can start an action to resolve the conflict. Other nodes can take an action to suppress routing information contamination. DAA function should be embeded in routing control messages for MANETs regardless of whether reactive or proactive routing protocol is employed to minimize the overhead. In summary, the baselines of this framework are as follows: - Each node MAY perform "pre-service DAD" and "in-service DAD", before and after address/prefix assignment, respectively. - A node, that detects duplicate address/prefix between other nodes, MAY perform "DAA". - Pre-service and in-service DAD and DAA functions could be embedded in routing control messages regardless of whether reactive or proactive routing protocol is employed. With regard to the first baseline above, pre-service DAD is useful to suppress occurrences of an address/prefix conflict and in-service DAD is useful to suppress occurrences of address/prefix conflict and the resulting possible routing information contamination in case of network mergers. To define pre-service and in-service DAD systematically, we use the concept of autoconfiguration phases. The second baseline is useful to speed up duplicated address/prefix detection at the nodes with duplicate address/prefix. It is also useful for other nodes to keep its routing table correctly. The third baseline is useful to reduce pre-service DAD, in-service DAD and DAA overhead and to allow inter-working between nodes performing pre-service DAD and those performing in-service DAD when they coexist. Mase, et al. Expires March 21, 2008 [Page 8] Internet-Draft Framework September 2007 3.2. Autoconfiguration phases This section proposes a high-level conceptual view of generic MANET autoconfiguration. The different phases of the autoconfiguration process are abstracted by means of diagrams (Fig. 1 - 4), that propose different approaches to the process of autoconfiguration, which can be applied in different scenarios. The purpose of this framework is to derive a checklist of autoconfiguration functionalities, in order to build solutions taylored for different scenarios. The NO ADDRESS phase - In this phase a node does not have its own IP address/prefix. It does not participate in user data forwarding. If a routing protocol is in use in the MANET, the router does not process, generate or forward routing control messages generated by other nodes. At some point, the router MAY generate a (tentative) address/prefix by means of a given address/ prefix generation method. When it generates its address/prefix, the node should enter the ADVERTISING phase. The ADVERTISING phase - In this phase, a node does not participate in user data forwarding. If a routing protocol is in use in the MANET, the router does not forward routing control messages generated by other routers. In this phase, the router MAY perform pre-service DAD by means of a given mechanism (for instance by using specific control signalling, that could be embeded in the ad hoc routing signalling in use). If pre-service DAD is used, and the node detects that its tentative address/prefix creates a conflict with other MANET nodes, it should re-enters the NO ADDRESS phase. Else, if pre-service DAD completes without any address/prefix conflict being detected, or if pre-service DAD is not required, the router should enter the NORMAL phase. Note that if pre- service DAD is used, the ADVERTISING phase MAY have incremental substates in order to reduce the risks of routing table pollution with duplicate addresses/prefixes. In the LOCAL ADVERTISEMENT phase, pre- service DAD control signalling reaches only a TTL-limited neighborhood, whereas in the GLOBAL ADVERTISEMENT phase, pre- service DAD control signalling reaches the whole MANET. The NORMAL phase - In this phase, the node participates in IP communication normally. If a routing protocol is in use in the MANET, the node MAY process, generate or forward routing control messages as specified by the routing protocol in use, and MAY generate or forward user data. A node in this phase MAY perform in-service DAD by means of a given mechanism (for instance by using specific control messages that can be embeded in the routing control messages). If in-service DAD is used and if the node Mase, et al. Expires March 21, 2008 [Page 9] Internet-Draft Framework September 2007 detects an address/prefix conflict that forces it to acquire a new address/prefix to resolve this conflict, the router should return to the NO ADDRESS phase. Note that the phases in this model are cyclic, and that a router can pop up in the MANET in any phase. For instance, a router that beneficiated from appropriate static preconfiguration MAY start directly in the NORMAL phase. (Address/prefix generation) Duplicate (In-service DAD) +--------------+ address/prefix +--------------+ | NO ADDRESS | detected | NORMAL | +----------| phase |<-------------------| phase |<--+ | +--------------+ +--------------+ | | ^ | | | Duplicate address/prefix | | (Tentative) | detected Address/prefix | | address/prefix +---------+ checked | | generated | | | +--------------------------------------------------------+ | | | ADVERTISING phase | | | | | | | | +--------------+ +-------------+ | | | | | LOCAL AD. | | GLOBAL AD. | | | +----| | phase |------------------| phase | |---+ | +--------------+ +-------------+ | +--------------------------------------------------------+ (Pre-service DAD) Fig. 1 Phases model with full DAD. This conceptual framework reveals three specific potential aspects of the MANET autoconfiguration problem: - The (tentative) IP addresses/prefixes generation and assignment aspect. - The pre-service DAD aspect, to somehow ensure a reasonalble belief in the fact that an address/prefix about to be assigned does not create a conflict. - The in-service DAD aspect, to deal with conflicts that are detected between already assigned addresses/prefixes. Mase, et al. Expires March 21, 2008 [Page 10] Internet-Draft Framework September 2007 +--------------+ +--------------+ | NO ADDRESS | | NORMAL | | phase |------------------->| phase | +--------------+ Address/prefix +--------------+ Generation Fig. 2 Phases model without DAD. Pre-service DAD +----------------------------------+ | | | | | +--------------+ +---------------+ +--------------+ | | NO ADDRESS | | ADVERTISING | | NORMAL | +-->| phase |----->| phase |----->| phase | +--------------+ +---------------+ +--------------+ Fig. 3 Phases model without in-service DAD. In-service DAD +----------------------------------------------------------+ | | | | | +--------------+ +--------------+ | | | NO ADDRESS | | NORMAL | | +--->| phase |------------------>| phase |---+ +--------------+ +--------------+ Fig. 4 Phases model without pre-service DAD. Mase, et al. Expires March 21, 2008 [Page 11] Internet-Draft Framework September 2007 4. IANA Considerations This document has no actions for IANA. Mase, et al. Expires March 21, 2008 [Page 12] Internet-Draft Framework September 2007 5. Security Considerations This document presents only framwork of autoconfiguration for MANETs and does therefore not specify any special security measure. However, introduction of autoconfiguration phases may be useful to realize some security measures. For example, node authentification may be done during the ADVERTISING phase. Mase, et al. Expires March 21, 2008 [Page 13] Internet-Draft Framework September 2007 6. 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), Shubranshu Singth (Samsung AIT), Simone Ruffino (Telecom Italia) and Kilian Weniger (Panasonic R&D Center) for intense technical discussions, early reviews and comments on this work. Mase, et al. Expires March 21, 2008 [Page 14] Internet-Draft Framework September 2007 7. References [1] Brander, S. "Key words for use in RFCs to Indicate Requirement Levels," RFC2119, Mar. 1997. [2] Narten, T., E. Nordmark and W. Simpson,"Neighbor Discovery for IP Version 6 (IPv6)," RFC2461, Dec. 1998. [3] Thomson, S. and T. Narten,"IPv6 Stateless Address Autoconfiguration," RFC2462, Dec. 1998. [4] Cheshire, S., B. Aboba and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses," RFC3927, May 2005. [5] Baccelli, E., K.Mase, S. Ruffino, and S.Singh, "Address Autoconfiguration for MANET: Terminology and Problem Statement," draft-ietf-autoconf-statement-00 (work in progress), June 2007. [6] Weniger, K., "PACMAN: Passive Autoconfiguration for Mobile Ad Hoc Networks," IEEE Journal on Selected Areas in Communications (JSAC), Vol. 23, No. 3, 2005. [7] Mase, K. and C. Adjih, "No Ovrhead Autoconfiguration OLSR", draft-mase-manet-atuoconf-noaolsr-00 (work in progress), May 2005. [8] 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. [9] Mohsin, M. and R. Prakash, "IP Address Assignment in a Mobile Ad Hoc Network," MILCOM 2002. [10] 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. [11] 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. [12] 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. [13] Zhou, H., L. M. Ni, and M. W. Mutka, "Prophet Address Allocation for Large Scale MANETs," INFOCOM 2003. Mase, et al. Expires March 21, 2008 [Page 15] Internet-Draft Framework September 2007 [14] 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. [15] Jeong, J., "Ad Hoc IP Address Autoconfiguration," Internet Draft, draft-jeong-adhoc-ip-addr-autoconf-00.txt, Nov. 2003, work in progress. [16] Mase, K., S. Narita, and S. Yoshida, "Efficient IP address Assignment in Mobile Ad Hoc Networks," pp. 504-508, WPMC, 2003. [17] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003. [18] Perkins, C. E., Belding-Royer, E., and S. Das, "Ad hoc On- Demand Distance Vector (AODV) Routing", RFC 3561, July 2003. [19] 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. [20] Weniger, K., "Passive Duplicate Address Detection in Mobile Ad hoc Networks", In Proc. IEEE WCNC 2003, pp. 1504-1509, March 2003. [21] 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. [22] 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, et al. Expires March 21, 2008 [Page 16] Internet-Draft Framework September 2007 Authors' Addresses Kenichi Mase 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 INRIA Domaine de Voluceau, Rocquencourt, France Phone: +33 1 3963 5215 Email: cedric.adjih@inria.fr Emmanuel Baccelli INRIA Phone: +33 1 6933 5511 Email: cedric.adjih@inria.fr Mase, et al. Expires March 21, 2008 [Page 17] Internet-Draft Framework September 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Mase, et al. Expires March 21, 2008 [Page 18]