MANET Autoconfiguration (Autoconf) E. Baccelli (Ed.) Internet-Draft HITACHI Labs Europe Expires: January 8, 2007 July 7, 2006 MANET IP Address Autoconfiguration: 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 8, 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 requirements for its design. Contributors C. Adjih, T. Clausen, K. Mase, C. Perkins, P. Ruiz, S. Ruffino, S. Singh, D. Thaler contributed to this document. Their names are not Baccelli (Ed.) Expires January 8, 2007 [Page 1] Internet-Draft MANET Autoconf Problem Statement July 2006 included in the authors' section due to the RFC Editor's limit of 5 names. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Standalone MANET . . . . . . . . . . . . . . . . . . . . . 6 3.2. MANET Connected to an External Network . . . . . . . . . . 6 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Baccelli (Ed.) Expires January 8, 2007 [Page 2] Internet-Draft MANET Autoconf Problem Statement July 2006 1. Introduction MANETs (mobile ad hoc networks, see RFC 2501) are networks composed of mobile devices called nodes, communicating over wireless media, which dynamically self-organize multi-hop communication between each other. Each node forms the network by generating and/or relaying control traffic, and may relay user traffic (behaving like a router). Each node may also use the network by generating user traffic (behaving like a host). This hybrid behavior is a cheap solution to extend user access to a pre-established network infrastructure. This characteristic also enables user communications to bypass access to the infrastructure when an alternative path is available through peer users' relaying. A mobile ad hoc network may thus function regardless of its connection or not to the infrastructure. More precisely, a MANET may either be: - disconnected from the fixed infrastructure, and then called a standalone MANET - connected to the fixed infrastructure, with only one gateway to fixed infrastructure, and then called a stub MANET - connected to the fixed infrastructure, with multiple gateways to fixed infrastructure, and then called a multi-homed MANET In the case of MANETs over IP an issue arises prior to self- organization for user communication (i.e. prior to participation in the ad hoc routing protocol in use). This issue concerns dynamic IP address assignment to mobile ad hoc nodes: indeed, traditional IP address assignment solutions are not adapted to MANET characteristics, and a new solution is therefore needed. The following details this problem, and provides requirements and guidelines for the solution to be designed. Baccelli (Ed.) Expires January 8, 2007 [Page 3] Internet-Draft MANET Autoconf Problem Statement July 2006 2. Terminology 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 RFC2119. In addition, 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. MANET 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. Standalone ad hoc network - An independent ad hoc network which has no connectivity, either direct of via Internet gateways, to any other IP networks such as the Internet. Stub ad hoc network - An ad hoc network which has connectivity to the Internet via a single Internet gateway. Multi-homed ad hoc network - An ad hoc network which has connectivity to the Internet via more than two different Internet gateways. 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. Baccelli (Ed.) Expires January 8, 2007 [Page 4] Internet-Draft MANET Autoconf Problem Statement July 2006 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.) Expires January 8, 2007 [Page 5] Internet-Draft MANET Autoconf Problem Statement July 2006 3. Applicability Automatic configuration of IP addresses of MANET nodes (AUTOCONF) is deemed necessary in a number of deployment scenarios. In this section, we describe use cases in which AUTOCONF can be applied. 3.1. Standalone MANET In this kind of scenario, the MANET is not connected to an external network: all traffic is generated by MANET nodes and destined to MANET 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). MANET nodes need to automatically configure at least one MANET-local unique IPv6 address, to bootstrap the routing protocol; address uniqueness ensures that the routing protocol is able to find correct routes towards given destinations, and that routing table are not polluted with confusing entries. 3.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 Internet hosts. Multiple gateways provide more reliability and fault tolerance to the entire MANET and enable load balancing of data flows to/from the Internet. Typically, Internet Gateways are managed by an administrative entity (i.e. a network operator or service provider). However they can also be "opportunistic" and non-managed. Configuration mechanism must provide an address to nodes and gateways, to be used for communications intra-MANET, as well as one or more global addresses, to be used for communications with Internet hosts outside the MANET. Gateways typically manage topologically correct IPv6 prefixes, that can be used to configure global addresses in the MANET. Gateway prefix usage can be configured statically, or dynamically (e.g. using DHCPv6 with Prefix Delegation Option such as specified in RFC3633). Gateways should also play a role in other configuration procedures, such as Duplicated Address Detection. An example of such a scenario is a mesh network, which is typically used to build community and urban network (e.g. RoofNet) to provide Internet public access for outdoor mobile users. Mesh networks are typically realized by deploying fixed Access Points, acting as Internet gateways, scattered over a geographical area. The ad hoc Baccelli (Ed.) Expires January 8, 2007 [Page 6] Internet-Draft MANET Autoconf Problem Statement July 2006 network can include the Access Points only, or both mobile users and Access Points, depending on the type of deployment in use. AUTOCONF mechanism are needed for each type of deployment to enable self- configuration nodes and Access Points. Another example is the coverage extension of fixed wide-area wireless networks: such a scenario may include the use of mobile gateways, such as one or more mobile nodes in the MANET that are connected to the Internet through an alternative technology, such as a cellular WAN interface (e.g. UMTS), or a broadband wireless MAN interface (e.g. WiMAx). These nodes can either be managed by an administrative entity (i.e. a network operator or service provider), or be unmanaged and determined in an "opportunistic" fashion. Passengers in a train may for example form a MANET that is connected to the Internet either via specific node(s) on the vehicule (managed by the train company) or via occasional passenger(s) that share their simultaneous connection to the MANET and to the Internet. The number and the position of gateways in this case is then dynamic and can cause frequent re-routing of uplink data bursts, and/or loss of connectivity, due to MANET partitioning. Autoconfiguration mechanism 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. Configuration procedures, especially address uniqeness check, could have very tight time constraints, requiring to complete with low latencies. Baccelli (Ed.) Expires January 8, 2007 [Page 7] Internet-Draft MANET Autoconf Problem Statement July 2006 4. Problem Statement Traditional dynamic IP address assignment solutions, such as RFC 2462, 3315 and 2461, are not applicable to MANETs due to the characteristics of ad hoc connectivity. 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 this case, a broadcast must be somehow relayed several times in order to reach all the nodes participating in the MANET. In that respect, it is worth noting that IPv6 does not currently specify an address scope that is applicable for MANET scope. Another characteristic of MANETs is that a significant proportion of the nodes that constitute the MANET may be mobile. Therefore nodes in a given mobile ad hoc network are likely to appear and disappear, and the network topology can change rather dynamically compared to traditional networks. In particular, phenomenons such as MANET paritionning (i.e. a MANET suddenly 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. Moreover, node mobility introduces a further issue in that: 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. It is also worth noting that, in the case where multiple gateways are available in the MANET, specific problems arise : o 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 univocally 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. Baccelli (Ed.) Expires January 8, 2007 [Page 8] Internet-Draft MANET Autoconf Problem Statement July 2006 o Additional problems come from issues with current IPv6 specifications. For example, the strict application of [ADDRCONF] 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.) Expires January 8, 2007 [Page 9] Internet-Draft MANET Autoconf Problem Statement July 2006 5. Framework 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. A solution must achieve its task with minimal overhead, due to scarse bandwidth, and minimal delay, due to the dynamicity of the topology. Moreover, specific mechanisms (i.e. DAD mechanisms, for Duplicate Address Detection) must be used in order to detect and resolve potential IP address conflicts. DAD mechanisms can be split into two distinct categories: (i) Pre-service DAD, which aims at verifying that a tentative new IP address assignment will not create a conflict with other MANET devices. (ii) In-service DAD, which aims at continuously checking that an IP address already in use has not become duplicated in the MANET. Basically, with regards to IP addressing, a device may be into either of 3 different states, as shown in Fig 1. : NO_ADDRESS_STATE - In this state a device does not have its own IP address, and it MUST NOT process, generate or forward routing control messages generated by other devices. It MUST NOT participate in user data forwarding. It MAY generate a tentative address by means of a pre-determined address generation method. When it generates its tentative address, the device enters the ADVERTISING_STATE. ADVERTISING_STATE - In this state, a device MUST NOT forward routing control messages generated by other nodes. It MUST NOT participate in user data forwarding. It SHOULD perform pre- service MANET-DAD using specific control signalling, that can be embeded in the ad hoc routing signalling in use. If the device detects that its tentative address creates a conflict with other MANET devices, it MUST re-enter NO_ADDRESS_STATE. Else, if pre- service MANET-DAD completes without any address conflict being detected, the node enters the NORMAL_STATE (note that ADVERTISING STATE may have substates with regards to the scope of advertisement, such as LOCAL_AD_state and GLOBAL_AD_state). Baccelli (Ed.) Expires January 8, 2007 [Page 10] Internet-Draft MANET Autoconf Problem Statement July 2006 NORMAL_STATE - In this state, the device processes, generates or forwards routing control messages generated by other devices, as specified by the routing protocol(s) in use. It also participates in user data forwarding. A device in this state SHOULD perform in-service MANET-DAD, using control messages that can be embeded in the routing control messages. If the device has to acquire a new address, it MUST return the NO_ADDRESS_STATE. (Address generation) (In-service DAD) +--------------+ Duplicate address +--------------+ | NO_ADDRESS | detected | NORMAL | +----------| _STATE |<-------------------| _STATE |<--+ | +--------------+ +--------------+ | | ^ Full routing | | | Duplicate address | |Tentative address | detected | | generated +--------+ Time-out| | | | | +--------------------------------------------------------+ | | | ADVERTISING_STATE | | | | | | | | +--------------+ +-------------+ | | | | | LOCAL_AD | Time-out | GLOBAL_AD | | | +--->| | _STATE |<-----------------| _STATE | |---+ | +--------------+ +-------------+ | +--------------------------------------------------------+ (Pre-service DAD, no forwarding) Fig. 1 Autoconfiguration state transition diagram. The following lists the building blocks composing a solution to IP address autoconfiguration for MANETs, according to the finite state machine described in Fig. 1: - A mechanism is needed for tentative IP addresses generation and assignment, for the transition from NO_ADDRESS_STATE to ADVERTISING_STATE. - A mechanism is needed to provide pre-service DAD, for the transition from ADVERTISING_STATE back to NO_ADDRESS_STATE, or from ADVERTISING_STATE to NORMAL_STATE. - A mechanism is needed to provide in-service DAD, to resolve address conflicts that are detected, and possibly transition from Baccelli (Ed.) Expires January 8, 2007 [Page 11] Internet-Draft MANET Autoconf Problem Statement July 2006 NORMAL_STATE back to NO_ADDRESS_STATE. - A mechanism is needed to establish when a new address should be sought for due to node mobility, and thus decide to transition from NORMAL_STATE back to NO_ADDRESS_STATE. Baccelli (Ed.) Expires January 8, 2007 [Page 12] Internet-Draft MANET Autoconf Problem Statement July 2006 6. Security Considerations TBD Baccelli (Ed.) Expires January 8, 2007 [Page 13] 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.) Expires January 8, 2007 [Page 14] Internet-Draft MANET Autoconf Problem Statement July 2006 Author's Address Emmanuel Baccelli HITACHI Labs Europe Phone: +33 1 69 33 55 11 Email: baccelli@eurecom.fr Baccelli (Ed.) Expires January 8, 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.) Expires January 8, 2007 [Page 16]