RFC 2101

IPv4 Address Behaviour Today

📅 published February 1997, from ietf

RFC 2101: IPv4 Address Behaviour Today ✨

bestie, this is RFC 2101 🦋 It's an Informational doc from the Network Working Group, written by B. Carpenter, J. Crowcroft and Y. Rekhter, with IAB listed as their affiliation. It's dated February 1997. The title block doesn't list anything this RFC obsoletes or updates, so it stands on its own 💜

Status of this Memo

okay so this memo is just information for the Internet community 🌸 It does not specify an Internet standard of any kind, and distribution of it is unlimited.

Abstract

the main point of this note is to clarify how people should understand the 32-bit IP version 4 address space 🌈 Its meaning has changed a LOT since it was first defined. There's also a short section on IPv6 addresses that covers the main ways they're similar to IPv4 and the main ways they're different 🎀

Table of Contents

     1. Introduction.................................................1
     2. Terminology..................................................2
     3. Ideal properties.............................................3
     4. Overview of the current situation of IPv4 addresses..........4
       4.1. Addresses are no longer globally unique locators.........4
       4.2. Addresses are no longer all temporally unique............6
       4.3. Multicast and Anycast....................................7
       4.4. Summary..................................................8
     5. IPv6 Considerations..........................................8
     ANNEX: Current Practices for IPv4 Address Allocation & Routing..9
     Security Considerations........................................10
     Acknowledgements...............................................11
     References.....................................................11
     Authors' Addresses.............................................13

1. Introduction ✨

okay so the main purpose here is to clarify how we should interpret the 32-bit IP version 4 address space 💖 Its significance has changed a LOT since it was first defined in 1981 [RFC 791]. 😭

This clarification is for protocol designers, product implementors, Internet service providers, and user sites 🫶 It's meant to stop the misunderstandings about IP addresses that have popped up in the last few years, which happened because the Internet grew exponentially. Literally exploding 💥

Also, there's a short section on IPv6 addresses that covers the main similarities with IPv4 and the main differences 🦋

2. Terminology 📚

so in computer networks, directories, names, network addresses, and routes are all separate concepts, and each one needs to be analysed on its own [RFC 1498] 💅 But "network address" (which we'll just call "address" from here on) actually needs to be split into at least two ideas: "identifier" and "locator". Honestly, this wasn't super well understood when RFC 791 was written 🙈

Some definitions for this doc:

  • "host" means any system that originates and/or terminates IPv4 packets 💻
  • "router" means any system that forwards IPv4 packets from one host or router to another 🔀

Now the identifier 🎀 It's a bit string that's used for the entire lifetime of a communication session between two hosts, and it identifies one host from the other host's point of view. It's how you check that incoming packets really come from the other end of the conversation, for example in the TCP pseudo-header [RFC 793] or in an IP Security association [RFC 1825]. Traditionally, the source IPv4 address in every packet has been used for this 👑

Quick note: other people sometimes use "identifier" to mean other things 🙈 This document doesn't claim to cover the general question of what end-point identifiers mean.

Next, the locator 📍 It's a bit string that tells you where a packet must be delivered. Basically, it points to the spot in the Internet topology where the destination host is attached. Traditionally, the destination IPv4 address in every packet does this job. IP routing protocols treat IPv4 addresses as locators, and they build routing tables based on which routers (which also have their own locators) say they know a route to the locators of particular hosts 🗺️

Now, identifiers AND locators both have uniqueness requirements, but they're different 👀

  • Identifiers must be unique with respect to each set of inter-communicating hosts.
  • Locators must be unique with respect to each set of inter-communicating routers. We'll call that set a routing "realm" 🌸

While locators must be unique within a given routing realm, that uniqueness (though not routability) could stretch across more than one realm. So we can tell apart a set of realms with unique locators from a set of realms with non-unique (overlapping) locators ✨

Identifiers and locators also have lifetime requirements, and once again they're different 🧚

  • Identifiers must be valid for at least the maximum lifetime of a communication between two hosts.
  • Locators must be valid only as long as the routing mechanisms require them to be. That could be shorter OR longer than the communication's lifetime 💜

It's worth noting that it's a contingent fact of history that RFC 791 and RFC 793 use the same address space and the same IP header fields (source and destination addresses) for BOTH identifiers and locators 🤯 In the traditional Internet, a host's identifier is the same as its locator. It's also spatially unique (unambiguous) and temporally unique (constant) 💖

These uniqueness conditions had consequences for design assumptions in two places: routing (the infrastructure that IPv4 locators make possible) and transport protocols (the stuff that relies on IP connectivity) 🔥 Spatial uniqueness meant an address worked as an interface identifier AND a host identifier, and it was also the key to the routing table. Temporal uniqueness meant TCP implementations didn't need to keep any state about the far end's identity beyond its IP address. So IP addresses could be used for both end-to-end IP security AND for binding upper layer sessions 🫶

In general, using IPv4 addresses as locators has been seen as more important than using them as identifiers. When the two uses clashed, the locator use won 👑 Basically, it's been considered more useful to deliver the packet first and worry about identifying the endpoints later, rather than include an identity in a packet that can't be delivered 📦 In other words, there's been intensive work on routing protocols and very little concrete work on other aspects of address usage 🙈

3. Ideal properties. 🌈

okay so no matter what constraints we just talked about, it's super easy to see the IDEAL properties for identifiers and locators 💅

  • Identifiers should be assigned at birth, never change, and never be re-used 🎂
  • Locators should describe the host's position in the network's topology, and should change whenever the topology changes 🗺️

Unfortunately, neither of these ideals is met by IPv4 addresses 😭 The rest of this document is a snapshot of the current real situation 📸

4. Overview of the current situation of IPv4 addresses 🔮

okay bestie, real talk: IPv4 addresses are no longer all globally unique 😭 and they don't all have indefinite lifetimes anymore either. it's giving plot twist 💀

4.1 Addresses are no longer globally unique locators 🌸

[RFC 1918] shows how corporate networks, a.k.a. Intranets, may legitimately re-use a subset of the IPv4 address space if they need to, which forms multiple routing realms. at the boundary between two (or more) routing realms, we can find a whole spectrum of devices that make communication between the realms possible 🦋

at one end of the spectrum is a pure Application Layer Gateway (ALG). this device is the termination point for the application layer data stream, and an end-user can see it. for example, say an end-user Ua in routing realm A wants to talk to an end-user Ub in routing realm B. Ua has to explicitly establish communication with the ALG that connects A and B first, and only then can Ua reach Ub. we call this a "non-transparent" ALG 🙈

another form of ALG makes the communication through it transparent to the end user. using the same example, with a "transparent" ALG, Ua doesn't have to set up explicit connectivity with the ALG before talking to Ub. the connectivity gets set up transparently, so Ua only ever sees a connection to Ub ✨

for completeness, not every ALG involves changes to the network header 👀 an ALG could be used only at the very beginning of a session, just for authentication, and then it goes away and the communication continues natively.

both non-transparent and transparent ALGs are required (by definition) to understand the syntax and semantics of the application data stream. honestly, ALGs are very simple from the network layer architecture point of view, because they show up as Internet hosts in each realm. they act as the origination and termination points for communication 💅

at the other end of the spectrum is a Network Address Translator (NAT) [RFC 1631]. for this document, we define a NAT as a device that only modifies the network and transport layer headers, and does not understand the syntax or semantics of the application layer data stream. (using our terminology, what RFC1631 describes is a device with both NAT and ALG functionality, so it's a whole combo 🍓)

in the standard case, a NAT sits between a corporate network using private addresses [RFC 1918] and the public Internet. that NAT changes the source IPv4 address in packets heading towards the Internet, and changes the destination IPv4 address in packets coming from the Internet. when a NAT is used to connect routing realms with overlapping addresses, like a direct connection between two intranets, the NAT may modify both addresses in the IP header. since the NAT modifies the address(es) in the IP header, it also has to modify the transport (e.g., TCP, UDP) pseudo-header checksum 🧚 and here's the lowkey wild part: if you look closely, when you interconnect routing realms with overlapping addresses, the set of operations a NAT performs on the network and transport headers forms a (proper) subset of the set of operations a transparent ALG performs on the network and transport layers 🤯

by definition, a NAT doesn't understand the syntax and semantics of an application data stream. so a NAT can't support applications that carry IP addresses at the application layer (e.g., FTP with PORT or PASV command [RFC 959]). on the flip side, a NAT can support any application, as long as that application doesn't carry IP addresses at the application layer. an ALG is different: it can only support the applications that are coded into it 💀

so both NATs and ALGs have their own limitations, and those limitations can constrain how useful they are. combining NAT and ALG functionality in a single device can overcome some of those limitations, but not all of them. such a device would use the NAT functionality for applications that don't carry IP addresses, and fall back on the ALG functionality for applications that do. for example, it would use NAT to handle the FTP data connection, but use ALG to handle the FTP control connection. however, such a device will fail completely on an application that carries IP addresses if the device doesn't support that application through the ALG functionality, and instead tries to handle it through the NAT functionality 😭

communicating through either ALGs or NATs involves changing the network header (specifically the source and destination addresses) and the transport header. IP Security authentication headers assume the addresses in the network header are preserved end-to-end, so it's not clear how you could support IP Security-based authentication between a pair of hosts talking through either an ALG or a NAT. and IP Security, when used for confidentiality, encrypts the entire transport layer end-to-end, so it's also not clear how an ALG or NAT could modify encrypted packets the way they need to. basically, both ALGs and NATs are likely to force a boundary between two distinct IP Security domains, both for authentication and for confidentiality, unless specific enhancements to IP Security are designed for this purpose 🔥

interconnecting routing realms via either ALGs or NATs relies on the DNS [RFC 1035]. specifically, for a given set of (interconnected) routing realms, even if network layer addresses are no longer unique across the set, fully qualified domain names would still need to be unique across the set. however, a site that runs a NAT or ALG probably needs to run two DNS servers, one inside and one outside the NAT or ALG, giving different answers to identical queries. this gets discussed further in [kre]. DNS security [RFC 2065] and some dynamic DNS updates [dns2] will presumably not be valid across a NAT/ALG boundary, so we have to assume the external DNS server gets at least part of its tables some other way 🫶

to sum it up: since RFC 1918, we haven't really changed the spatial uniqueness of an address so much as we've recognized that there are multiple spaces. each space is still a routing realm, like an intranet, which might be connected to other intranets or to the Internet by NATs or ALGs (see the discussion above). the temporal uniqueness of an address is unchanged by RFC 1918 ⭐

4.2. Addresses are no longer all temporally unique ⏳

note that as soon as address significance changes anywhere in the address space, it has in some sense changed everywhere. and honestly? this has already happened 😭

IPv4 address blocks were, for many years, assigned chronologically, i.e. effectively at random with respect to network topology. this led to constantly growing routing tables, and that does not scale 💀 today, hierarchical routing (CIDR [RFC 1518], [RFC 1519]) is used to improve the scaling of routing within a routing realm, and especially within the Internet (The Annex goes into more detail on CIDR) 🎀

the scaling capabilities of CIDR are based on the assumption that address allocation reflects network topology as much as possible. and the boundaries for aggregating addressing information aren't required to be fully contained within a single organization. they may span multiple organizations (e.g., a provider with its subscribers). so if a subscriber changes its provider, then, to avoid injecting extra overhead into the Internet routing system, the subscriber may need to renumber 🍓

changing providers is just one possible reason to renumber. the informational document [RFC 1900] shows why renumbering is an increasingly frequent event. and both DHCP [RFC 1541] and PPP [RFC 1661] promote the use of dynamic address allocation 🌈

to sum it up: since the development and deployment of DHCP and PPP, and since renumbering is expected to become a common event, IP address significance has indeed changed. spatial uniqueness should stay the same, so addresses are still effective locators. temporal uniqueness is no longer assured. it may be quite short, possibly shorter than a TCP connection time. in those cases, an IP address is no longer a good identifier. this has some impact on end-to-end security, and it breaks TCP in its current form 💔

4.3 Multicast and Anycast 📡

since we deployed multicast [RFC 1112], we have to separate the debate over the meaning of IP addresses into the meaning of source and destination addresses. a destination multicast address (i.e. a locator for a topologically spread group of hosts) can traverse a NAT, and it isn't necessarily restricted to an intranet (or to the public Internet). its lifetime can be short too 🦋

the concept of an anycast address is an address that semantically locates any one of a group of systems performing equivalent functions. there's no way such an address can be anything but a locator. it can never serve as an identifier as defined in this document, because it doesn't uniquely identify a host 🙅‍♀️ in this case, the effective temporal uniqueness, or useful lifetime, of an IP address can be less than the time it takes to establish a TCP connection ⏱️

quick note: we used TCP here just to illustrate the idea of an association. lots of UDP-based applications (or other systems layered on IP) allocate state after receiving or sending a first packet, based on the source and/or destination. all of them get affected by the absence of temporal uniqueness, whereas only the routing infrastructure gets affected by changes in spatial uniqueness 💜

4.4 Summary 🌟

due to dynamic address allocation and increasingly frequent network renumbering, the temporal uniqueness of IPv4 addresses is no longer globally guaranteed. that puts their use as identifiers into severe question 😱 due to the proliferation of Intranets, spatial uniqueness is also no longer guaranteed across routing realms. interconnecting routing realms could be done via either ALGs or NATs. in principle, that kind of interconnection will have less functionality than if those Intranets were directly connected. in practice, the difference in functionality may or may not matter, depending on individual circumstances 🫧

5. IPv6 Considerations 🦋

Okay so let's talk IPv6 🧚. For temporal uniqueness (the identifier-like vibe 🫶), the IPv6 model [RFC 1884] is giving the SAME energy as the current IPv4 model, just more so 💅. IPv6 will have mechanisms to autoconfigure IPv6 addresses on IPv6 hosts ✨. Prefix changes are expected, and when a prefix changes, the global IPv6 addresses of every host under that prefix have to change too 😭. So IPv6 is going to amplify the existing problem of finding stable identifiers for end-to-end security and session bindings like TCP state. Not me stressing 💀.

The IAB feels this is unfortunate 🙈. The move to IPv6 would be the perfect moment to give upper layer end-to-end protocols temporally unique identifiers 🎀. What those identifiers actually look like still needs further study 🔍.

For spatial uniqueness (the locator-like vibe), the IPv6 address space is SO big that running short on addresses, the way you'd need an RFC 1918-like approach and address translation, is hardly conceivable 🌈. There's no shortage of IPv6 addresses, and there's also a well-defined mechanism for getting link-local and site-local addresses in IPv6 [RFC 1884, section 2.4.8] 🍓. None of this stops separate routing realms for IPv6 if you want them, which would also mean multiple security domains 🔐. We can't point to a case where multiple IPv6 routing realms are needed right now, but it's also hard to say whether there'll be just one or more than one 🤷‍♀️. If we assume there will be more than one, those realms could be interconnected via ALGs and NATs, and the considerations for those ALGs and NATs look identical to IPv4's 👑.

ANNEX: Current Practices for IPv4 Address Allocation & Routing 📚

Okay, history lesson but make it iconic 🎀. IP address structure and IP routing were originally built around network number classes (Class A/B/C networks) [RFC 790]. Then in the early 90s the Internet grew so fast that it needed big improvements, both in how well the Internet routing system scaled and in how well the IP address space got used 🚀. Classful addressing and the classful routing that came with it just weren't cutting it anymore 😤. So during the 1992 - 1993 period the Internet adopted Classless Inter-Domain Routing (CIDR) [RFC 1380], [RFC 1518], [RFC 1519] ✨. CIDR brings a new address allocation architecture, new routing protocols, and a new structure for IP addresses 💅.

CIDR makes scalability better by stretching hierarchical routing past individual subnets and networks 🌸. Routing info can now be aggregated not just at the subnet and network level, but at the level of individual sites and also at the level of Internet Service Providers 💖. So an organization (site) can act as an aggregator for all the destinations inside it 👑. And a provider can act as an aggregator for all the destinations of its subscribers (organizations directly connected to the provider) 🫶.

Making hierarchical routing work at the level of sites and providers, with them acting as aggregators, meant changing both the address allocation procedures and the routing protocols 🔥. Back in the pre-CIDR days, sites got addresses without any thought about aggregating addressing info above the level of an individual network number 🙈. CIDR-based allocation instead recommends that allocation be done so sites and providers CAN aggregate addressing info, and that kind of allocation is called "aggregator based" 🧚. To get the benefits of "aggregator based" allocation, CIDR brings in an inter-domain routing protocol (BGP-4) [RFC 1771, RFC 1772] that gives sites and providers the tools to aggregate routing info 🌈.

CIDR also improves address space utilization by ditching network classes and replacing them with contiguous, variable size (power of 2) address blocks 🍓. That means the amount of space you request can match the amount you actually get [RFC 1466] 💯. It also makes "aggregator based" allocation possible 🎀. Getting rid of network classes means both intra- and inter-domain routing protocols need new capabilities, and so does IP forwarding 🛠️. Specifically, CIDR-capable protocols have to handle reachability (addressing) info written as variable length address prefixes, and forwarding has to implement the "longest match" algorithm 🧠. The CIDR implications for routing protocols are described in [RFC 1817] 📖.

CIDR's scaling depends on address allocation reflecting network topology as much as possible, especially at the site level and in how sites connect to providers 🗺️. That's what lets sites and providers act as aggregators ✨. If a site changes providers, the site may need to renumber, so it doesn't pile extra overhead onto the Internet routing system 😬. CIDR doesn't require every site that changes providers to renumber, BUT (and this is the scary part 👀) if none of the sites changing providers renumber, the Internet routing system might collapse under the sheer amount of routing info it'd have to handle 💀.

Keeping "aggregator based" allocation (for scalable routing) and letting sites switch providers (for competition) both need practical solutions for renumbering sites 🔄. Containing overhead in a fast-growing Internet routing system makes renumbering more and more common [RFC 1900] 📈.

Scaling the Internet routing system, with CIDR as the main scaling tool, also pushed the evolution of address allocation and management policies for the Internet 🌐. That evolution added "address lending" as an alternative to the "address ownership" policy [RFC 2008] 🤝.

IP addressing and routing have been constantly evolving since IP was first specified [RFC 791] 🦋. Some addressing and routing principles got deprecated, some were kept, and some new ones came in 🌟. Current Internet routing and addresses (based on CIDR) are an evolutionary step that stretches the use of hierarchy to keep a routable global Internet alive 🫶.

Security Considerations 🔐

The impact of the IP addressing model on security is discussed in sections 4.1 and 5 of this document. ⚠️

Acknowledgements 🎀

This document was developed in the IAB. Constructive comments were received from Ran Atkinson, Jim Bound, Matt Crawford, Tony Li, Michael A. Patton, Jeff Schiller. Earlier private communications from Noel Chiappa helped to clarify the concepts of locators and identifiers 💖. Thank you, legends 🫶.

References 📚

[RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

[RFC 790] Postel, J., "Assigned Numbers", September 1981.

[RFC 959] Postel, J., and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.

[RFC 1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.

[RFC 1112] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, September 1989.

[RFC 1380] Gross, P., and P. Almquist, "IESG Deliberations on Routing and Addressing", RFC 1380, November 1992.

[RFC 1466] Gerich, E., "Guidelines for Management of IP Address Space", RFC 1466, May 1993.

[RFC 1498] Saltzer, J., "On the Naming and Binding of Network Destinations", RFC 1498, August 1993 (originally published 1982).

[RFC 1518] Rekhter, Y., and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, September 1993.

[RFC 1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.

[RFC 1541] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541, October 1993.

[RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.

[RFC 1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.

[RFC 1772] Rekhter, Y., and P. Gross, "Application of the Border Gateway Protocol in the Internet", RFC 1772, March 1995.

[RFC 1817] Rekhter, Y., "CIDR and Classful Routing", RFC 1817, September 1995.

[RFC 1825] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, September 1995.

[RFC 1900] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996.

[RFC 1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996.

[RFC 1933] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996.

[RFC 2008] Rekhter, Y., and T. Li, "Implications of Various Address Allocation Policies for Internet Routing", RFC 2008, October 1996.

[kre] Elz, R., et. al., "Selection and Operation of Secondary DNS Servers", Work in Progress.

[RFC 2065] Eastlake, E., and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997.

[dns2] Vixie, P., et. al., "Dynamic Updates in the Domain Name System (DNS UPDATE)", Work in Progress.

Authors' Addresses ✍️

Brian E. Carpenter
Computing and Networks Division
CERN
European Laboratory for Particle Physics
1211 Geneva 23, Switzerland

EMail: brian@dxcoms.cern.ch

Jon Crowcroft
Dept. of Computer Science
University College London
London WC1E 6BT, UK

EMail: j.crowcroft@cs.ucl.ac.uk

Yakov Rekhter
Cisco systems
170 West Tasman Drive
San Jose, CA, USA

Phone: +1 914 528 0090
Fax: +1 408 526-4952
EMail: yakov@cisco.com
📦 where this page comes from