From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5889.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc5889.txt (limited to 'doc/rfc/rfc5889.txt') diff --git a/doc/rfc/rfc5889.txt b/doc/rfc/rfc5889.txt new file mode 100644 index 0000000..5653152 --- /dev/null +++ b/doc/rfc/rfc5889.txt @@ -0,0 +1,451 @@ + + + + + + +Internet Engineering Task Force (IETF) E. Baccelli, Ed. +Request for Comments: 5889 INRIA +Category: Informational M. Townsley, Ed. +ISSN: 2070-1721 Cisco Systems + September 2010 + + + IP Addressing Model in Ad Hoc Networks + +Abstract + + This document describes a model for configuring IP addresses and + subnet prefixes on the interfaces of routers which connect to links + with undetermined connectivity properties. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5889. + +Copyright Notice + + Copyright (c) 2010 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. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + +Baccelli & Townsley Informational [Page 1] + +RFC 5889 Ad Hoc IP Addressing September 2010 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Applicability Statement . . . . . . . . . . . . . . . . . . . . 4 + 4. IP Subnet Prefix Configuration . . . . . . . . . . . . . . . . 4 + 5. IP Address Configuration . . . . . . . . . . . . . . . . . . . 4 + 6. Addressing Model . . . . . . . . . . . . . . . . . . . . . . . 5 + 6.1. IPv6 Model . . . . . . . . . . . . . . . . . . . . . . . . 5 + 6.2. IPv4 Model . . . . . . . . . . . . . . . . . . . . . . . . 6 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 + Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . . 7 + +1. Introduction + + The appropriate configuration of IP addresses and subnet masks for + router network interfaces is generally a prerequisite to the correct + functioning of routing protocols. Consideration of various items, + including underlying link capabilities and connectivity, geographical + topology, available address blocks, assumed traffic patterns etc., + are used when determining the appropriate network topology and the + associated IP interface configuration. + + When the capabilities and connectivity of the links that connect + routers are well-known and stable, logical network topology design + and corresponding IP interface configuration are straightforward. + Absent any assumption about link-level connectivity, however, there + is no canonical method for determining a given IP interface + configuration. + + Link-level connectivity is generally qualified as undetermined when + it is unplanned and/or time-varying in character. Ad hoc networks + are typical examples of networks with undetermined link-level + connectivity. Routing protocols for ad hoc networks are purposely + designed to detect and maintain paths across the network, even when + faced with links with undetermined connectivity, assuming that + routers' interfaces are configured with IP addresses. This document + thus proposes a model for configuration of IP addresses and subnet + prefixes on router interfaces to links with undetermined connectivity + properties, to allow routing protocols and data packet forwarding to + function. + + Note that routers may ultimately need additional IP prefixes for the + diverse applications that could run directly on the routers + themselves, or for assignment to attached hosts or networks. For + + + +Baccelli & Townsley Informational [Page 2] + +RFC 5889 Ad Hoc IP Addressing September 2010 + + + IPv6, these addresses may be global [RFC3587], Unique-Local [RFC4193] + or Link-Local [RFC4291]. For IPv4, the addresses may be global + (i.e., public) or private [RFC1918]. In general, global scope is + desired over local scope, though it is understood that this may not + always be achievable via automatic configuration mechanisms. In this + document however, automatic configuration of the prefixes used for + general applications is considered as a problem that is separable + from that of automatic configuration of addresses and prefixes + necessary for routing protocols to function. This document thus + focuses on the latter: the type of IP address and subnet mask + configuration necessary for routing protocols and data packet + forwarding to function. + +2. Terminology + + This document uses the vocabulary and the concepts defined in + [RFC1918] and [RFC4632] for IPv4, as well as [RFC4291] for IPv6. + +3. Applicability Statement + + This model gives guidance about the configuration of IP addresses and + the IP subnet prefixes on a router's IP interfaces, which connect to + links with undetermined connectivity properties. + + When more specific assumptions can be made regarding the connectivity + between interfaces or the (persistent) reachability of some + addresses, these should be considered when configuring subnet + prefixes. + +4. IP Subnet Prefix Configuration + + If the link to which an interface connects enables no assumptions of + connectivity to other interfaces, the only addresses that can be + assumed "on link", are the address(es) of that interface itself. + Note that while link-local addresses are assumed to be "on link", the + utility of link-local addresses is limited as described in Section 6. + + Thus, subnet prefix configuration on such interfaces must not make + any promises in terms of direct (one hop) IP connectivity to IP + addresses other than that of the interface itself. This suggests the + following principle: + + o no on-link subnet prefix should be configured on such an + interface. + + Note that if layer 2 communication is enabled between a pair of + interfaces, IP packet exchange is also enabled, even if IP subnet + configuration is absent or different on each of these interfaces. + + + +Baccelli & Townsley Informational [Page 3] + +RFC 5889 Ad Hoc IP Addressing September 2010 + + + Also note that if, on the contrary, assumptions can be made regarding + the connectivity between interfaces, or regarding the persistent + reachability of some addresses, these should be considered when + configuring IP subnet prefixes, and the corresponding interface(s) + may in such case be configured with an on-link subnet prefix. + +5. IP Address Configuration + + Routing protocols running on a router may exhibit different + requirements for uniqueness of interface addresses; some have no such + requirements, others have requirements ranging from local uniqueness + only, to uniqueness within, at least, the routing domain (as defined + in [RFC1136]). + + Routing protocols that do not require unique IP addresses within the + routing domain utilize a separate unique identifier within the + routing protocol itself; such identifiers could be based on factory + assignment or configuration. + + Nevertheless, configuring an IP address that is unique within the + routing domain satisfies the less stringent uniqueness requirements, + while also enabling protocols that have the most stringent + requirements of uniqueness within the routing domain. As a result, + the following principle allows for IP autoconfiguration to apply to + the widest array of routing protocols: + + o an IP address assigned to an interface that connects to a link + with undetermined connectivity properties should be unique, at + least within the routing domain. + +6. Addressing Model + + Sections 4 and 5 describe principles for IP address and subnet prefix + configuration on an interface of a router, when that interface + connects to a link with undetermined connectivity properties. The + following describes guidelines that follow from these principles, + respectively for IPv6 and IPv4. + + Note that the guidelines provided in this document slightly differ + for IPv6 and IPv4, as IPv6 offers possibilities that IPv4 does not + (i.e., the possibility to simply not configure any on-link subnet + prefix on an IPv6 interface), which provide a "cleaner" model. + + + + + + + + + +Baccelli & Townsley Informational [Page 4] + +RFC 5889 Ad Hoc IP Addressing September 2010 + + +6.1. IPv6 Model + + For IPv6, the principles described in Sections 4 and 5 suggest the + following rules: + + o An IP address configured on this interface should be unique, at + least within the routing domain, and + + o No on-link subnet prefix is configured on this interface. + + Note that while an IPv6 link-local address is assigned to each + interface as per [RFC4291], in general link-local addresses are of + limited utility on links with undetermined connectivity, as + connectivity to neighbors may be constantly changing. The known + limitations are: + + o In general, there is no mechanism to ensure that IPv6 link-local + addresses are unique across multiple links, though link-local + addresses using an IID that are of the modified EUI-64 form should + be globally unique. + + o Routers cannot forward any packets with link-local source or + destination addresses to other links (as per [RFC4291]), while + most of the time, routers need to be able to forward packets to/ + from different links. + + Therefore, autoconfiguration solutions should be encouraged to + primarily focus on configuring IP addresses that are not IPv6 link- + local. + +6.2. IPv4 Model + + For IPv4, the principles described in Sections 4 and 5 suggest rules + similar to those mentioned for IPv6 in Section 6.1, that are: + + o An IP address configured on this interface should be unique, at + least within the routing domain, and + + o Any subnet prefix configured on this interface should be 32 bits + long. + + Note that the use of IPv4 link-local addresses [RFC3927] in this + context should be discouraged for most applications, as the + limitations outlined in Section 6.1 for IPv6 link-local addresses + also concern IPv4 link-local addresses. These limitations are + further exacerbated by the smaller pool of IPv4 link-local addresses + to choose from and thus increased reliance on Duplicate Address + Detection (DAD). + + + +Baccelli & Townsley Informational [Page 5] + +RFC 5889 Ad Hoc IP Addressing September 2010 + + +7. Security Considerations + + This document focuses on the IP address and subnet mask configuration + necessary for routing protocols and data packet forwarding to + function. [RFC4593] describes generic threats to routing protocols, + whose applicability is not altered by the presence of interfaces with + undetermined connectivity properties. As such, the addressing model + described in this document does not introduce new security threats. + + However, the possible lack of pre-established infrastructure or + authority, as enabled by the use of interfaces with undetermined + connectivity properties, may render some of the attacks described in + [RFC4593] easier to undertake. In particular, detection of + malevolent misconfiguration may be more difficult to detect and to + locate. + +8. References + +8.1. Normative References + + [RFC1136] Hares, S. and D. Katz, "Administrative Domains and Routing + Domains: A model for routing in the Internet", RFC 1136, + December 1989. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + + [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic + Configuration of IPv4 Link-Local Addresses", RFC 3927, + May 2005. + + [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., + and E. Lear, "Address Allocation for Private Internets", + BCP 5, RFC 1918, February 1996. + + [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast + Addresses", RFC 4193, October 2005. + + [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global + Unicast Address Format", RFC 3587, August 2003. + + [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing + (CIDR): The Internet Address Assignment and Aggregation + Plan", BCP 122, RFC 4632, August 2006. + + + + + + + +Baccelli & Townsley Informational [Page 6] + +RFC 5889 Ad Hoc IP Addressing September 2010 + + +8.2. Informative References + + [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to + Routing Protocols", RFC 4593, October 2006. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Baccelli & Townsley Informational [Page 7] + +RFC 5889 Ad Hoc IP Addressing September 2010 + + +Appendix A. Contributors + + This document reflects discussions and contributions from several + individuals including (in alphabetical order): Teco Boot, Thomas + Clausen, Ulrich Herberg, Thomas Narten, Erik Nordmark, Charles + Perkins, Zach Shelby, and Dave Thaler. + +Authors' Addresses + + Emmanuel Baccelli (editor) + INRIA + + EMail: Emmanuel.Baccelli@inria.fr + URI: http://www.emmanuelbaccelli.org/ + + + Mark Townsley (editor) + Cisco Systems + + EMail: mark@townsley.net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Baccelli & Townsley Informational [Page 8] + -- cgit v1.2.3