MANET Autoconfiguration (Autoconf) E. Baccelli (Ed.) Internet-Draft INRIA Expires: January 25, 2007 K. Mase Niigata University S. Ruffino Telecom Italia S. Singh Samsung July 24, 2006 Address Autoconfiguration for MANET: Terminology and Problem Statement draft-baccelli-autoconf-statement-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 January 25, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Traditional dynamic IP address assignment solutions are not adapted to mobile ad hoc networks. This document elaborates on this problem, states the need for a new solution, and provides guidelines and Baccelli (Ed.), et al. Expires January 25, 2007 [Page 1] Internet-Draft MANET Autoconf Problem Statement July 2006 requirements for its design. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Overview of the Problem . . . . . . . . . . . . . . . . . 3 1.2. Specification of Requirements . . . . . . . . . . . . . . 3 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 5 2.1. Standalone MANET . . . . . . . . . . . . . . . . . . . . . 5 2.2. MANET Connected to an External Network . . . . . . . . . . 5 3. Deployment Scenarios Selection . . . . . . . . . . . . . . . . 6 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Specific Broacast Characteristics . . . . . . . . . . . . 7 4.2. Dynamic Topology . . . . . . . . . . . . . . . . . . . . . 7 4.3. Locally Unique Addresses, Globally Unique Addresses . . . 8 4.4. Multiple Gateways . . . . . . . . . . . . . . . . . . . . 8 5. Solution Guidelines . . . . . . . . . . . . . . . . . . . . . 9 5.1. Solution Model . . . . . . . . . . . . . . . . . . . . . . 9 5.2. General Requirements . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Baccelli (Ed.), et al. Expires January 25, 2007 [Page 2] Internet-Draft MANET Autoconf Problem Statement July 2006 1. Introduction Mobile ad hoc networks (i.e. MANETs, refer to RFC 2501) are networks composed of mobile devices also called nodes, that communicate over wireless media, and which dynamically self-organize multi-hop communication between each other. Each node may generate and forwards control traffic, and forward user traffic (thus potentially behaving like a router). Each node may also use the network by generating user traffic (and thus potentially behaving like a host). Some mobile ad hoc network may function regardless of the availability of a connection to the infrastructure (i.e. the Internet). More precisely, a MANET may either be disconnected from the fixed IP infrastructure (then called a standalone MANET), or connected to the fixed IP infrastructure (through one or more gateways). 1.1. Overview of the Problem Prior to participation in IP communication, each node's interface on a MANET that does not beneficiate from appropriate static configuration needs to be automatically assigned at least one IP address, that SHOULD be unique (i) locally, for communication inside the MANET, or (ii) globally, for communication accross the Internet. However, standard automatic IP address assignment solutions do not work "as-is" on MANETs due to ad hoc networks' characteristics, and new mechanisms are therefore needed. The goal of this document is to detail these problems, and to provide guidelines and requirements for solutions to be designed. 1.2. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.3. Terminology In addition to the specific wording described in the previous section, this document uses the following terminology : MANET Node - A device with one or more wireless interfaces and associated IP address(es) which is used by the MANET routing protocol in use. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 3] Internet-Draft MANET Autoconf Problem Statement July 2006 Local address - An IP address configured on a MANET node and valid for communication among MANET nodes that are part of the same ad hoc network. Nodes MUST NOT communicate with other nodes outside the MANET using this address. Global address - An IP address configured on a MANET node and valid for communication with nodes in the Internet, as well as internally within the MANET. Internet gateway - An edge node connected to MANET as well as to the Internet and capable of providing bidirectional connectivity between the Internet and MANET . These gateways are expected to provide topologically correct IPv6 prefixes. Internet gateways mostly run ad hoc routing protocols, but they can also run infrastructure network protocols (e.g. OSPF). Duplicate Address Detection (DAD) - The process by which a node confirms the uniqueness of an address it wishes to configure or has already configured. A node already equipped with an IP address participates in DAD in order to protect its IP address from being used by another node. Pre-service MANET-DAD - The process verifying that a tentative new IP address assignment will not create a conflict with other MANET devices. In-service MANET-DAD - The process of continuously checking that an IP address already in use has not become duplicated in the MANET. Standalone MANET - An independent ad hoc network which has no connectivity, either direct of via Internet gateways, to any other IP networks such as the Internet. Network merger - The process by which two or more ad hoc networks, previously disjoint, get connected. In general, network merger happens as a consequence of node mobility and/or wireless link environment. Network partitioning - The process by which an ad hoc network splits into two or more disconnected ad hoc networks. In general, this proccess happens as a consequence of node mobility and/or wireless link environment. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 4] Internet-Draft MANET Autoconf Problem Statement July 2006 2. Deployment Scenarios Automatic configuration of IP addresses of MANET nodes (AUTOCONF) may be necessary in a number of deployment scenarios. In this section, we outline the use cases that concern and reveal problems related to the Autoconfiguration of MANET nodes. 2.1. Standalone MANET In this kind of scenario, the MANET is not connected to any external network: all traffic is generated by MANET nodes and destined to nodes in the same MANET. Nodes joining a standalone MANET can either (i) have no previous configuration, or (ii) already have one or more MANET local and/or global addresses, statically or dynamically pre- configured, to be used for IP communication. Due to partitions and mergers, standalone MANETs can often be composed with both kinds of nodes. Typical applications of this scenario include private or temporary networks, set-up in areas where neither wireless coverage nor network infrastructure exist (e.g. emergency networks for disaster recovery, or conference-room networks). 2.2. MANET Connected to an External Network In this scenario, the MANET is connected to an external network, (e.g. the Internet), by means of one or more gateways. MANET nodes can generate traffic directed to remote hosts accross the Internet. As in Section 2.1, nodes in a connected MANET could either (i) already own a global IP address, which could be used for external traffic, or (ii) have no previous configuration. Examples include public wireless networks of scattered fixed WLAN Access Points participating in the MANET of mobile users, and acting as Internet Gateways. Another example of such a scenario is the coverage extension of a fixed wide-area wireless network, where one or more mobile nodes in the MANET are connected to the Internet through technologies such as UMTS or WiMAX. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 5] Internet-Draft MANET Autoconf Problem Statement July 2006 3. Deployment Scenarios Selection TBD Baccelli (Ed.), et al. Expires January 25, 2007 [Page 6] Internet-Draft MANET Autoconf Problem Statement July 2006 4. Problem Statement MANET nodes that do not beneficiate from appropriate static IP address configuration may need to automatically configure at least one unique local IPv6 address, in order to enable IP communication within the MANET. To communicate with hosts across the Internet, configuration mechanism may also need to provide one or more global IPv6 addresses. Internet Gateways typically manage topologically correct IPv6 prefixes that can be used to configure global address. They are usually managed by an administrative entity (i.e. a network operator or service provider), however they can also be opportunistic and unmanaged. Internet Gateways are typically fixed, but may also be mobile. Their presence in the MANET may be intermittent (the number of gateways may vary), and thus the availability of an Internet connection in the MANET may also be intermittent. 4.1. Specific Broacast Characteristics Traditional dynamic IP address assignment solutions, such as RFC 2462, 3315 and 2461, do not work as-is in MANETs due to these networks' unique properties, as elaborated in the following sections. These solutions assume that a broadcast direclty reaches every device on the network, whereas it is generally not the case in MANETs. Indeed, some nodes in the MANET will typically be indirectly connected to the source of the broadcast, through several intermediate peer mobile ad hoc nodes. In that respect, it is worth noting that IPv6 does not currently specify an address scope that is applicable for MANET scope. 4.2. Dynamic Topology A significant proportion of the nodes in the MANET may be mobile with wireless interface(s), leading to ever changing neighbors and neighbor sets for most MANET nodes. Therefore network topology may change rather dynamically compared to traditional networks. In particular, phenomena such as MANET paritionning (i.e. a MANET separating into two or more disconnected MANETs) and MANET merging (i.e. two or more disconnected MANETs suddenly being connected) are potential events that may greatly disrupt the uniqueness of IP addresses in use. For instance, a standalone MANET A may feature nodes that use IP addresses that are locally unique within MANET A, but this uniqueness is not guaranteed anymore if MANET A merges at some point with another MANET B. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 7] Internet-Draft MANET Autoconf Problem Statement July 2006 4.3. Locally Unique Addresses, Globally Unique Addresses Moreover, even if a node uses an IP address that is locally unique within its MANET, this address may not be fit for Internet communication. Indeed, in order to be able to communicate with outside the MANET (i.e. the Internet), a node must use an IP address that must be both globally unique, as well as topologically correct, reflecting it's current location. 4.4. Multiple Gateways In the case where multiple gateways are available in the MANET, specific problems arise. One problem is the way in which global prefixes are managed within the MANET. If *one* prefix is used for the whole MANET, partitioning of the MANET may invalid routes in the Internet towards MANET nodes. On the other hand, use of *multiple* network prefixes guarantees traffic is unambiguously routed towards the gateway owning one particular prefix, but asymmetry in the nodes' choice of ingress/egress gateway can lead to non-optimal paths followed by inbound/outbound data traffic. Additional problems come from issues with current IPv6 specifications. For example, the strict application of RFC2462 may lead to check every IPv6 unicast for uniqueness : in a multiple-gateway / multiple-prefixes MANET, this could bring to a large amount of control signalling, due to frequent reconfiguration. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 8] Internet-Draft MANET Autoconf Problem Statement July 2006 5. Solution Guidelines 5.1. Solution Model This section proposes a high-level conceptual view of generic MANET autoconfiguration. The different phases of the autoconfiguration process are abstracted by means of a diagram (see Fig. 1), that may serve as conceptual framework of the issues that nodes have to solve. However, note that solutions do not have to follow this framework. The purpose of this framework is merely to derive a checklist of autoconfiguration functionalities, in order to build solutions taylored for different scenarios. Basically, with regards to IP addressing, a device may find itself into the 3 different phases depicted in Fig 1. : The NO ADDRESS phase - In this phase a device does not have its own IP address. It does not participate in user data forwarding. If a routing protocol is in use in the MANET, the node does not process, generate or forward routing control messages generated by other devices. At some point, the node may generate a (tentative) address by means of a given address generation method. When it generates its address, the device should enter the ADVERTISING phase. The ADVERTISING phase - In this phase, a device does not participate in user data forwarding. If a routing protocol in in use in the MANET, the node does not forward routing control messages generated by other nodes. In this phase, the node may perform pre-service MANET-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 MANET-DAD is used, and the device detects that its tentative address creates a conflict with other MANET devices, it should re-enters the NO ADDRESS phase. Else, if pre-service MANET-DAD completes without any address conflict being detected, or if pre-service DAD is not required, the node should enter the NORMAL phase. Note that if pre-service MANET-DAD is used, the ADVERTISING phase may have incremental substates in order to reduce the risks of routing table pollution with duplicate addresses. In the LOCAL ADVERTISEMENT phase, pre-service MANET-DAD control signalling reaches only a TTL-limited neighborhood, whereas in the GLOBAL ADVERTISEMENT phase, pre-service MANET-DAD control signalling reaches the whole MANET. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 9] Internet-Draft MANET Autoconf Problem Statement July 2006 The NORMAL phase - In this phase, the device participates in IP communication normally. If a routing protocol is in use in the MANET, the device may process, generate or forward routing control messages as specified by the routing protocol in use, and may generate or forward user data. A device in this phase may perform in-service MANET-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 MANET-DAD is used and if the device detects an address conflict that forces it to acquire a new address to resolve this conflict, the node should return to the NO ADDRESS phase. Note that the phases in this model are cyclic, and that a node can pop up in the MANET in any phase. For instance, a node that beneficiated from appropriate static preconfiguration may start directly in the NORMAL phase. (Address generation) (In-service MANET-DAD) +--------------+ Duplicate address +--------------+ | NO ADDRESS | detected | NORMAL | +----------| phase |<-------------------| phase |<--+ | +--------------+ +--------------+ | | ^ | | | Duplicate address | |(Tentative) address | detected Address | | generated +--------+ checked | | | | | +--------------------------------------------------------+ | | | ADVERTISING phase | | | | | | | | +--------------+ +-------------+ | | | | | LOCAL AD. | | GLOBAL AD. | | | +--->| | phase |----------------->| phase | |---+ | +--------------+ +-------------+ | +--------------------------------------------------------+ (Pre-service MANET-DAD) Fig. 1 Generic autoconfiguration phases. This conceptual framework reveals three specific potential aspects of the problem, which solutions MUST be designed take into account: - The (tentative) IP addresses generation and assignment aspect. - The pre-service DAD aspect, to somehow ensure a reasonalble belief in the fact that an address about to be assigned does not Baccelli (Ed.), et al. Expires January 25, 2007 [Page 10] Internet-Draft MANET Autoconf Problem Statement July 2006 create a conflict. - The in-service DAD aspect, to deal with conflicts that are detected between already assigned addresses. 5.2. General Requirements A solution for IP address autoconfiguration for MANETs is needed for mobile ad hoc node to acquire a correct IP address prior to their full participation in the mobile ad hoc routing protocol(s) in use. Such a solution must address the distributed, multi-hop nature of mobile ad hoc networks. Autoconfiguration mechanisms must be able to follow changes in the MANET and react to gateway connectivity loss, or to the event of new gateways becoming available, (re)configuring addresses accordingly. A solution must achieve its task with minimal overhead, due to scarse bandwidth, and minimal delay, due to the dynamicity of the topology. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 11] Internet-Draft MANET Autoconf Problem Statement July 2006 6. Security Considerations Address configuration in MANET could be prone to security attacks, as in other type of IPv6 networks. Security threats to IPv6 neighbor discovery are discussed in RFC 3756: in particular, analysis includes trust model and threats for a specific ad hoc network scenario, where all the nodes share a common link (i.e. they are one hop away from each other, full-meshed connectivity is available). Although the document does not explicitly address MANETs, where nodes can be multiple hop away from each other, the trust model it provides could be valid also in the context of AUTOCONF. It is also worth noting that, in case of MANET connected to the Internet, other threats defined in RFC3756 could apply here, e.g. attacks involving routers and DoS attacks on Duplicate Address Detection procedures. Analysis has to be further extended to include threats, specific to multi-hop networks and, in particular, related to the address configuration process: security issues of routing protocol operations (e.g. how to secure routing protocol messages) are out of scope of AUTOCONF WG. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 12] Internet-Draft MANET Autoconf Problem Statement July 2006 7. IANA Considerations This document does currently not specify IANA considerations. 8. References [1] Macker, J. and S. Corson, "MANET Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999. [2] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IPv6", RFC 2461, December 1998. [3] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6", RFC 3315, July 2003. [4] Narten, T. and S. Thomson, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 13] Internet-Draft MANET Autoconf Problem Statement July 2006 Contributors This document is the result of joint efforts, including those of the following contributers, listed in alphabetical order: C. Adjih (INRIA), T. Clausen (Ecole Polytechnique), C. Perkins (Nokia), P. Ruiz (University of Murcia), P. Stupar (Telecom Italia), D. Thaler (Microsoft). Baccelli (Ed.), et al. Expires January 25, 2007 [Page 14] Internet-Draft MANET Autoconf Problem Statement July 2006 Authors' Addresses Emmanuel Baccelli INRIA Phone: +33 1 69 33 55 11 Email: Emmanuel.Baccelli@inria.fr Kenichi Mase Niigata University Phone: +81 25 262 7446 Email: Mase@ie.niigata-u.ac.jp Simone Ruffino Telecom Italia Phone: +39 011 228 7566 Email: Simone.Ruffino@telecomitalia.it Shubhranshu Singh Samsung Phone: +82 31 280 9569 Email: Shubranshu@gmail.com Baccelli (Ed.), et al. Expires January 25, 2007 [Page 15] Internet-Draft MANET Autoconf Problem Statement July 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 16]