RFC 5889

IP Addressing Model in Ad Hoc Networks

📅 published September 2010, from ietf

RFC 5889: IP Addressing Model in Ad Hoc Networks 🎀

Okay bestie, this is RFC 5889 💖 It's an Informational RFC (so it's guidance, not a standards-track spec 🧚), published by the IETF in September 2010 with ISSN 2070-1721. The editors are E. Baccelli, Ed. from INRIA and M. Townsley, Ed. from Cisco Systems. The header doesn't list anything it obsoletes or updates, so it isn't replacing or changing any other RFC. Iconic, right? ✨

Abstract

This doc describes a model for setting up IP addresses and subnet prefixes on the interfaces of routers that connect to links with undetermined connectivity properties 🌸

Status of This Memo

This doc is not an Internet Standards Track spec. It's published for informational purposes 💅

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 for the full scoop 🦋

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc5889 ✨

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved 💜

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, because they lay out your rights and restrictions for this doc 🙈 Code Components pulled from this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License ⚠️

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 🌈

Okay so, getting the IP addresses and subnet masks right on router interfaces is basically a prerequisite for routing protocols to work properly 😭 People weigh a bunch of stuff when they plan this, like the link's capabilities and connectivity, the geographic topology, the available address blocks, the expected traffic patterns, and so on. All of that decides the right network topology and the matching IP interface config ✨

When the capabilities and connectivity of the links between routers are well-known and stable, designing the logical topology and configuring the IP interfaces is straightforward 💅 But if you can't assume anything about link-level connectivity, there's no canonical way to figure out the right IP interface config. Lowkey chaotic 💀

Link-level connectivity counts as undetermined when it's unplanned and/or time-varying. Ad hoc networks are the classic example of networks with undetermined link-level connectivity 🦋 Routing protocols for ad hoc networks are specifically built to detect and maintain paths across the network, even when the links have undetermined connectivity, as long as the routers' interfaces are configured with IP addresses 🫶 So this doc proposes a model for configuring IP addresses and subnet prefixes on router interfaces attached to links with undetermined connectivity, so that routing protocols and data packet forwarding can actually function 🎀

Heads up, routers might eventually need more IP prefixes for the various applications that run directly on the routers, or for hosts and networks attached to them. For IPv6, those addresses can be global [RFC3587], Unique-Local [RFC4193], or Link-Local [RFC4291]. For IPv4, they can be global (i.e., public) or private [RFC1918]. Generally, global scope is preferred over local scope, though it's understood that this might not always be possible with automatic configuration mechanisms 🌸 In this doc, though, automatic configuration of the prefixes used for general applications is treated as a separate problem from automatically configuring the addresses and prefixes that routing protocols need in order to function. So this doc focuses on the latter: the kind of IP address and subnet mask configuration that routing protocols and data packet forwarding need to work 💖

2. Terminology ✨

This doc uses the vocabulary and concepts defined in [RFC1918] and [RFC4632] for IPv4, and in [RFC4291] for IPv6 🧚

3. Applicability Statement 🎀

This model gives guidance on configuring IP addresses and IP subnet prefixes on a router's IP interfaces, the ones connecting to links with undetermined connectivity properties 💅

When you can make more specific assumptions about connectivity between interfaces, or about the (persistent) reachability of some addresses, those should be taken into account when configuring subnet prefixes 🦋

4. IP Subnet Prefix Configuration 💜

If the link an interface connects to doesn't allow any assumptions of connectivity to other interfaces, the only addresses you can assume are "on link" are the address(es) of that interface itself 🙈 Link-local addresses are also assumed to be "on link," but their usefulness is limited, as explained in Section 6 🌸

So subnet prefix configuration on these interfaces must not make any promises about direct (one hop) IP connectivity to IP addresses other than the interface's own address. This leads to the following principle:

  • no on-link subnet prefix should be configured on such an interface.

Also, if layer 2 communication is enabled between a pair of interfaces, IP packet exchange is enabled too, even if IP subnet configuration is missing or different on each of those interfaces ✨

And on the flip side, if assumptions can be made about connectivity between interfaces, or about the persistent reachability of some addresses, those should be considered when configuring IP subnet prefixes. In that case, the corresponding interface(s) may be configured with an on-link subnet prefix 🫶

5. IP Address Configuration 🌈

Routing protocols running on a router can have different requirements for how unique interface addresses need to be. Some have no requirements at all, and others need uniqueness anywhere from just locally, up to uniqueness within at least the routing domain (as defined in [RFC1136]) 😭

Routing protocols that don't require unique IP addresses within the routing domain use a separate unique identifier inside the routing protocol itself. Those identifiers could be based on factory assignment or configuration 💅

Even so, configuring an IP address that's unique within the routing domain satisfies the less stringent uniqueness requirements, and it also works for protocols with the strictest uniqueness requirements within the routing domain 💖 So, for IP autoconfiguration to work with the widest possible range of routing protocols, this principle applies:

  • 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 a router's interface when that interface connects to a link with undetermined connectivity properties 🦋 This section lays out the guidelines that follow from those principles, one for IPv6 and one for IPv4 🫶

Heads up, the guidelines in this doc are slightly different for IPv6 and IPv4, because IPv6 gives you options IPv4 doesn't. For example, you can simply not configure any on-link subnet prefix on an IPv6 interface, which makes for a "cleaner" model 🎀

6.1. IPv6 Model 🧚

For IPv6, the principles from Sections 4 and 5 suggest these rules:

  • An IP address configured on this interface should be unique, at least within the routing domain, and
  • No on-link subnet prefix is configured on this interface.

Now, an IPv6 link-local address gets assigned to every interface as per [RFC4291], but link-local addresses are generally of limited use on links with undetermined connectivity, since connectivity to neighbors may keep changing 🌸 The known limitations are:

  • In general, there's no mechanism to make sure IPv6 link-local addresses are unique across multiple links. That said, link-local addresses using an IID in the modified EUI-64 form should be globally unique ✨
  • Routers can't 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 💀

So, autoconfiguration solutions should be encouraged to focus mainly on configuring IP addresses that are not IPv6 link-local 💖

6.2. IPv4 Model 🌈

For IPv4, the principles from Sections 4 and 5 suggest rules similar to the ones for IPv6 in Section 6.1, which are:

  • An IP address configured on this interface should be unique, at least within the routing domain, and
  • Any subnet prefix configured on this interface should be 32 bits long.

Heads up: using IPv4 link-local addresses [RFC3927] in this context should be discouraged for most applications 🙈 The limitations outlined in Section 6.1 for IPv6 link-local addresses also apply to IPv4 link-local addresses. And it gets worse, because there's a smaller pool of IPv4 link-local addresses to choose from, which means more reliance on Duplicate Address Detection (DAD) 😭

7. Security Considerations ⚠️

This doc focuses on the IP address and subnet mask configuration needed for routing protocols and data packet forwarding to function. [RFC4593] describes generic threats to routing protocols, and the presence of interfaces with undetermined connectivity properties doesn't change whether those threats apply 💜 So the addressing model in this doc doesn't introduce any new security threats ✨

BUT, and this is a big but 😱, the possible lack of pre-established infrastructure or authority that comes with interfaces with undetermined connectivity properties may make some of the attacks described in [RFC4593] easier to pull off. In particular, malevolent misconfiguration may be harder to detect and harder to locate 🚨

8. References 🍓

8.1. Normative References ✨

okay so these are the references the spec needs you to read, no skipping bestie 📚🫶

  • [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. 👑

8.2. Informative References 🌈

these ones are more of a "good to know" vibe, not a must-read, but they're iconic 💅

  • [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006. 💀

Appendix A. Contributors 🫶

this doc is built on discussions and contributions from a whole squad of people, listed here in alphabetical order: Teco Boot, Thomas Clausen, Ulrich Herberg, Thomas Narten, Erik Nordmark, Charles Perkins, Zach Shelby, and Dave Thaler. literally legends, all of them 👑✨

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
📦 where this page comes from