Autoconf T. Clausen Internet-Draft U. Herberg Intended status: Informational LIX, Ecole Polytechnique Expires: August 29, 2009 February 25, 2009 MANET Router Configuration Recommendations draft-clausen-manet-autoconf-recommendations-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 August 29, 2009. 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document describes a pragmatic set of configuration recommendations for MANETs, as well as provides a rationale for why Clausen & Herberg Expires August 29, 2009 [Page 1] Internet-Draft MANET Router Configuration Recommendation February 2009 these recommendations are sound. While there may be other equally valid ways of configuring a MANET, the recommendations in this document have the merit of being supported by an existence proof (there're running networks in existence, configured according to these recommendations), and they require neither modifications to the IP stack nor to upper-layer protocols or applications. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Document Outline . . . . . . . . . . . . . . . . . . . . . 4 2. MANET Configuration Recommendations . . . . . . . . . . . . . 4 2.1. MANET "Node" Morphology -- Hosts and Routers . . . . . . . 5 2.2. MANET Interface Configuration . . . . . . . . . . . . . . 6 2.3. Prefixes delegated to MANET Router . . . . . . . . . . . . 7 3. Example MANET Configurations . . . . . . . . . . . . . . . . . 7 3.1. MANET Router and Single Host . . . . . . . . . . . . . . . 7 3.2. MANET Router and Attached Network w. Prefix Delegation . . 9 3.3. MANET Router and Attached Network w/o Prefix Delegation . 10 3.4. MANET Router with two MANET Interfaces and Attached Network . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Unique MANET Interface Addresses . . . . . . . . . . . . . 13 4.2. /32 and /128 Prefix Lengths . . . . . . . . . . . . . . . 14 4.3. IP Hop Isolation . . . . . . . . . . . . . . . . . . . . . 18 5. Summary and Characteristics . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Clausen & Herberg Expires August 29, 2009 [Page 2] Internet-Draft MANET Router Configuration Recommendation February 2009 1. Introduction A MANET (Mobile Ad hoc NETwork) is, in academic circles, commonly described as a variation over the following: "a collection of independent nodes, communicating over a wireless, capacity-restricted medium, whereby they form a multi-hop connected network with no assumptions of an a-priori network infrastructure and with a highly dynamic topology." While such a description may be extrapolated to interesting challenges for research and protocol design, such as fast-convergence routing algorithms and bandwidth-economic protocols, it does little to describe the exact morphology and IP configuration of the "independent nodes" from which the MANET is constructed. Consequently, it offers little guidance in how a "real-world" IP- based MANET can be configured and deployed. MANET routing protocol specification as developed by the IETF, such as [RFC3626], [RFC3561], [RFC4728] and [RFC3684], stipulate internal processing of such "independent nodes" as well as specify the exact protocol message exchange between these, in order to allow construction of routing tables. As such, these specifications allow for operation of a MANET, and do provide indications as to under which assumptions such operation is assumed -- but on the other hand do not have as vocation to provide explicit configuration and deployment guidelines for MANETs. MANET routing protocols explicitly assume that all MANET nodes in a MANET are already configured, i.e. that the network interfaces have appropriate IP addresses etc. The purpose of this present document is to remedy that by describing recommendations and considerations for configuring and deploying a MANET. These considerations are characterized by adhering strictly to IP -- i.e. to require no modifications to neither the protocol stack nor to applications accessing the network -- and to be applicable for, to the best of the authors knowledge, any MANET using any choice of routing protocol from among those developed for MANETs within the IETF. Caveat lector: Other configurations and deployment approaches for MANETs are likely possible, and should not be disregarded or excluded. This document, however, describes a set of configuration and deployment recommendations, which practical experience and real- world deployments have shown to be feasible. Also note that this document describes only the end result -- but not any process (automatic or otherwise). Hence, when the term "configuration" is employed, it is as a noun for "the end result". Clausen & Herberg Expires August 29, 2009 [Page 3] Internet-Draft MANET Router Configuration Recommendation February 2009 1.1. Document Outline Section 2 presents, without rationale, explanation or apologies, recommendations for the constitution and configuration of a MANET router and of a MANET. This should allow the reader to immediately understand how to -- safely -- configure and deploy an IP based MANET using any of the currently developed IETF MANET routing protocols. This, while maintaining compatibility with all "Internet applications" and with other protocols, and without requiring modifications to the IP stack. Section 3 shows a selection of MANET router configurations, each strictly following the recommendations given in Section 2. These examples are not exhaustive, but rather illustrative for the kind of deployments supported by the recommendations in Section 2. Section 4 explains the background and rationale for the configuration recommendations presented in Section 2. For each configuration recommendation, a selection of justifications are presented and detailed. This should allow the reader to understand why the recommendations given in Section 2 represent a reasonable and operational way of configuring a MANET. Section 5 concludes this document by summarizing the configuration recommendations and the characteristics of a MANET configured according to the recommendations given in this document. 2. MANET Configuration Recommendations This section presents a small set of MANET configuration recommendations. As indicated in Section 1, these recommendations constitute an approach for which there is an existence proof that a MANET so configured is both correctly functioning and one in which "Internet applications" and other protocols operate unmodified without requiring modifications to the IP stack. Section 2.1 expands the notion of MANETs being constructed from "independent nodes" into the familiar terminology on the Internet and of IP networking of "Hosts" and "Routers". Section 2.2 describes address configuration of MANET router interfaces, and Section 2.3 how prefixes delegated to a MANET router are used. Caveat lector: This section explains uniquely the HOW of configuration of a MANET router and a MANET. The WHY -- the rationale and justification -- is given in Section 4. Clausen & Herberg Expires August 29, 2009 [Page 4] Internet-Draft MANET Router Configuration Recommendation February 2009 2.1. MANET "Node" Morphology -- Hosts and Routers Each "independent node" in a MANET can functionally be described according to Figure 1, with the "MANET node" being composed of a "MANET router" (R) with one or more "MANET interfaces" -- i.e. the interface which is to be used for establishing connectivity between MANET routers -- as well as zero or more interfaces towards other networks or hosts on classic IP links. \|/ MANET interface | +-----------|---------------------+ | +--+------+ | | | R | MANET router| | +---------+ | | | | | | +---+ | Classical IP | | | H | | links with | | +---+ | hosts | | _______|______ | | | | | | | +---+ +---+ +---+ | | | H |...| H | | H | | | +---+ +---+ +---+ | | | +---------------------------------+ MANET node Figure 1: MANET "node" morphology Functionally, this entails that: o MANET routing protocols are run over MANET interfaces only; o MANET routers enable connectivity between the MANET and hosts or other non-MANET networks; o MANET characteristics are "isolated behind an IP hop" from hosts or other networks; o Applications on hosts and other networks can remain "MANET unaware". A MANET, therefore, looks as depicted in Figure 2: the inner cloud represents where MANET routers have MANET interfaces and where only MANET aware protocols operate (e.g. MANET routing protocols) -- and the outer cloud represents the non-MANET-aware part of the network, with hosts and other (non-MANET) networks. Clausen & Herberg Expires August 29, 2009 [Page 5] Internet-Draft MANET Router Configuration Recommendation February 2009 ,.----.. _.--'''--._ ___ ,' ``. ,' `. _....._ _,'' ``,' +---+ +---+ ,-' `-. / | H | | H | \ | +---+ +---+ \ | |_______| | | ____| Edge | , ,-' +-. ___ _.' ,' +---+ ,,---../ | `'' ``. ``._ ,' | H |--+ ,' +--+--+ `. \ / +---+ | / +-----+ | R | \ | | +----| R | +-----+ Core | | `. +---+ | ' +-----+ / \ ' | | | H |--+ / \ / \ `. / `. +---+ | \ +-----+ +-----+ \ ,' `-. \ \_| R |------| R | | -''. / \ +--+--+ +-----+ ' `. ,' `. | _,' \ .' `-. | ,`. ,''' | | `-.___.+' `..__,,,' | | | / \ ,-----+--. / \ | | _,' `. +---+ +---+ ..,-' `-..____,,< | H | | H | /( / \ +---+ +---+ ,' \ ,' `. / `. ,' `._ ,-' `-..___,,' ``----'' Figure 2: A MANET with routers (R) and hosts (H). The "core" consists of routers that are responsible for network formation and maintenance. The "edge" includes hosts and non-MANET aware networks. This is akin to, say, an OSPF network, which can be depicted similarly to Figure 2: Within the inner cloud, OSPF routers with NBMA interfaces would be operating using protocol mechanisms suitably aware of NBMA characteristics, whereas the outer cloud would contain non-NBMA-aware parts of the network, such as hosts. 2.2. MANET Interface Configuration The following summarizes the configuration constraints for MANET interfaces of a MANET router: o Each MANET interface on a MANET router MUST be configured with an IP address which is unique, at least within the MANET. Clausen & Herberg Expires August 29, 2009 [Page 6] Internet-Draft MANET Router Configuration Recommendation February 2009 o Each MANET interface MUST be configured with a prefix length of /32 (for IPv4) or /128 (for IPv6). 2.3. Prefixes delegated to MANET Router The following summarizes the configuration constraints for a prefix, delegated to a MANET router: o If a prefix is delegated to a MANET router, this prefix MUST NOT be configured on any MANET interface. o If a prefix is delegated to a MANET router, other (non-MANET) interfaces MAY be configured with this prefix. 3. Example MANET Configurations This section provides a set of illustrative examples of common MANET configurations, respecting the considerations given in Section 2.2. Notice that this section does not attempt to exhaustively enumerate all possible MANET deployments or configurations. In the examples below, IP addresses and prefixes are extracted from within the private address space 192.168/16. This is for illustrative purposes only. This document does not take any position as to which address space is to be used for when configuring MANETs or other networks. 3.1. MANET Router and Single Host Figure 3 illustrates a MANET node consisting of a MANET router with a single MANET interface and a single host. This is the typical case, for example, when one has a laptop, PDA or smartphone participating in the MANET: the "router" and the "host" are in that case logical components within the same device, and with a single physical interface. The MANET node is assigned a single IPv4 address, in this case 192.168.1.1. This IP address is to identify both the MANET interface of the MANET router as well as the host. Logically, this is accomplished by configuring the interface of the MANET router as an "unnumbered interface", by assigning 192.168.1.1/32 to the MANET interface of the router. Traffic to the logical component that is the router will typically be addressed to a well-known multicast address, thus the router can distinguish between traffic to itself and traffic to the logical host. Clausen & Herberg Expires August 29, 2009 [Page 7] Internet-Draft MANET Router Configuration Recommendation February 2009 \|/ | 192.168.1.1/32 +-------|--------------+ | +--+--+ | | | R | | | +-----+ | | / | | / 192.168.1.1/32 | | +---+ | | | H | | | +---+ | +----------------------+ Figure 3: MANET router (R) and a single internal host (H) It is important to retain that the MANET interface is configured with a prefix length of /32, as this is an IPv4 network -- had it been an IPv6 network, the required prefix length for the MANET interfaces would have been /128. For administrative reasons, e.g. for the ability to aggregate routes for injection into other routing domains, IP addresses assigned to MANET interfaces (or prefixes delegated to MANET routers) within the same MANET may be extracted from within a larger interval, say, 192.168.0.0/16. Even so, each MANET interface configured with an IP address MUST be configured with a prefix length of /32 (IPv4) or /128 (IPv6) and no MANET interface may be configured with this larger address interval as prefix. Notice that in this situation, the address interval 192.168.0.0/16 represents the ability to aggregate a set of addresses into a single entry, and is specifically *NOT* related to "subnet" or "subnet prefix". A complete MANET so configured might look as depicted in Figure 4. Clausen & Herberg Expires August 29, 2009 [Page 8] Internet-Draft MANET Router Configuration Recommendation February 2009 _____ ,,-''''`-.. ,,-' `-.._-' `._ 192.168.0.0/16 ,' \ / \|/ \___ / \|/ | `-. | | +---+----+ `. | +----+---+ |192.168.| | | |192.168.| | 1.2/32 | | _' | 1.1/32 | +--------+ / / +--------+ < / \|/ \ | \|/ | \ \ | +----+---+ \ \ +----+---+ |192.168.| | `. |192.168.| | 1.4/32 | | `-..__. | 1.3/32 | +--------+ / \ +--------+ / `. ,' `. _,. ,,-' `--....-' `.. ,,' `'-----'' Figure 4: A correctly configured MANET. IP addresses within the routers are those assigned to the MANET interface. Notice that while all such IP addresses are extracted from the address interval 192.168.0.0/16, all MANET interfaces are configured with prefix lengths of /32. 3.2. MANET Router and Attached Network w. Prefix Delegation Figure 5 illustrates a MANET router with a single MANET interface and an interface towards a classic IP link such as an Ethernet. The MANET router is delegated the IPv4 prefix 192.168.1.0/24. That prefix is assigned to the non-MANET link, on which interfaces are assigned addresses such as 192.168.1.1/24, 192.168.1.2/24, 192.168.1.3/24 etc. Note that the interfaces on that classic IP link are configured with a prefix length of /24, indicating that the interfaces with addresses from within that IP prefix are all reachable within a single IP hop. The MANET interface is configured as an "unnumbered interface" by "borrowing" the address (192.168.1.1) from its interface towards the classic IP link - but is configured with the prefix length /32. The MANET interface is, specifically, not configured with a prefix length of /24, even though that prefix is delegated to the MANET router, as the MANET interface is not able to reach all other interfaces with addresses from within 192.168.1.0./24 in a single IP hop. Clausen & Herberg Expires August 29, 2009 [Page 9] Internet-Draft MANET Router Configuration Recommendation February 2009 192.168.1.1/32 \|/ +------------|------------+ | | | | +-+-----+ | | | R | 192.168.1.0/24 | +-------+ | |192.168.1.1/24 | | | | | +---------------+---------+ | ,----------+-----------. | | | +---+ +---+ +---+ 192.168.1.2/24 | H | | H | | H | 192.168.1.4/24 +---+ +---+ +---+ 192.168.1.3/24 Figure 5: MANET router (R) with an attached network and a delegated subnet prefix. Notice that the prefix 192.168.1.0/24 is assigned to the non-MANET link, where interfaces are configured with that prefix, e.g. 192.168.1.3/24. The MANET interface "borrows" the IP address from that link, however is configured with a prefix length of /32. Traffic to the MANET interface with the IP address 192.168.1.1 can be distinguished from traffic to the non-MANET interface with the same address since traffic destined to the MANET interface of the router typically will be addressed to a well-known multicast address. 3.3. MANET Router and Attached Network w/o Prefix Delegation Figure 6 shows a situation similar to that of Section 3.2 except that the MANET router, for whatever reason, is not delegated any prefix. As no prefix has been delegated to the MANET router, the MANET router can not simply "borrow" an IP address from within a delegated prefix for its MANET interface and know this IP address to be unique -- but has to rely on some other mechanism for acquiring an IP address. Whichever mechanism is used for acquiring this IP address, is shall ensure that this IP address is unique, at least within the MANET. Assuming that the MANET router has acquired the IP address 130.225.194.42 for use on its MANET interface, and that whatever mechanism gave this IP address to the MANET router ensured that this address is unique, at least within the MANET, then the MANET router can be configured as in figure Figure 6. Clausen & Herberg Expires August 29, 2009 [Page 10] Internet-Draft MANET Router Configuration Recommendation February 2009 130.225.194.42/32 \|/ +------------|------------+ | | | | +-+-----+ | | | R | | | +-------+ | | | | | | | +---------------+---------+ | ,----------+-----------. | | | +---+ +---+ +---+ | H | | H | | H | +---+ +---+ +---+ Figure 6: MANET router (R) with an attached network. The router has, through whichever mechanism, acquired the IP address 130.225.194.42 -- with which it configures its MANET interface and with a prefix length of /32. At this time, no prefix is delegated to the MANET router. The MANET router may attempt to acquire a prefix, through whatever mechanism availble on the network, for use when configuring attached hosts and networks -- or may assign IP addresses from within a private address space to such hosts and networks, and deploy NAT. 3.4. MANET Router with two MANET Interfaces and Attached Network Similar to Figure 5, Figure 7 illustrates the configuration of a MANET router with two MANET interfaces. In this case, the attached network and one of the MANET interfaces is configured exactly as in Figure 5, whereas the second MANET interface is configured using an otherwise unused IP address -- in this case 192.168.1.42 -- from within the 192.168.1.0/24 prefix. This interface is also configured with a prefix length of /32. Clausen & Herberg Expires August 29, 2009 [Page 11] Internet-Draft MANET Router Configuration Recommendation February 2009 192.168.1.1/32 \|/ \|/ 192.168.1.42/32 +------------|---|--------+ | | | | | +-+---+-+ | | | R | 192.168.1.0/24 | +-------+ | |192.168.1.1/24 | | | | | +---------------+---------+ | ,----------+-----------. | | | +---+ +---+ +---+ 192.168.1.2/24 | H | | H | | H | 192.168.1.4/24 +---+ +---+ +---+ 192.168.1.3/24 Figure 7: MANET router (R) with an attached network and a delegated subnet prefix and two MANET interfaces. Notice that the prefix 192.168.1.0/24 is assigned to the non-MANET link, where interfaces are configured with that prefix, e.g. 192.168.1.3/24. The MANET interface "borrows" the IP address from that link, however is configured with a prefix length of /32. The second MANET interface is configured using an unused IP address from within the same subnet prefix, in this case 192.168.1.42 -- also configured with a prefix length of /32 Using IP addresses from within the prefix delegated to the MANET router for configuring MANET interfaces on that router ensures that these IP addresses are unique, at least within the MANET -- assuming, of course, that the prefix delegation mechanism does not delegate the same prefix to multiple MANET routers within the same network. Notice that the same logic applies in this scenario as in the one in Figure 5: the second MANET interface could assume any IP address from within 192.168.1.0/24, even one already used by a host such as 192.168.1.2, as long as it is not used on another MANET interface and as long as the second MANET interface is also configured with a prefix length of /32. Traffic to the MANET interface with the IP address 192.168.1.2 can be distinguished from traffic to the non- MANET interface with the same address since traffic destined to the MANET interface of the router typically will be addressed to a well- known multicast address. 4. Rationale Section 2 describes three recommendations when configuring MANET Clausen & Herberg Expires August 29, 2009 [Page 12] Internet-Draft MANET Router Configuration Recommendation February 2009 routers and MANET interfaces on MANET routers: o Each MANET interface on a MANET router MUST be configured with an IP address which is unique, at least within the MANET; o MANET interfaces MUST be configured with prefix lengths of /32 (IPv4) or /128 (IPv6); o MANET routers MUST isolate MANET characteristics from non-MANET interfaces. This section provides a rationale for the configuration recommendations in Section 2 by presenting the reasoning behind each of these -- as well as a selection of consequences from configuring a MANET router without following these recommendations. In the descriptions in the following sections, IP addresses and prefixes are extracted from within the private address space 192.168/16. This is for illustrative purposes only. This document does not take any position as to which address space is to be used for when configuring MANETs or other networks. 4.1. Unique MANET Interface Addresses MANET interfaces are typically not attached to point-to-point links, but are rather of a "semi-broadcast nature" such as indicated in Figure 8. Hence, a packet transmitted on a MANET interface may be received by any number of MANET interfaces, including the transmitting MANET interface itself. Communication Range <~~~~~~~~+~~~~~~~~> <~~~~~~~~+~~~~~~~> |<~~~~~~~~+~~~~~~~~>| +--|--+ +--|--+ +--|--+ | A | | B | | C | +-----+ +-----+ +-----+ Figure 8: Example of "semi-broadcast" MANET interface characteristics. The arrows indicate the transmission range for each MANET interface, i.e. the range within which a transmitted packet can be successfully received and decoded. In order for MANET routers to be able to forward data packet not destined to themselves or to directly attached non-MANET hosts or networks, they need to be able to uniquely identify the "next hop" for a packet. Symmetrically, in order for a MANET router to discriminate between incoming data packets for it to forward (either Clausen & Herberg Expires August 29, 2009 [Page 13] Internet-Draft MANET Router Configuration Recommendation February 2009 within the MANET or to an attached host or network) or to discard, it needs to be able to identify if indeed it is the "next hop" for a received data packet. In order to accomplish this, MANET interfaces which are in direct L2 communication with each other need to be configured with unique IP addresses. Some MANET routing protocols employ flooding mechanisms (also commonly denoted "optimized flooding") in order to reduce the overhead involved in topology dissemination throughout the network. Examples include [RFC3626] and [RFC5449]. Such flooding mechanisms are based on each node selecting a subset of its neighbors as "relays", with only these relays taking part in flooding operations. Such relay selection algorithm in general require the ability to uniquely identify each MANET interface up to two hops away from the source; such is the case for [RFC3626] and [RFC5449]. Other flooding algorithms, studied for MANETs, perform relay selection requiring the ability to uniquely identify each MANET interface further away -- such is the case with various non-connected dominating set flooding approaches, currently a subject of research. By configuring MANET interfaces such that each has a MANET-wide unique address, it is ensured that both the flooding mechanisms from the current crop of MANET routing protocols, as well as potential future developments, are supported. 4.2. /32 and /128 Prefix Lengths In early MANET deployments, a common occurrence was to configure a MANET as "a subnet" and configure it as indicated in Figure 9: the MANET would have a subnet prefix, say 192.168.1.0/24 and MANET interfaces would be configured with this subnet prefix, e.g. 192.168.1.3/24. Clausen & Herberg Expires August 29, 2009 [Page 14] Internet-Draft MANET Router Configuration Recommendation February 2009 Communication Range <~~~~~~~~~~~~+~~~~~~~~~~~~> <~~~~~~~~~~~~+~~~~~~~~~~~~~> |<~~~~~~~~~~~~+~~~~~~~~~~~~>| +--------+ +--------+ +--------+ |192.168.| |192.168.| |192.168.| | 1.1/24 | | 1.2/24 | | 1.3/24 | +--------+ +--------+ +--------+ Data packet: --------------> dest 192.168.1.3 next-hop 192.168.1.2 ICMP Redirect <-------------- Figure 9: Misconfigured MANET: MANET interfaces configured with a shared /24 prefix, causing the central router to produce an ICMP redirect when forwarding packets from 192.126.1.1 to 192.168.1.3. If, for example, a data packet was transmitted by the MANET router 192.168.1.1 to be received by 192.168.1.3, then this would -- with reference to Figure 9 -- have to be forwarded by the MANET router 192.168.1.2. With the MANET interfaces in this MANET being configured with the subnet prefix 192.168.1 and the prefix length /24, it was observed that this produced ICMP redirects by 192.168.1.2. An early, and often suggested, solution was to "treat the symptoms rather than cure the disease" by disabling ICMP redirects on MANET routers -- i.e. to require modifications to the IP stack operation in order that it can be supporting MANETs. The ICMP redirect is intended to be used to inform a source to send packets using an alternative, more direct, route -- e.g. if a source, s wishes to send a data packet to a destination node d via the path s-R1-R2-d, and if R1 knows that a direct path s-R2-d is available, then the ICMP redirect from R1 will inform s of this route. Two interfaces, configured with addresses from within the same subnet prefix, and with the same prefix length are defined to be reachable from each other within a single IP hop. More precisely, it is assumed that all interfaces with IP addresses within that subnet prefix and configured with the same prefix length are directly reachable from each other without forwarding by an intermediate router. Hence, a way for R1 to know that a direct path may exist between h and R2 is if h, R1 and R2 are configured with IP addresses from within the same subnet prefix and within the same subnet prefix. Clausen & Herberg Expires August 29, 2009 [Page 15] Internet-Draft MANET Router Configuration Recommendation February 2009 Returning to the MANET scenario in Figure 9, with all MANET interfaces being configured with the same subnet prefix and the same prefix length, it follows from the discussion above that all these MANET interfaces are expected to be directly reachable from each other within a single IP hop. When, in this configuration, the router 192.168.1.2 is requested to forward a data packet from 192.168.1.1 to 192.168.1.3, it is expected that it generates an ICMP redirect to 192.168.1.1 suggesting that a direct path exists from 192.168.1.1 to 192.168.1.3 -- as this is what the configuration suggests. Rather than "treating the symptoms" and disabling ICMP redirects, requiring /32 and /128 prefix lengths on MANET interfaces "cures the disease". An interface so configured will not make any assumptions about other interfaces being within a single IP hop, and so will not generate ICMP redirects when forwarding traffic. An argument could be made, suggesting that for each set of MANET interfaces which are all directly reachable in one IP hop from each other, a shared "subnet prefix" can be assigned. Considering the network from Figure 9, this could allow two "subnets" to be formed, as indicated in Figure 10, with the MANET interface of the center router being configured with two IP addresses (or, being configured with two virtual interfaces, each with one IP address), one in each of the two subnets. Clausen & Herberg Expires August 29, 2009 [Page 16] Internet-Draft MANET Router Configuration Recommendation February 2009 . Communication . Range . ~~~~~~~~~~~~+~~~~~~~~~~~~~~~~><~~~~~~~~~~~~~~~~~~~+~~~~~~~~~ <~~~~~~~~~~~~~~~~~+~~~~~~~~~~~~~~~~~~~> . 192.168.1.1/24 . 192.168.2.2/24 \ | / \ | / \ | / \|/ 192.168. \|/ 192.168. \|/ | 1.2/24 | 2.1/24 | +--|-+ +----+ +--|-+ | N1 | | N2 | | N3 | +----+ +-.--+ +----+ . ----------------------. Subnet prefix .-------------------------- 192.168.1.0/24 . Subnet prefix . 192.168.2.0/24 Figure 10: MANET interfaces configured with a shared /24 subnet prefixes among neighbors which can all communicate directly in one IP hop. Notice that some MANET interfaces will be required to have multiple IP addresses, and as the network topology changes, also change their MANET interface configuration. While this could be a valid configuration, considering that the "M" in MANET is for "mobile", the network topology can be expected to change dynamically and frequently. A network so configured would, therefore, require constant "subnet formation" and "interface reconfiguration", in order to maintain the configuration valid. It would require (complex) mechanisms for tracking the topology dynamics and would entail potentially frequent changes to MANET interface address configurations. Such frequent changes of interface configurations would likely also adversely affect e.g. relay selection mechanisms such as those used for flooding in [RFC3626] and [RFC5449]: from the point of view of a router R, even if the topology within a 2 hop radius from R did not physically change (and so, no relay set recalculations would be needed), the logical configuration of interface addresses on a node 2 hops away from R might change (e.g. due to physical topology changes to the neighborhood of that node, i.e. 3 hops away from R) in order to preserve the ability of having "shared prefixes" among neighboring MANET interfaces. This would then potentially require relay set recalculations by R and additional signaling to this effect by a routing protocol on R -- even though topological changes were 3 hops away from R and such recalculations and signaling would not be necessary in case MANET interface addresses were kept stable. Clausen & Herberg Expires August 29, 2009 [Page 17] Internet-Draft MANET Router Configuration Recommendation February 2009 Finally, as the only application(s) to be exposed to MANET interfaces are MANET routing protocols and other protocols explicitly MANET aware and designed for management of a MANET infrastructure, it is highly questionable if there would be any benefits from introducing the complexities necessary for maintaining such dynamically changing "subnets" among MANET interfaces. Configuring MANET interfaces with a /32 or /128 prefix length is, therefore, a safe approach which entails no additional complicated mechanisms or signaling, and which requires no changes to the IP stack. 4.3. IP Hop Isolation Upper-layer applications and protocols are designed with a set of (often not explicitly expressed) assumptions as to the nature and characteristics of the underlying network communications fabric. This includes, but is not limited to, assumptions on (i) the relationship between a "subnet" and the ability for interfaces configured within the same subnet to all be able to communicate with each other directly, i.e. in one IP hop (as evoked in Section 4.1 and Section 4.2), (ii) that communication between interfaces on the same link is symmetric (if interface A can receive packets from interface B, then interface B can receive packets from interface A), (iii) that link-local multicast (i.e. with TTL or hop-limit equal to 1) is supported and is well defined (e.g. that the recipients of a link local multicast from interface A is identical to those of interface B, assuming that interfaces A and B are on the same link). Essentially, upper-layer applications and protocols assume an underlying link with characteristics similar to those of an Ethernet. Over MANET interfaces, these assumptions may not hold true. Consider for example the network in Figure 11. If interface A makes a link local multicast transmission, then this is received by the interface B -- whereas if interface B makes a link local multicast transmission, then this is received by the interfaces A and C. Communication Range <~~~~~~~~+~~~~~~~~> <~~~~~~~~+~~~~~~~> |<~~~~~~~~+~~~~~~~~>| +--|--+ +--|--+ +--|--+ | A | | B | | C | +-----+ +-----+ +-----+ Figure 11: Link local multicast over MANET interfaces: without forwarding, a transmission from the manet interface A reaches a different set of interfaces than those for a transmission from Clausen & Herberg Expires August 29, 2009 [Page 18] Internet-Draft MANET Router Configuration Recommendation February 2009 interface B (or interface C). There are, essentially, four potential ways of addressing this problem: requiring all upper-layer applications and protocols to become "MANET aware", inventing mechanisms for presenting a MANET as-if it was an Ethernet, pushing the problem to layer 2, or encapsulating any MANET specific behavior in a way such that it is only exposed to explicitly MANET aware applications and protocols. Requiring all upper-layer applications and protocols to be reworked such that they be MANET aware is impossible, due to the sheer volume of such, is undesirable as a tenant of the Internet is to provide an abstraction for applications from the interconnect characteristics, and would likely, not be without technical problems of its own -- for example, Section 4.2 exposes the complexity with respect to the single problem of correctly ensuring the relationship between "subnet" and which MANET interfaces are able to directly communicate. Pushing the problem to layer 2, and requiring a layer 2 to present an "Ethernet-like" medium would for a given layer 2 solve the problem -- but do away with the ability to deploy heterogeneous MANETs, and would be akin to e.g. requiring OSPF to do away with all but one interface type and require all layer 2's over which OSPF is expected to run to adhere to this single remaining interface type. The last way of addressing this problem is to encapsulate MANET specific behaviors in a way such that it only is exposed to explicitly MANET aware applications and protocols. This approach has several merits, not the least of which is that this is exactly the way in which existing routing protocols are deployed: interfaces between routers, and their characteristics, are exposed only to applications and protocols which are explicitly aware of these interfaces and their characteristics, with all other applications and protocols being isolated from these by being connected via an "Ethernet-like" link to the router -- i.e. by virtue of being isolated behind an IP hop (the router). For example, applications on hosts are exposed to an "Ethernet-like" link with other hosts and potentially routers -- and are blissfully unaware whether these routers are connected using point-to-point links, NBMA links, broadcast links etc. For these reasons, configuring a MANET such that the MANET router is isolating the MANET interfaces and their characteristics from hosts and other (non-MANET) networks by an IP hop, and requiring that on MANET routers, only explicitly MANET aware applications are exposed to MANET interfaces, is a safe and simple approach that entails no additional complex mechanisms and signaling. This also requires no Clausen & Herberg Expires August 29, 2009 [Page 19] Internet-Draft MANET Router Configuration Recommendation February 2009 changes to neither the IP stack nor the upper-layer applications and protocols operating on these hosts and (non-MANET) networks. 5. Summary and Characteristics This document proposes recommendations as to how MANETs can be configured and deployed, specifically, it provides the following three sets of recommendations: MANET Interface Address Configuration: o Each MANET interface on a MANET router MUST be configured with an IP address which is unique, at least within the MANET. o Each MANET interface MUST be configured with a prefix length of /32 (for IPv4) or /128 (for IPv6). Delegated Prefix Configuration: o If a prefix is delegated to a MANET router, this prefix MUST NOT be configured on any MANET interfaces. o If a prefix is delegated to a MANET router, other (non-MANET) interfaces MAY be configured with this prefix. MANET Interface Characteristics Encapsulation: o MANET interface characteristics are exposed only to explicitly MANET-aware protocols and applications, such as MANET routing protocols; o MANET interfaces are not exposed to applications and upper-layer protocols, i.e.; o MANET routers provide connectivity to hosts and other (non-MANET) networks via links with "Ethernet-like" link characteristics, and; o MANET routers provide connectivity from hosts and other (non- MANET) networks via IP routing, i.e. MANET interface characteristics are "hidden behind an IP hop" from applications and upper-layer protocols. A MANET configured according to these recommendations has the following key characteristics: MANET Characteristics: Clausen & Herberg Expires August 29, 2009 [Page 20] Internet-Draft MANET Router Configuration Recommendation February 2009 o It requires no modifications to the IP stack on hosts and non- MANET aware networks; o It requires no modifications to the IP stack on MANET routers; o It requires no modifications to upper-layer applications and protocols on hosts and (non-MANET) routers; o It supports all MANET routing protocols, as currently developed within the IETF. 6. IANA Considerations This document has no actions for IANA. 7. Security Considerations This document does currently not describe any security considerations. 8. Acknowledgments The considerations presented in this document are the authors condensation of years of experience within and outside the IETF, from studying, building, testing and deploying MANETs. The authors would like to express his profound thanks to (in no specific order) Dave Thaler (Microsoft), Thomas Narten (IBM), Jari Arkko (Ericsson), Mark Townsley (Cisco), Chris Dearlove (BAE Systems), Justin Dean (NRL), Joe Macker (NRL), Ian Chakeres (CenGen), Charles E. Perkins (WiChorus), Emmanuel Baccelli (INRIA), Henning Rogge (FGAN) and Ryuji Wakikawa (Toyota) for having given their valuable time to participating in the (at time vivid) discussions with the authors, and forming the foundation for writing this present document. Emmanuel Baccelli (INRIA) provided valuable proof-reading of this document in its final stages. 9. References Clausen & Herberg Expires August 29, 2009 [Page 21] Internet-Draft MANET Router Configuration Recommendation February 2009 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- Demand Distance Vector (AODV) Routing", RFC 3561, July 2003. [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003. [RFC3684] Ogier, R., Templin, F., and M. Lewis, "Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)", RFC 3684, February 2004. [RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4", RFC 4728, February 2007. [RFC5449] Clausen, T., Baccelli, E., Nguyen, D., and P. Jacquet, "OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks", RFC 5449, February 2009. Authors' Addresses Thomas Heide Clausen LIX, Ecole Polytechnique Phone: +33 6 6058 9349 Email: T.Clausen@computer.org URI: http://www.ThomasClausen.org/ Ulrich Herberg LIX, Ecole Polytechnique Phone: +33 1 6933 4126 Email: ulrich@herberg.name URI: http://www.herberg.name/ Clausen & Herberg Expires August 29, 2009 [Page 22]