AUTOCONF Working Group C. Bernardos Internet-Draft UC3M Intended status: Informational R. in 't Velt Expires: April 29, 2010 TNO October 26, 2009 Addressing Model for Router Interfaces in Ad Hoc Networks draft-bernardos-autoconf-addressing-model-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 April 29, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document describes a practical IP addressing model for interfaces that take part in router-to-router communications in ad Bernardos & in 't Velt Expires April 29, 2010 [Page 1] Internet-Draft autoconf addressing model October 2009 hoc networks. Requirements Language 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 RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Addressing model . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. IPv4/IPv6 practical addressing model . . . . . . . . . . . 5 3.3. DAD considerations . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Bernardos & in 't Velt Expires April 29, 2010 [Page 2] Internet-Draft autoconf addressing model October 2009 1. Introduction In order to communicate among themselves, ad hoc routers [RFC2501] need to configure their network interface(s) with addresses that are valid within an ad hoc network. Ad hoc routers may also need to configure globally routable addresses, in order to communicate with devices on the Internet. From the IP layer perspective, an ad hoc network presents itself as a L3 multi-hop network formed over a collection of links. This document describes a practical addressing model for ad hoc networks. It is required that a such model does not cause problems for ad hoc-unaware parts of the system, such as standard applications running on an ad hoc router or regular Internet nodes attached to the ad hoc routers. 2. Terminology Readers are expected to be familiar with all the terms defined in the RFC 2501 [RFC2501]. In addition the document makes use of the following definitions: Wireless Link According to [I-D.iab-ip-model-evolution], a "link" in the IP service model refers to the topological area within which a packet with an IPv4 TTL or IPv6 Hop Limit of 1 can be delivered. That is, where no IP-layer forwarding (which entails a TTL/Hop Limit decrement) occurs between two nodes. A "wireless link" can be defined similarly, with the topological area in this case given by the radio-range coverage of the wireless technology used. Due to the nature of the wireless medium, links are intermittent, and potentially short-lived. Node movement exacerbates these characteristics. MANET interface Any interface over which a MANET protocol is run. MANET domain A MANET domain is delimited by a set of MANET routers that run a common MANET routing protocol and corresponds to its routing domain. Attached MANET (domain) Bernardos & in 't Velt Expires April 29, 2010 [Page 3] Internet-Draft autoconf addressing model October 2009 A MANET domain attached to an infrastructure based network (e.g., the Internet). The MANET interfaces of routers of an attached MANET should be configured with unique global IP addresses, if these addresses are somehow exposed beyond the MANET domain. By infrastructure network, we refer to any existing network which presents a certain hierarchical organisation (e.g., different subnets) and that is delegated a certain set of IP addresses/ prefixes. Non-overlapping prefix Two IP prefixes p::/l_p and q::/l_q are non-overlapping if and only if there is no IP address p::a/l_p configured from p::/l_p that also belongs to q::/l_q, and the other way around. For example, 2001:DB8:1:1::/64 and 2001:DB8:1:2::/64 are non- overlapping prefixes, while 2001:DB8:1::/48 and 2001:DB8:1:2::/64 are not. 3. Addressing model This section describes a practical IPv4/IPv6 addressing model for ad hoc networks. We first define the scope of the addressing model, then propose how to practically configure IP on MANET interfaces. Finally, we provide some considerations on address uniqueness. 3.1. Scope This document describes an addressing model for MANET interfaces. Regular (non-MANET) interfaces are not in the scope of the present document, as they are expected to be configured using standard mechanisms (such as SLAAC [RFC4862] or DHCP [RFC2131], [RFC3315]). Note, that MANET routers may need to acquire IP address prefixes to facilitate the configuration of IP addresses on nodes reachable via non-MANET interfaces. How to do this is a topic that is also outside the scope of this document. This document does not place restrictions on the use of IP addresses configured on MANET interfaces. We assume that these IP addresses are used by MANET routing protocols. We also assume that, once MANET routing protocols have started to populate the Forwarding Information Bases (FIB) of routers with routing entries, these IP addresses will play a role in the forwarding of user data packets. In particular, it is assumed that these addresses will be found as next-hop addresses in the routing tables of MANET routers. The forwarding of user data in many cases includes the resolution of the link-layer address of the interface to which the next-hop IP address is bound. Furthermore, it cannot be ruled out that the IP addresses configured Bernardos & in 't Velt Expires April 29, 2010 [Page 4] Internet-Draft autoconf addressing model October 2009 on MANET interfaces will be used as source or destination addresses by end-user applications in cases where such applications reside on MANET routers. An architecture in which applications are separated by one hop from MANET interfaces is conceptually elegant, but may not always be practical. This document considers MANET domains for the purposes of IP configuration. Therefore, when we use the term "MANET" throughout this document, we are referring to a MANET domain. For example, MANET local uniqueness refer to uniqueness within the MANET domain. Globally unique IP addresses MUST be provided for routers of attached MANETs for those cases where these addresses are visible outside the MANET domain, while only uniqueness within the MANET domain is required for non-attached MANETs. This document does not rule out that IP addresses might be configured by non-autoconf mechanisms (e.g., manually) on MANET interfaces. 3.2. IPv4/IPv6 practical addressing model This section describes the basic principles for IP addressing for MANET interfaces, in as much an IP version agnostic manner as possible. MANET interfaces of attached MANETs SHOULD be configured with global IPv6 addresses if these addresses are somehow exposed outside the MANET domain. For non-attached MANETs, ULAs or global addresses SHOULD be used. Since the topology of a mobile ad hoc network is expected to be frequently changing, MANET interfaces MUST be configured with unique/ non-overlapping prefixes. This principle does not assume any prefix length. The use of /32 (in the IPv4 case) or /128 (in the IPv6 case) prefix lengths can be an effective way to ensure that prefixes are non-overlapping. However, it would be needlessly restrictive to mandate the use of only these prefix lengths. Due to its larger address space, it is much easier to generate addresses for IPv6 that are unique than is the case for IPv4. This is equally true for prefixes with non-maximum lengths. MANET interfaces MUST also be configured with IPv6 Link-local addresses (as required by RFC 4861 [RFC4861] and RFC 4291 [RFC4291]). Two main concerns may arise when considering the use of IPv6 Link- local addresses: o Address uniqueness: the event of having two duplicate addresses in the same link has proved to be very low (EUI64 derived interface Bernardos & in 't Velt Expires April 29, 2010 [Page 5] Internet-Draft autoconf addressing model October 2009 identifiers very rarely collide, since MAC addresses are expected to be globally unique), and even some mechanisms have been proposed to reduce the collision probability [paper.DAD]. Therefore, in most scenarios it is safe to assume that the probability of having two or more duplicated link-local addresses in a MANET is negiglible. For those scenarios, in which this cannot be safely assumed, we refer to the DAD considerations of Section 3.3. o Reachability: connectivity among neighbours in wireless links may be intermittent and/or short-lived. Therefore, the use of link- local addresses may lead to reachability issues, since two nodes that were in direct coverage range at one moment, might not be anymore shortly after. These problems might also arise in wired networks (nodes going up/down), but it is not the common case. Designers of MANET routing protocols (and other protocols) should be aware of these concerns and assess their impact, in order to make an informed decision whether to make use of link-local addresses or not. Fluctuating reachability as discussed above is also of concern to the data forwarding process in ad hoc networks. This is especially true, if existing mechanisms for neighbour discovery and address resolution are to be applied. In order to mitigate these problems, several solutions may be used, such as (but not limited to): decrease some of the ND default timer values (specified in RFC 4861 [RFC4861]), such as REACHABLE_TIME, RETRANS_TIMER, DELAY_FIRST_PROBE_TIME, MIN_RANDOM_FACTOR, MAX_RANDOM_FACTOR; implement a stronger interaction between the MANET routing protocols and the ND process, so the MANET routing protocol helps to keep updated the ND tables. Finally, if none of these solutions (or alternative ones) may be implemented, processes running on the MANET routers that need to be isolated from this problem can decide not to use link-local addresses for their local communications. Since IPv4 lacks any standardised unreachability detection mechanism, these considerations about reachability only concern IPv6. Configuration and use of IPv4 link-locals on MANET interfaces are not forbidden. However, while in IPv6, an interface may be simultaneously configured with a link-local address and with unicast (global or local) addresses, this is not recommended in IPv4 [RFC3927]. When forwarding user data packets from one MANET router to the next, along the path from source to destination, standard mechanisms for layer-2 address resolution of next-hop IP addresses, such as ND or ARP, may be used. In this context, it should be noted that the presence of IPv6 link-local addresses on MANET interfaces may lead to Bernardos & in 't Velt Expires April 29, 2010 [Page 6] Internet-Draft autoconf addressing model October 2009 their use, e.g. as source address in a neigbor solicitation. As mentioned before, the exchange of MANET routing protocols packets is a potential alternative source of link-layer address information. 3.3. DAD considerations This document assumes that DAD is disabled by default for the IP addresses configured on MANET interfaces (this is allowed in RFC 4862 [RFC4862]. For the case of link-local addresses, we assume the collision probability is negiglible, and that it therefore is safe to avoid the overhead of an active DAD process (which would need to be modified to be run in a MANET domain wide fashion). For the case of the non-overlapping prefixes, we do not specify how their uniqueness is ensured (this is out-of-scope of this document and falls in the solution space). However, this document does not forbid the use of any DAD mechanism, if it is required in some certain scenarios. From the point of view of MANETs, it seems appropriate to consider as well the use of passive DAD approaches (such as [paper.PACMAN], [paper.PACMAN_assessment]). 4. IANA Considerations This document makes no request of IANA. 5. Security Considerations This document does currently not describe any security considerations. 6. Acknowledgements Some of the ideas included in this draft have been proposed in the AUTOCONF ML by several people. Thanks for all the AUTOCONF WG participants for the fruitful discussions over these years. The authors would like to thank Thomas Clausen and Teco Boot for their comments and discussion on this document. The research of Carlos J. Bernardos leading to these results has received funding from the European Community's Seventh Framework Programme (FP7/2007-2013) under grant agreement n. 214994 (CARMEN project) and also from the Ministry of Science and Innovation of Spain, under the QUARTET project (TIN2009-13992-C02-01). Bernardos & in 't Velt Expires April 29, 2010 [Page 7] Internet-Draft autoconf addressing model October 2009 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. 7.2. Informative References [I-D.iab-ip-model-evolution] Thaler, D., "Evolution of the IP Model", draft-iab-ip-model-evolution-01 (work in progress), November 2008. [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999. [paper.DAD] Bagnulo, M., Soto, I., Garcia-Martinez, A., and A. Azcorra, "Avoiding DAD for Improving Real-Time Communication in MIPv6 Environments", Joint International Workshop on Interactive Distributed Multimedia Systems/ Protocols for Multimedia Systems IDMS-PROMS 2002, Coimbra (Portugal). Lecture Notes in Computer Science 2515, pps 73-79, Ed. Springer-Verlag, 2002. , November 2002. Bernardos & in 't Velt Expires April 29, 2010 [Page 8] Internet-Draft autoconf addressing model October 2009 [paper.PACMAN] Weniger, K., "PACMAN: passive autoconfiguration for mobile ad hoc networks", IEEE Journal on Selected Areas in Communications 23 (3) , 2005. [paper.PACMAN_assessment] Bernardos, C., Calderon, M., Soto, I., Solana, A., and K. Weniger, "Building an IP-based Community Wireless Mesh Network: Assessment of PACMAN as an IP Address Autoconfiguration Protocol", Computer Networks, accepted for publication , 2009. Authors' Addresses Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 6236 Email: cjbc@it.uc3m.es URI: http://www.it.uc3m.es/cjbc/ Ronald in 't Velt TNO Information and Communication Technology Brassersplein 2 Delft 2600 GB The Netherlands Phone: +31 15 2857306 Email: Ronald.intVelt@tno.nl Bernardos & in 't Velt Expires April 29, 2010 [Page 9]