AUTOCONF Working Group C. Bernardos Internet-Draft UC3M Intended status: Informational R. in 't Velt Expires: April 22, 2010 TNO October 19, 2009 Addressing Model for Router Interfaces in Ad Hoc Networks draft-bernardos-autoconf-addressing-model-00 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 22, 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 22, 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 . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Bernardos & in 't Velt Expires April 22, 2010 [Page 2] Internet-Draft autoconf addressing model October 2009 1. Introduction In order to communicate among themselves, ad hoc nodes [RFC2501] need to configure their network interface(s) with addresses that are valid within an ad hoc network. Ad hoc nodes 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 such models do not cause problems for ad hoc-unaware parts of the system, such as standard applications running on an ad hoc node or regular Internet nodes attached to the ad hoc nodes. 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 Following [I-D.iab-ip-model-evolution], a "wireless 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. Due to the wireless nature of the link, the topological area is defined by the radio- range coverage of the wireless technology used, and therefore links are intermittent, and potentially short-lived. 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) A MANET domain attached to an infrastructure based network (e.g., the Internet). The MANET interfaces of routers of an attached Bernardos & in 't Velt Expires April 22, 2010 [Page 3] Internet-Draft autoconf addressing model October 2009 MANET should be configured with unique global IP addresses, if these addresses are somehow exposed beyond the MANET domain. Non-overlapping prefix A set of IP prefixes is said to be non-overlapping if the following condition is met: there does not exist any IP address that could belong to more than one single IP prefix. 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 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, and they could be configured using standard mechanisms (such as SLAAC [RFC4862] or DHCP [RFC2131], [RFC3315]). Note, that while this document does not concern itself with mechanisms for obtaining prefixes for the purpose of configuring IP addresses on nodes reachable via non-MANET interfaces, such mechanisms are presumed to be in scope for the Autoconf WG. 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 routes are in place, these addresses 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. This entails the performance of link-layer address resolution on these addresses. Furthermore, these addresses may be used as source or destination addresses by end-user applications in those cases where such applications reside on MANET routers. 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, local uniqueness refer to uniqueness within the MANET domain. Globally unique IP addresses MUST be provided for routers of attached Bernardos & in 't Velt Expires April 22, 2010 [Page 4] Internet-Draft autoconf addressing model October 2009 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. Ensuring that configured prefixes on MANET interfaces with non-maximum lengths are non-overlapping is obviously easier for IPv6 than for IPv4, due to the larger addressing space. 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 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 [I-D.soto-mobileip-random-iids]. 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 Bernardos & in 't Velt Expires April 22, 2010 [Page 5] Internet-Draft autoconf addressing model October 2009 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. Having brought to attention these concerns, it is further left to the designers of MANET routing protocols (and other protocols) to determine whether link-local addresses can be used in an effective way. Fluctuating reachability as discussed above is als 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]. Standard mechanisms for layer-2 address resolution, such as ND or ARP may be used for addresses configured on MANET interfaces. The use of ARP requires the configuration of an IPv4 broadcast address on MANET interfaces. This broadcast address MUST have a wider scope than the unique, non-overlapping prefix of the IPv4 address on the MANET interface. (In IPv4-bases MANETs, 255.255.255.255 is often used). As mentioned before, the use of MANET routing protocols may also be considered as an alternative method for layer-2 address resolution. 3.3. DAD considerations This document assumes 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 therefore it is safe to avoid the overhead of an active DAD process (which would need to be Bernardos & in 't Velt Expires April 22, 2010 [Page 6] Internet-Draft autoconf addressing model October 2009 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 [I-D.weniger-autoconf-pdad-olsr]). 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 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). 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. Bernardos & in 't Velt Expires April 22, 2010 [Page 7] Internet-Draft autoconf addressing model October 2009 [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. [I-D.soto-mobileip-random-iids] Bagnulo, M., Soto, I., and A. Azcorra, "Random generation of interface identifiers", draft-soto-mobileip-random-iids-00 (work in progress), January 2002. [I-D.weniger-autoconf-pdad-olsr] Mase, K. and K. Weniger, "PDAD-OLSR: Passive Duplicate Address Detection for OLSR", draft-weniger-autoconf-pdad-olsr-01 (work in progress), June 2006. [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999. Bernardos & in 't Velt Expires April 22, 2010 [Page 8] Internet-Draft autoconf addressing model October 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 22, 2010 [Page 9]