RFC 6250

Evolution of the IP Model

📅 published May 2011, from ietf

1. Introduction ✨

RFC 6250: Evolution of the IP Model 🦋

Written by D. Thaler for the Internet Architecture Board (IAB) 💖

Category: Informational 🎀

Date: May 2011 🌸

ISSN: 2070-1721 ✨

This header doesn't list anything it obsoletes or updates. 🧚

Abstract 🌈

okay so this doc is all about the IP service model and how it's glowed up over time 💅 It looks at the IP layer the way upper-layer protocols and apps actually see it, especially the properties people wrongly assume exist (and sometimes still do 💀), plus the properties that would cause real problems if anyone changed them. The whole discussion is built around checking a set of claims, aka misconceptions 🙈 Last but not least, it gives some guidance for protocol designers and implementers 🫶

Status of This Memo 🍓

This document is not an Internet Standards Track specification. It's published for informational purposes, so no drama 💜

This document is a product of the Internet Architecture Board (IAB). It holds information the IAB decided was valuable enough to keep on the permanent record ✨ Documents the IAB approves for publication are not a candidate for any level of Internet Standard, see Section 2 of RFC 5741 💅

For info about the current status of this document, any errata, and how to give feedback on it, check http://www.rfc-editor.org/info/rfc6250 🔥

Copyright (c) 2011 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, because they spell out your rights and restrictions with respect to this document 🎀

Table of Contents 🧚

   1. Introduction ....................................................3
   2. The IP Service Model ............................................4
      2.1. Links and Subnets ..........................................5
   3. Common Application Misconceptions ...............................5
      3.1. Misconceptions about Routing ...............................5
           3.1.1. Claim: Reachability is symmetric ....................5
           3.1.2. Claim: Reachability is transitive ...................6
           3.1.3. Claim: Error messages can be received in
                  response to data packets ............................7
           3.1.4. Claim: Multicast is supported within a link .........7
           3.1.5. Claim: IPv4 broadcast is supported ..................8
           3.1.6. Claim: Multicast/broadcast is less expensive
                  than replicated unicast .............................8
           3.1.7. Claim: The end-to-end latency of the first
                  packet to a destination is typical ..................8
           3.1.8. Claim: Reordering is rare ...........................9
           3.1.9. Claim: Loss is rare and probabilistic, not
                  deterministic .......................................9
           3.1.10. Claim: An end-to-end path exists at a
                   single point in time ..............................10
           3.1.11. Discussion ........................................10
      3.2. Misconceptions about Addressing ...........................11
           3.2.1. Claim: Addresses are stable over long
                  periods of time ....................................11
           3.2.2. Claim: An address is four bytes long ...............12
           3.2.3. Claim: A host has only one address on one interface 12
           3.2.4. Claim: A non-multicast/broadcast address
                  identifies a single host over a long period of time 13
           3.2.5. Claim: An address can be used as an
                  indication of physical location ....................14
           3.2.6. Claim: An address used by an application is
                  the same as the address used for routing ...........14
           3.2.7. Claim: A subnet is smaller than a link .............14
           3.2.8. Claim: Selecting a local address selects
                  the interface ......................................15
           3.2.9. Claim: An address is part of an on-link
                  subnet prefix ......................................15
           3.2.10. Discussion ........................................15
      3.3. Misconceptions about Upper-Layer Extensibility ............16
           3.3.1. Claim: New transport-layer protocols can
                  work across the Internet ...........................16
           3.3.2. Claim: If one stream between a pair of
                  addresses can get through, then so can another .....17
           3.3.3. Discussion .........................................17
      3.4. Misconceptions about Security .............................17
           3.4.1. Claim: Packets are unmodified in transit ...........17
           3.4.2. Claim: Packets are private .........................18
           3.4.3. Claim: Source addresses are not forged .............18
           3.4.4. Discussion .........................................18
   4. Security Considerations ........................................18
   5. Conclusion .....................................................19
   6. Acknowledgements ...............................................20
   7. IAB Members at the Time of This Writing ........................20
   8. IAB Members at the Time of Approval ............................20
   9. References .....................................................20
      9.1. Normative References ......................................20
      9.2. Informative References ....................................21

1. Introduction ✨

Ever since the Internet Protocol was first published as [IEN028] in 1978, IP has been giving network-layer connectivity to upper-layer protocols and applications 🌸 The basic IP service model was written down in the original IENs (and later in the RFCs that obsolete them). But the mantra has been "Everything Over IP" 💅, so the model has glowed up hard over the past 30 years to enable new behaviors the original definition never imagined 🦋 For example, by 1989 things were already getting confusing, so [RFC1122] clarified a bunch of stuff and extended the model. In 2004, [RFC3819] gave link-layer protocol designers advice on a bunch of issues that affect upper layers, and it's the closest in intent to this document 🫶 Today's IP service model isn't documented in one single place. It's either implicit or scattered across tons of different RFCs 🙈 So, honestly, today's IP service model is not well known, or at least it's often misunderstood 💀

Back in the early days of IP, changing or extending the basic model was way easier, since it wasn't as widely deployed and there were fewer implementations 🧚 Today, the ossification of the Internet makes evolving the IP model even harder 😭 So understanding how the IP model evolved matters for two big reasons:

  1. To clarify which properties upper-layer protocols and applications can and can't depend on. Lots of misconceptions float around about what apps can rely on, and some of them are seriously problematic 👑
  2. To document lessons for future evolution to take into account. The service model needs to stay consistent instead of evolving in two opposing directions 🔥 Sometimes IETF Working Groups today consider, or even take, directions that would change the IP service model. Doing that without understanding the implications for applications can be dangerous 🚨

This RFC is basically documenting the different aspects of the IP service model and how they've changed over time 🌈 In particular, it looks at the properties of the IP layer as upper-layer protocols and applications see them, especially the ones that were (and at times still are) wrongly believed to exist. It also calls out the properties that would cause problems if changed 💖

2. The IP Service Model ✨

In this document, "IP service model" refers to the model IP exposes to higher-layer protocols and applications 💅 It's shown in Figure 1 by the horizontal line 🦋

 +-------------+                                  +-------------+
 | Application |                                  | Application |
 +------+------+                                  +------+------+
        |                                                |
 +------+------+                                  +------+------+
 | Upper-Layer |                                  | Upper-Layer |
 |  Protocol   |                                  |  Protocol   |
 +------+------+                                  +------+------+
        |                                                |
------------------------------------------------------------------
        |                                                |
     +--+--+                  +-----+                 +--+--+
     | IP  |                  | IP  |                 | IP  |
     +--+--+                  +--+--+                 +--+--+
        |                        |                       |
  +-----+------+           +-----+------+          +-----+------+
  | Link Layer |           | Link Layer |          | Link Layer |
  +-----+------+           +--+-----+---+          +-----+------+
        |                     |     |                    |
        +---------------------+     +--------------------+

      Source                                        Destination

                          IP Service Model

                              Figure 1

The foundation of the IP service model today is documented in Section 2.2 of [RFC0791] 🧚 Generally speaking, IP gives you a connectionless delivery service for variable-size packets. It doesn't guarantee ordering, delivery, or lack of duplication. It's merely best effort (although some packets may get better service than others) 🙈 Senders can send to a destination address without signaling a priori, and receivers just listen on an already provisioned address, also without signaling a priori. Very chill, very no-strings-attached 💜

Architectural principles of the IP model are further discussed in [RFC1958] and in Sections 5 and 6 of [NEWARCH] 🌸

Section 2.1 of [RFC4903] discusses the terms "link" and "subnet" with respect to the IP model 🦋

A "link" in the IP service model refers to the topological area within which a packet with an IPv4 Time to Live (TTL) or IPv6 Hop Limit of 1 can be delivered. Put differently, it's where no IP-layer forwarding (which entails a TTL/Hop Limit decrement) occurs between two nodes 🔥

A "subnet" in the IP service model refers to the topological area within which addresses from the same subnet prefix are assigned to interfaces 💅

3. Common Application Misconceptions 💀

Below is a list of properties that applications and upper-layer protocols often assume, but which have become less true over time 🙈 Bestie, this is where the myths get busted 🫶

3.1. Misconceptions about Routing 🌈

3.1.1. Claim: Reachability is symmetric 🦋

okay so a LOT of apps assume that if host A can contact host B, then B can contact A right back 💅 that's the vibe. request-response patterns need reverse reachability only after forward reachability works, and callbacks (like the File Transfer Protocol (FTP) [RFC0959] does) totally rely on it 🙈

originally, reachability was symmetric (the path taken might be different tho 👀), both within a link and across the Internet. then NATs (Network Address Translators) and firewalls showed up and ruined the party 😭 so this can't be assumed anymore. host-to-host connectivity is challenging if not impossible in general. it's pretty easy to start a conversation from hosts (A-E in the example diagram) to servers (S), but not the other way around, and not between A-E either. for a longer chat about peer-to-peer connectivity, check out Appendix A of [RFC5694] 🌸

        __________                                 ___       ___
       /          \             ___        ___    /   \ ____|FW |__A
      /            \    ___    /   \ _____|NAT|__|     |    |___|
     |              |__|NAT|__|     |     |___|  |     |__B
     |              |  |___|  |     |__C          \___/
     |              |          \___/               ___
  S__|   Internet   |           ___        ___    /   \
     |              |   ___    /   \ _____|NAT|__|     |__D
     |              |__|FW |__|     |     |___|  |     |
     |              |  |___|  |     |__E          \___/
      \            /           \___/
       \__________/

                              Figure 2

ok but here's the thing 🫶 if a request can be sent, a reply to that request can generally be received, but an unsolicited request in the other direction may not be received. [RFC2993] goes deeper into this if you're obsessed like me 🤓

there are also links (like satellite) that were defined as unidirectional, so an address on one of those gives you asymmetric reachability. [RFC3077] tackles this for multihomed hosts by tunneling packets over another interface so symmetric reachability gets restored ✨

and finally, even common wireless networks like 802.11 might not hold this assumption, as discussed in Section 5.5 of [WIRELESS] 📡

3.1.2. Claim: Reachability is transitive 🧚

the assumption here is: if host A can contact host B, and B can contact C, then A can contact C. so basically the "my friend can reach you, so you can reach them" logic. applications and protocols that use referrals are the main ones doing this 💜

originally, reachability was transitive, both within a link and across the Internet. with NATs, firewalls, and various routing policies showing up, this can't be assumed across the Internet anymore, but it's often still true within a link. so upper-layer protocols and applications may be relying on transitivity within a link. however, some radio technologies, like 802.11 ad hoc mode, break this assumption within a link. not it 💀

3.1.3. Claim: Error messages can be received in response to data packets 💌

some upper-layer protocols and applications assume ICMP error messages will come back when a packet can't be delivered. examples include Path MTU Discovery [RFC1191] [RFC1981], which relies on "too big" messages, and traceroute plus expanding ring search [RFC1812], which rely on messages saying packets hit their TTL/Hop Limit 🍓

originally this assumption mostly held, but then lots of ICMP senders started rate-limiting their responses to fight denial-of-service attacks, and many firewalls now block ICMP messages entirely. for the longer tea, see Section 2.1 of [RFC2923] ☕

this led to an alternate Path MTU Discovery mechanism that doesn't rely on the assumption being true [RFC4821], plus guidance for firewall admins ([RFC4890] and Section 3.1.1 of [RFC2979]) 🛡️

[RFC1112] brought multicast into the IP service model 🎀 in this evolution, senders still just send to a destination address without signaling a priori, but unlike the original IP model, receivers must signal to the network before they can receive traffic sent to a multicast address.

today, tons of apps and protocols use multicast addresses, including protocols for address configuration and service discovery, etc. (see [MCAST4] and [MCAST6] for the ones using well-known addresses) 🧠

most of these only assume multicast works within a link, and it may or may not work across a wider area. network-layer multicast works over most link types, but there are Non-Broadcast Multi-Access (NBMA) links where it doesn't work (e.g., X.25, ATM, frame relay, 6to4, Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), Teredo), and that can mess with some protocols and apps 😬 similarly, links like 802.11 ad hoc mode might not deliver multicast packets to all receivers on the link. [RFC4861] says:

Note that all link types (including NBMA) are expected to provide multicast service for applications that need it (e.g., using multicast servers).

and its predecessor [RFC2461] had similar wording 📜

but honestly? not all link types today meet that expectation 😤

3.1.5. Claim: IPv4 broadcast is supported 📢

IPv4 broadcast support was originally defined on a link, across a network, and for subnet-directed broadcast, and lots of apps and protocols use it. BUT for security reasons, [RFC2644] deprecated forwarding broadcast packets. so since 1999, broadcast can only be relied on within a link 🚫 still, there are NBMA links where broadcast doesn't work, and some "semi-broadcast" links (like 802.11 ad hoc mode) where broadcast packets might not reach every node on the link. another broadcast fail: when a /32 or /31 is assigned to a point-to-point interface (e.g., [RFC3021]), there's no broadcast address left at all 💔

tbh, link-scoped multicast being added to the IP service model pretty much made broadcast obsolete 🥀 also, the broadcast API model on most platforms lets receivers just listen on an already provisioned address without signaling a priori. but unlike the unicast API model, senders must signal to the local IP stack (SO_BROADCAST) before they can send traffic to a broadcast address. from the network's perspective, though, the host still sends without signaling a priori 🤷‍♀️

3.1.6. Claim: Multicast/broadcast is less expensive than replicated unicast 💸

some apps and upper-layer protocols use multicast or broadcast not because they don't know the receivers' addresses, but just to avoid sending multiple copies of the same packet over the same link 🧃

in wired networks, sending one multicast packet on a link is generally cheaper than sending multiple unicast packets. but this may not be true for wireless networks, where implementations can only send multicast at the basic rate, no matter the negotiated rates of potential receivers 📶 so replicated unicast may get way higher throughput across those links than multicast/broadcast traffic 🚀

3.1.7. Claim: The end-to-end latency of the first packet to a destination is typical ⏱️

lots of apps and protocols pick a destination by sending a message to each candidate, picking the first one to respond, and then using that one for everything after 🏃‍♀️ if the end-to-end latency of the first packet to each destination is atypical, you can end up with a super non-optimal destination, with way longer paths (and more load on the Internet) and lower throughput. yikes 😩

today there are a bunch of reasons this isn't true. first, when sending to a new destination there may be some startup latency from the link-layer or network-layer mechanism in use, like the Address Resolution Protocol (ARP), for instance. also, the first packet may take a different path from the subsequent ones. for example, Mobile IPv6 [RFC3775], Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601], and the Multicast Source Discovery Protocol (MSDP) [RFC3618] send packets on one path, then let themselves immediately switch to a shorter path, which causes a big latency difference 🌈 and the IETF Routing Research Group has various proposals being evaluated right now that result in similar path switching 🔍

3.1.8. Claim: Reordering is rare 🔀

as discussed in [REORDER], [RFC2991], and Section 15 of [RFC3819], reordering has a bunch of effects. for example, it increases buffering requirements (and jitter) in lots of apps and in devices that do packet reassembly 🧩 TCP [RFC0793] is especially affected, because it enters fast-retransmit when three packets are received before a late packet, and that drastically lowers throughput 📉 finally, some NATs and firewalls assume the initial fragment arrives first, so when that's not the case, packets get lost 😵

today there are a number of things that cause reordering. for example, some routers do per-packet, round-robin load balancing, which can cause a LOT of reordering depending on the topology 🌀 another example: when a packet is fragmented at the sender, some hosts send the last fragment first 🙃 and as discussed in Section 3.1.7, protocols that do path switching after the first packet cause deterministic reordering within the first burst of packets 🫠

3.1.9. Claim: Loss is rare and probabilistic, not deterministic 🎲

in the original IP model, senders just send, without signaling the network a priori. and honestly, that works to a degree 😌 in practice, the last hop (and in rare cases, other hops) of the path needs to resolve next hop information (e.g., the link-layer address of the destination) on demand. that results in queuing traffic, and if the queue fills up, some traffic gets dropped 📦 this means bursty sources can be problematic (and a single large packet that gets fragmented becomes such a burst, iykyk). the problem is rarely observed in practice today, either because resolution within the last hop happens super quickly, or because bursty apps are rarer. BUT any protocol that significantly increases such delays or adds new resolutions would be a change to the classic IP model and could adversely impact upper-layer protocols and apps that send bursts of packets ⚠️

also, mechanisms that simply drop the first packet, rather than queuing it, also break this assumption 🙅‍♀️ similar to the result of reordering, they can lead to a highly non-optimal destination being chosen by apps that use the first one to respond. two examples of mechanisms that seem to do this are network interface cards with a "Wake-on-LAN" capability, where any packet matching a specified pattern wakes up a machine in a power-conserving mode, but only after dropping the matching packet 😴, and MSDP, where encapsulating data packets is optional, but doing so lets bursty sources be accommodated while a multicast tree is built back to the source's domain 🌊

3.1.10. Claim: An end-to-end path exists at a single point in time ⏰

okay so in classic IP, applications assume one of two things 🫶: either an end-to-end path exists to a destination, or the packet just gets dropped 💀. IP today also kinda assumes packet delay is pretty short, because the "Time"-to-Live is really just a hop count 🦋. Back in IP's earlier history, the TTL field was also expected to get decremented every second, not just every hop 🙈.

Generally this is still true today ✨. BUT the IRTF Delay Tolerant Networking Research Group is looking into ways for apps to use IP in networks where this assumption isn't true 🧚, like store-and-forward networks (e.g., packets carried by vehicles or animals) 🐎.

3.1.11. Discussion 💅

The reasons the assumptions above are increasingly less true split into two categories 👑: effects caused by attributes of link-layer technologies, and effects caused by network-layer technologies.

RFC 3819 [RFC3819] advises link-layer protocol designers to minimize these effects 🌸. The link-layer causes aren't usually trying to break IP on purpose 🥺. Instead, adding IP over the technology introduces the problem. So where the link-layer protocol itself doesn't do this, designers specifying how IP is defined over such a link protocol should compensate to the maximum extent possible 💖. As examples, [RFC3077] and [RFC2491] compensate for the lack of symmetric reachability and the lack of link-layer multicast, respectively 🔥. In other words, when IP is defined over a link type, the protocol designers should attempt to restore the assumptions listed in this document 🎀. For example, since an implementation can distinguish between 802.11 ad hoc mode versus infrastructure mode, it may be possible to define a mechanism below IP to compensate for the lack of transitivity over such links 🧠.

At the network layer, as a general principle, we believe that reachability is good 🌈. For security reasons ([RFC4948]), though, it's desirable to restrict reachability by unauthorized parties 🔐. IPsec, an integral part of the IP model, gives you one means to do exactly that. Where there are issues with asymmetry, non-transitivity, and so forth, which are not direct results of restricting reachability to only authorized parties (for some definition of authorized), the IETF should attempt to avoid or solve such issues 🫶. Similar to the principle outlined in Section 3.9 of [RFC1958], the general theme when defining a protocol is to be liberal in what effects you accept, and conservative in what effects you cause 💜.

However, being liberal in what effects you accept also means remembering that diagnostics are important, and being too liberal can mask problems 👀. So there's a tussle between wanting to give your own users or applications a better experience and be more successful ([RFC5218]), and wanting to put pressure on getting problems fixed 😤. One solution is a separate "pedantic mode" that can be enabled to see the problems rather than mask them 🤓.

3.2. Misconceptions about Addressing 🏡

3.2.1. Claim: Addresses are stable over long periods of time 🗿

Originally, addresses were manually configured on fixed machines, so addresses were very stable 🖥️. With the glow-up of technologies like DHCP, roaming, and wireless, addresses can no longer be assumed to stay stable for long periods of time 📶. However, the APIs given to applications today typically still assume stable addresses (e.g., address lifetimes aren't exposed to applications that get addresses) 🙃. This can cause problems when addresses become stale 😬.

For example, many applications resolve names to addresses and then cache them without any notion of lifetime 📦. In fact, the classic name resolution APIs don't even give applications the lifetime of entries 💀.

Proxy Mobile IPv6 [RFC5213] tries to restore this assumption to some extent by preserving the same address while roaming around a local area 🏃‍♀️. Roaming between different networks has been a known issue since at least 1980, when [IEN135] proposed a mobility solution. It tried to restore this assumption by adding an additional address that applications can use, which stays stable while roaming anywhere with Internet connectivity 🌍. More recent protocols such as Mobile IPv6 (MIP6) [RFC3775] and the Host Identity Protocol (HIP) [RFC4423] follow in this same vein 🦋.

3.2.2. Claim: An address is four bytes long 📏

Many applications and protocols were designed to only support addresses that are four bytes long 😵. That was enough for IPv4, but the arrival of IPv6 made this assumption invalid, and with the exhaustion of IPv4 address space it will become increasingly less true 📉. There have been some attempts to mitigate this problem, with limited success in constrained cases. For example, "Bump-In-the-Stack" [RFC2767] and "Bump-in-the-API" [RFC3338] try to provide four-byte "IPv4" addresses for IPv6 destinations. They come with many limitations, including (among a number of others) all the problems of NATs 🙈.

3.2.3. Claim: A host has only one address on one interface 🔌

Lots of applications assume this (e.g., by calling a name resolution function such as gethostbyname and then just using the first address returned) 🫠. But it was never really true to begin with, even if it was the common case 🤷‍♀️. Even [RFC0791] states:

... provision must be made for a host to have several physical interfaces to the network with each having several logical Internet addresses.

However, this assumption is increasingly less true today 📱. We have multiple interfaces (e.g., wired and wireless), dual-IPv4/IPv6 nodes, multiple IPv6 addresses on the same interface (e.g., link-local and global), and so on 🌐. Similarly, many protocol specifications such as DHCP only describe operations for a single interface. Obtaining host-wide configuration from multiple interfaces presents a merging problem for nodes in practice 🧩. Too often, Working Groups simply ignore this problem, and applications and users suffer as a result from poor merging algorithms 😭.

One use of protocols such as MIP6 and HIP is to make this assumption somewhat more true. They add an additional "address" that can be the one used by such applications, and the protocol handles the complexity of multiple physical interfaces and addresses 🫶.

3.2.4. Claim: A non-multicast/broadcast address identifies a single host over a long period of time 🎯

Many applications and upper-layer protocols keep a communication session going with a destination over some period of time 💬. If that address gets reassigned to another host, or if it's assigned to multiple hosts and the host where packets arrive changes, those applications can run into problems 😵‍💫.

Also, many security mechanisms and configurations assume you can block traffic by IP address, which implies that a single attacker can be identified by IP address. If that IP address can also identify many legitimate hosts, applying such a block can result in denial of service 🚫.

[RFC1546] introduced the notion of anycast to the IP service model 🌟. It states:

Because anycasting is stateless and does not guarantee delivery of multiple anycast datagrams to the same system, an application cannot be sure that it is communicating with the same peer in two successive UDP transmissions or in two successive TCP connections to the same anycast address. The obvious solutions to these issues are to require applications which wish to maintain state to learn the unicast address of their peer on the first exchange of UDP datagrams or during the first TCP connection and use the unicast address in future conversations.

The issues with anycast are further discussed in [RFC4786] and [ANYCAST] 📚.

Another way multiple hosts end up using the same address is through scoped addresses, as defined for both IPv4 [RFC1918] [RFC3927] and IPv6 [RFC4007] 🗺️. Because such addresses can be reused within multiple networks, hosts in different networks can use the same address. As a result, a host that is multihomed to two such networks can't use the destination address to uniquely identify a peer 😱. For example, a host can no longer use a 5-tuple to uniquely identify a TCP connection. This is why IPv6 added the concept of a "zone index" 💡.

Yet another example: in some high-availability solutions, one host takes over the IP address of another failed host 🦸‍♀️.

See [RFC2101], [RFC2775], and [SHARED-ADDRESSING] for additional discussion on address uniqueness 🔍.

3.2.5. Claim: An address can be used as an indication of physical location 📍

Some applications try to use an address to infer information about the physical location of the host with that address 🕵️‍♀️. For example, geo-location services are often used to provide targeted content or ads 🛍️.

Various forms of tunneling have made this assumption less true, and it will become increasingly less true as the use of IPv4 NATs for large networks keeps increasing 📈. See Section 7 of [SHARED-ADDRESSING] for a longer discussion 📖.

3.2.6. Claim: An address used by an application is the same as the address used for routing 🧭

Some applications assume the address the application uses is the same one used by routing 🤔. For example, some applications use raw sockets to read and write packet headers, including the source and destination addresses in the IP header 🛠️. As another example, some applications make assumptions about locality (e.g., whether the destination is on the same subnet) by comparing addresses 📐.

Protocols such as Mobile IPv6 and HIP specifically break this assumption, in an attempt to restore other assumptions discussed above 🔄. Recently, the IRTF Routing Research Group has been evaluating a number of possible mechanisms. Some would also break this assumption, while others preserve it near the edges of the network and only break it in the core of the Internet 🌐.

Breaking this assumption is sometimes called an "identifier/locator" split 🏷️. However, as originally defined in 1978 ([IEN019], [IEN023]), an address was only a locator, whereas names were defined to be the identifiers. The TCP protocol then used addresses as identifiers, though 🤯.

Finally, in a liberal sense, any tunneling mechanism might be said to break this assumption. In practice, though, applications that make this assumption will keep working, since the address of the inside of the tunnel is still used for routing as expected 🎀.

Okay so, in the classic IP model, a "subnet" is smaller than or equal to a "link" 🧚 Destinations with addresses in the same on-link subnet prefix can be reached with TTL (or Hop Count) = 1. Link-scoped multicast packets and all-ones broadcast packets will be delivered (in a best-effort fashion) to all listening nodes on the link 📡

Subnet broadcast packets will be delivered (in a best-effort fashion) to all listening nodes in the subnet. There have been some efforts in the past (e.g., [RFC0925], [RFC3069]) to allow multi-link subnets and change the above service model, but the adverse impact on applications that have such assumptions recommend against changing this assumption 🙈

[RFC4903] discusses this topic in more detail and surveys a number of protocols and applications that depend on this assumption. Specifically, some applications assume that, if a destination address is in the same on-link subnet prefix as the local machine, then therefore packets can be sent with TTL=1, or that packets can be received with TTL=255, or link-scoped multicast or broadcast can be used to reach the destination. It's giving "I assumed it would work" energy 💅

3.2.8. Claim: Selecting a local address selects the interface 🦋

Some applications assume that binding to a given local address constrains traffic reception to the interface with that address, and that traffic from that address will go out on that address's interface. However, Section 3.3.4.2 of [RFC1122] defines two models: the Strong End System (or strong host) model where this is true, and the Weak End System (or weak host) model where this is not true. In fact, any router is inherently a weak host implementation, since packets can be forwarded between interfaces 🌸

To some extent, this was never true, bestie 😭 There were cases in IPv4 where the "mask" was 255.255.255.255, such as on a point-to-point link where the two endpoints had addresses out of unrelated address spaces, and no on-link subnet prefix existed on the link. However, this didn't stop many platforms and applications from assuming that every address had a "mask" (or prefix) that was on-link. The assumption of whether a subnet is on-link (in which case one can send directly to the destination after using ARP/ND) or off-link (in which case one just sends to a router) has evolved over the years, and it can no longer be assumed that an address has an on-link prefix. In 1998, [RFC2461] introduced the distinction as part of the core IPv6 protocol suite. This topic is discussed further in [ON-OFF-LINK], and [RFC4903] also touches on this topic with respect to the service model seen by applications 👑

3.2.10. Discussion 💜

Section 4.1 of RFC 1958 [RFC1958] states: "In general, user applications should use names rather than addresses".

We emphasize the above point, which is too often ignored. Many commonly used APIs unnecessarily expose addresses to applications that already use names. Similarly, some protocols are defined to carry addresses, rather than carrying names (instead of or in addition to addresses). Protocols and applications that are already dependent on a naming system should be designed in such a way that they avoid or minimize any dependence on the notion of addresses. Literally, names > addresses 🫶

One challenge is that many hosts today do not have names that can be resolved. For example, a host may not have a fully qualified domain name (FQDN) or a Domain Name System (DNS) server that will host its name.

Applications that, for whatever reason, cannot use names should be IP-version agnostic. ✨

3.3. Misconceptions about Upper-Layer Extensibility 🧚

3.3.1. Claim: New transport-layer protocols can work across the Internet 🦋

IP was originally designed to support the addition of new transport-layer protocols, and [PROTOCOLS] lists many such protocols. Iconic history, honestly 📚

However, as discussed in [WAIST-HOURGLASS], NATs and firewalls today break this assumption and often only allow UDP and TCP (or even just HTTP) 🙃

Hence, while new protocols may work from some places, they will not necessarily work from everywhere, such as from behind such NATs and firewalls 💀

Since even UDP and TCP may not work from everywhere, it may be necessary for applications to support "HTTP failover" modes. The use of HTTP as a "transport of last resort" has become common (e.g., [BOSH] among others) even in situations where it is sub-optimal, such as in real-time communications or where bidirectional communication is required. Also, the IETF HyBi Working Group is now in the process of designing a standards-based solution for layering other protocols on top of HTTP. As a result of having to support HTTP failover, applications may have to be engineered to sustain higher latency 😭🔥

3.3.2. Claim: If one stream between a pair of addresses can get through, then so can another 🍓

Some applications and protocols use multiple upper-layer streams of data between the same pair of addresses and initiated by the same party. Passive-mode FTP [RFC0959], and RTP [RFC3550], are two examples of such protocols, which use separate streams for data versus control channels.

Today, there are many reasons why this may not be true. Firewalls, for example, may selectively allow/block specific protocol numbers and/or values in upper-layer protocol fields (such as port numbers). Similarly, middleboxes such as NATs that create per-stream state may cause other streams to fail once they run out of space to store additional stream state 🫠

3.3.3. Discussion 🌷

Section 5.1 of [NEWARCH] discusses the primary requirements of the original Internet architecture, including Service Generality. It states:

This goal was to support the widest possible range of applications, by supporting a variety of types of service at the transport level. Services might be distinguished by speed, latency, or reliability, for example. Service types might include virtual circuit service, which provides reliable, full-duplex byte streams, and also datagram service, which delivers individual packets with no guarantees of reliability or ordering. The requirement for datagram service was motivated by early ARPAnet experiments with packet speech (using IMP Type 3 messages).

The reasons that the assumptions in this section are becoming less true are due to network-layer (or higher-layer) techniques being introduced that interfere with the original requirement. Generally, these are done either in the name of security or as a side effect of solving some other problem such as address shortage. Work is needed to investigate ways to restore the original behavior while still meeting today's security requirements 🔍

3.4. Misconceptions about Security 🔐

3.4.1. Claim: Packets are unmodified in transit 📦

Some applications and upper-layer protocols assume that a packet is unmodified in transit, except for a few well-defined fields (e.g., TTL). Examples of this behavior include protocols that define their own integrity-protection mechanism such as a checksum.

This assumption is broken by NATs as discussed in [RFC2993] and other middleboxes that modify the contents of packets. There are many tunneling technologies (e.g., [RFC4380]) that attempt to restore this assumption to some extent.

The IPsec architecture [RFC4301] added security to the IP model, providing a way to address this problem without changing applications, although transport-mode IPsec is not currently widely used over the Internet 🛡️

3.4.2. Claim: Packets are private 🙈

The assumption that data is private has never really been true. However, many old applications and protocols (e.g., FTP) transmit passwords or other sensitive data in the clear 😬

IPsec provides a way to address this problem without changing applications, although it is not yet widely deployed, and doing encryption/decryption for all packets can be computationally expensive.

3.4.3. Claim: Source addresses are not forged 🕵️‍♀️

Most applications and protocols use the source address of some incoming packet when generating a response, and hence assume that it has not been forged (and as a result can often be vulnerable to various types of attacks such as reflection attacks).

Various mechanisms that restore this assumption include, for example, IPsec and Cryptographically Generated Addresses (CGAs) [RFC3972].

3.4.4. Discussion 🎀

A good discussion of threat models and common tools can be found in [RFC3552]. Protocol designers and applications developers are encouraged to be familiar with that document.

4. Security Considerations 🚨

This document discusses assumptions about the IP service model made by many applications and upper-layer protocols. Whenever these assumptions are broken, if the application or upper-layer protocol has some security-related behavior that is based on the assumption, then security can be affected.

For example, if an application assumes that binding to the IP address of a "trusted" interface means that it will never receive traffic from an "untrusted" interface, and that assumption is broken (as discussed in Section 3.2.8), then an attacker could get access to private information. This is a major "do not ignore" moment, no cap 😱

As a result, great care should be taken when expanding the extent to which an assumption is false. On the other hand, application and upper-layer protocol developers should carefully consider the impact of basing their security on any of the assumptions enumerated in this document.

It is also worth noting that many of the changes that have occurred over time (e.g., firewalls, dropping directed broadcasts, etc.) that are discussed in this document were done in the interest of improving security at the expense of breaking some applications 🔒

5. Conclusion 👑

Because a huge number of applications already exist that use TCP/IP for business-critical operations, any changes to the service model need to be done with extreme care. Extensions that merely add additional optional functionality without impacting any existing applications are much safer than extensions that change one or more of the core assumptions discussed above. Any changes to the above assumptions should only be done in accordance with some mechanism to minimize or mitigate the risks of breaking mission-critical applications. Historically, changes have been done without regard to such considerations and, as a result, the situation for applications today is already problematic. The key to maintaining an interoperable Internet is documenting and maintaining invariants that higher layers can depend on, and being very judicious with changes.

In general, lower-layer protocols should document the contract they provide to higher layers; that is, what assumptions the upper layer can rely on (sometimes this is done in the form of an applicability statement). Conversely, higher-layer protocols should document the assumptions they rely on from the lower layer (sometimes this is done in the form of requirements).

We must also recognize that a successful architecture often evolves as success brings growth and as technology moves forward. As a result, the various assumptions made should be periodically reviewed when updating protocols. 🦋✨

6. Acknowledgements ✨

Huge thank-yous 🫶 to Chris Hopps, Dow Street, Phil Hallam-Baker, and everyone else who had super helpful chats with the authors about the points that led to this doc. Iain Calder, Brian Carpenter, Jonathan Rosenberg, Erik Nordmark, Alain Durand, and Iljitsch van Beijnum also gave really valuable feedback 💜

7. IAB Members at the Time of This Writing 🌸

These are the IAB members at the time this was written:

  • Loa Andersson
  • Gonzalo Camarillo
  • Stuart Cheshire
  • Russ Housley
  • Olaf Kolkman
  • Gregory Lebovitz
  • Barry Leiba
  • Kurtis Lindqvist
  • Andrew Malis
  • Danny McPherson
  • David Oran
  • Dave Thaler
  • Lixia Zhang

8. IAB Members at the Time of Approval 🎀

And these were the IAB members when it got approved:

  • Bernard Aboba
  • Marcelo Bagnulo
  • Ross Callon
  • Spencer Dawkins
  • Russ Housley
  • John Klensin
  • Olaf Kolkman
  • Danny McPherson
  • Jon Peterson
  • Andrei Robachevsky
  • Dave Thaler
  • Hannes Tschofenig

9. References 📚

9.1. Normative References

Okay, these are the normative references, the ones you genuinely need to read to implement this stuff 🤓

  • [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
  • [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
  • [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
  • [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
  • [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
  • [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, August 1999.
  • [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
  • [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.

9.2. Informative References

And these are the informative ones, the extra reading for when you want the full story 🦋

  • [ANYCAST] McPherson, D. and D. Oran, "Architectural Considerations of IP Anycast", Work in Progress, February 2010.
  • [BOSH] Paterson, I., Smith, D., Saint-Andre, P., and J. Moffitt, "Bidirectional-streams Over Synchronous HTTP (BOSH)", XEP 0124, 2010, http://xmpp.org/extensions/xep-0124.html.
  • [IEN019] Shoch, J., "A note on Inter-Network Naming, Addressing, and Routing", IEN 19, January 1978, http://www.rfc-editor.org/ien/ien19.txt.
  • [IEN023] Cohen, D., "On Names, Addresses and Routings", IEN 23, January 1978, http://www.rfc-editor.org/ien/ien23.txt.
  • [IEN028] Postel, J., "Draft Internetwork Protocol Specification", IEN 28, February 1978, http://www.rfc-editor.org/ien/ien28.pdf.
  • [IEN135] Sunshine, C. and J. Postel, "Addressing Mobile Hosts in the ARPA Internet Environment", IEN 135, March 1980, http://www.rfc-editor.org/ien/ien135.txt.
  • [MCAST4] Internet Assigned Numbers Authority, "IPv4 Multicast Addresses", http://www.iana.org/assignments/multicast-addresses.
  • [MCAST6] Internet Assigned Numbers Authority, "INTERNET PROTOCOL VERSION 6 MULTICAST ADDRESSES", http://www.iana.org/assignments/ipv6-multicast-addresses.
  • [NEWARCH] Clark, D., et al., "New Arch: Future Generation Internet Architecture", Air Force Research Laboratory Technical Report AFRL-IF-RS-TR-2004-235, August 2004, http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA426770&Location=U2&doc=GetTRDoc.pdf.
  • [ON-OFF-LINK] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet Model", Work in Progress, February 2008.
  • [PROTOCOLS] Internet Assigned Numbers Authority, "Protocol Numbers", http://www.iana.org/assignments/protocol-numbers.
  • [REORDER] Bennett, J., Partridge, C., and N. Shectman, "Packet reordering is not pathological network behavior", IEEE/ACM Transactions on Networking, Vol. 7, No. 6, December 1999.
  • [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
  • [RFC0925] Postel, J., "Multi-LAN address resolution", RFC 925, October 1984.
  • [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
  • [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
  • [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
  • [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
  • [RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
  • [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
  • [RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
  • [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, January 1999.
  • [RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)", RFC 2767, February 2000.
  • [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
  • [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
  • [RFC2979] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
  • [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, November 2000.
  • [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
  • [RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", RFC 3021, December 2000.
  • [RFC3069] McPherson, D. and B. Dykes, "VLAN Aggregation for Efficient IP Address Allocation", RFC 3069, February 2001.
  • [RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and Y. Zhang, "A Link-Layer Tunneling Mechanism for Unidirectional Links", RFC 3077, March 2001.
  • [RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A. Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)", RFC 3338, October 2002.
  • [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
  • [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
  • [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
  • [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
  • [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004.
  • [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.
  • [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
  • [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005.
  • [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
  • [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
  • [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
  • [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, December 2006.
  • [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
  • [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
  • [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 2007.
  • [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 4948, August 2007.
  • [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
  • [RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful Protocol?", RFC 5218, July 2008.
  • [RFC5694] Camarillo, G. and IAB, "Peer-to-Peer (P2P) Architecture: Definition, Taxonomies, Examples, and Applicability", RFC 5694, November 2009.
  • [SHARED-ADDRESSING] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", Work in Progress, March 2011.
  • [WAIST-HOURGLASS] Rosenberg, J., "UDP and TCP as the New Waist of the Internet Hourglass", Work in Progress, February 2008.
  • [WIRELESS] Kotz, D., Newport, C., and C. Elliott, "The mistaken axioms of wireless-network research", Dartmouth College Computer Science Technical Report TR2003-467, July 2003, http://www.cs.dartmouth.edu/cms_file/SYS_techReport/337/TR2003-467.pdf.

Authors' Addresses 💌

Here's who to reach out to 💖

Dave Thaler
One Microsoft Way
Redmond, WA 98052
USA

Phone: +1 425 703 8835
EMail: dthaler@microsoft.com


Internet Architecture Board

EMail: iab@iab.org
📦 where this page comes from