RFC 1620

Internet Architecture Extensions for Shared Media

📅 published May 1994, from ietf

RFC 1620: Internet Architecture Extensions for Shared Media 🌈

Okay bestie, this one is RFC 1620, and it's Informational, which means it's giving info, not a standard 💅 It was written by B. Braden, J. Postel, and Y. Rekhter, dated May 1994. Braden and Postel are at ISI, Rekhter is at IBM Research, and it's from the Network Working Group. The title block doesn't list any RFCs it obsoletes or updates ✨

Status of This Memo 💅

This memo provides information for the Internet community, fr. It does not specify an Internet standard of any kind, so don't treat it like a rulebook 🙈 Distribution of this memo is unlimited 🦋

Abstract 🌸

The original Internet architecture assumed that each network is labeled with a single IP network number. That assumption can get violated for shared media, including "large public data networks" (LPDNs) 🌐 The architecture still works even when the assumption breaks, but it has no way to prevent multiple host-router and router-router hops through the shared medium 😭 This memo talks through alternative ways to extend the architecture so that some or all of those unnecessary hops get eliminated 🫶

Table of Contents 🧚

   1. INTRODUCTION ..................................................  2
   2. THE ORIGINAL INTERNET ARCHITECTURE ............................  2
   3. THE PROBLEMS INTRODUCED BY SHARED MEDIA .......................  4
   4. SOME SOLUTIONS TO THE SM PROBLEMS .............................  7
      4.1  Hop-by-Hop Redirection ...................................  7
      4.2  Extended Routing ......................................... 11
      4.3  Extended Proxy ARP ....................................... 13
      4.4  Routing Query Messages ................................... 14
      4.5  Stale Routing Information ................................ 14
      4.6  Implications of Filtering (Firewalls) .................... 15
   5. SECURITY CONSIDERATIONS ....................................... 16
   6. CONCLUSIONS ................................................... 17
   7. ACKNOWLEDGMENTS ............................................... 17
   8. REFERENCES .................................................... 18
   Authors' Addresses ............................................... 19

1. INTRODUCTION ✨

This memo is about what shared medium networks mean for the architecture of the TCP/IP protocol suite. General familiarity with the TCP/IP architecture and the IP protocol is assumed, so I'm not explaining the basics 💜

The Internet architecture is founded on what was originally called the "Catenet model" [PSC81] 🧚 Under this model, the Internet (originally dubbed "the Catenet") is formed using routers (originally called "gateways") to interconnect distinct and perhaps diverse networks. An IP host address (more correctly characterized as a network interface address) is formed of the pair (net#,host#). Here net# is a unique IP number assigned to the network (or subnet) the host is attached to, and host# identifies the host on that network (or subnet) 🎀

The original Internet model made the implicit assumptions that each network has a single IP network number, and that networks with different numbers may interchange packets only through routers. Those assumptions may be violated for networks implemented using a common "shared medium" (SM) at the link layer (LL) 💀 For example, network managers sometimes configure multiple IP network numbers (usually subnet numbers) on a single broadcast-type LAN such as an Ethernet 🍓 The large (switched) public data networks (LPDNs), such as SMDS and B-ISDN, form a potentially more important example of shared medium networks 🌈 Any two systems connected to the same shared medium network are capable of communicating directly at the LL, without IP layer switching by routers. This is an opportunity to optimize performance and perhaps lower cost by eliminating unnecessary LL hops through the medium 🔥

This memo discusses how unnecessary hops can be eliminated in a shared medium, while retaining the coherence of the existing Internet architecture 👑 This issue has come up in a number of IETF Working Groups concerned with LPDNs, including IPLPDN, IP over ATM, IDRP for IP, and BGP 🎀 It's time to take a careful look at the architectural issues that need to be solved. The memo first summarizes the relevant aspects of the original Internet architecture (Section 2), then explains the extra-hop problems created by shared media networks (Section 3). Finally, it discusses some possible solutions (Section 4) 💅

2. THE ORIGINAL INTERNET ARCHITECTURE 🦋

We very briefly review the original architecture to introduce the terminology and concepts 🧠 Figure 1 illustrates a typical set of four networks A, ... D, represented traditionally as clouds, interconnected by routers R2, R3, and R4. Routers R1 and R5 connect to other parts of the Internet. Ha, ... Hd represent hosts connected to these networks 🌸

              Ha           Hb           Hc           Hd

              |            |            |            |
              |            |            |            |
             _|_          _|_          _|_          _|_
            (   )        (   )        (   )        (   )
            (Net)        (Net)        (Net)        (Net)
            ( A )        ( B )        ( C )        ( D )
     - R1 --(   )-- R2 --(   )-- R3 --(   )-- R4 --(   )-- R5 --
            (   )        (   )        (   )        (   )
            (___)        (___)        (___)        (___)

             Figure 1.  Example Internet Fragment

It is not necessary to distinguish between network and subnet in this memo. We may assume that there is some address mask associated with each "network" in Figure 1, allowing a host or router to divide the 32 bits of an IP address into an address for the cloud and a host number that is defined uniquely only within that cloud 🧩

An Internet router is connected to local network(s) as a special kind of host 🖥️ Indeed, for network management purposes, a router plays the role of a host by originating and terminating datagrams. However, there is an important difference between a host and a router: the routing function is mostly centralized in the routers, allowing hosts to be "dumb" about routing 😌 Internet hosts are required [RFC-1122] to make only one simple routing decision: is the destination address local to the connected network? If the address is not local, we say it is "foreign" (relative to the connected network or to the host) 🙃

A host sends a datagram directly to a local destination address or (for a foreign destination) to a first-hop router 📦 The host initially uses some "default" router for any new destination address. If the default is the wrong choice, that router returns a Redirect message and forwards the datagram ↩️ The Redirect message specifies the preferred first-hop router for the given destination address. The host uses this information, which it maintains in a "routing cache" [RFC-1122], to determine the first-hop address for subsequent datagrams to the same destination 💌

To actually forward an IP datagram across a network hop, the sender must have the link layer (LL) address of the target. Therefore, each host and router must have some "address resolution" procedure to map IP address to an LL address 🗺️ ARP, used for networks with broadcast capability, is the most common address resolution procedure [Plummer82] 📣 If there is no LL broadcast capability (or if it is too expensive), then there are two other approaches to address resolution: local configuration tables, and "address-resolution servers" (AR Servers) 🛠️

If AR Servers are used for address resolution, hosts must be configured with the LL address(es) of one or more nearby servers 🫶 The mapping information provided by AR Servers might itself be collected using a protocol that allows systems to register their LL addresses, or from static configuration tables 📋 The ARP packet format and the overall ARP protocol structure (ARP Request/ARP Reply) may be suitable for the communications between a host and an AR server, even in the absence of the LL broadcast capabilities; this would ease conversion of hosts to using AR Servers 🦋

The examples in this memo use ARP for address resolution. At least some of the LPDN's that are planned will provide sufficient broadcast capability to support ARP 📡

⚠️ Heads up, bestie: ARP operates at the link layer, while the Redirect and routing cache mechanisms operate at the IP layer of the protocol stack. Don't mix those two up!

To be continued in part 2 💜🧚

3. THE PROBLEMS INTRODUCED BY SHARED MEDIA 🧚

Okay bestie, so Figure 2 is the same setup as Figure 1 🎀 except now networks A, B, C, and D are all chilling inside one shared medium (SM), which is that dashed box around the clouds. 🦋 Networks A through D are now logical IP networks (called LIS's in [Laubach93]) instead of physical ones. Each one may (or may not) be administratively distinct. 💅 The SM gives any two hosts or routers plugged into it direct connectivity, so host Ha can send datagrams straight to host Hd or to router R4. ✨ A router with some but not all of its interfaces on the shared medium is called a "border router", and R1 and R5 are the examples here.

           Ha           Hb           Hc           Hd

           |            |            |            |
      ---- | ---------- | ---------- | ---------- | ----
     |   __|__        __|__        __|__        __|__   |
        (     )      (     )      (     )      (     )
     |  (     )      (     )      (     )      (     )  |
        ( Net )      ( Net )      ( Net )      ( Net )
     |  (  A  )      (  B  )      (  C  )      (  D  )  |
        (     )      (     )      (     )      (     )
     |  (     )      (     )      (     )      (     )  |
        (_____)      (_____)      (_____)      ( ____)
     |    | |          | |          | |          | |    |
      --- | | -------- | | -------- | | -------- | | ---
          | |          | |          | |          | |
    - R1 -   --- R2 ---   --- R3 ---   --- R4 ---   --- R5 ---

Figure 2. Logical IP Networks in Shared Medium

Figure 2 shows the "classical" model from [Laubach93] 🌸, which just means applying the original Internet architecture from earlier straight onto the shared medium. It works, and it's correct, but it's not optimal. 🙈 For example, two hosts on the same logical network (not drawn in Figure 2) would be totally fine, since the source host forwards the datagram directly in a single hop to a host on that same logical network. The original rules also handle any other pair of hosts in Figure 2. Ha would send a datagram to Hd via the four-hop path Ha -> R2 -> R3 -> R4 -> Hd. 😭 The problem is that the classical model ignores the direct Ha -> Hd connectivity the shared medium already offers.

This memo is about mechanisms for getting minimal-hop connectivity when you actually want it. 🔥 BUT, it's not always desirable in a shared medium. Those "extra" hops may be needed so the routers can act as administrative firewalls. 🛡️ When firewall protection isn't required, though, it should be possible to use the shared medium and let the datagram take the shorter path. Basically, it should be possible to choose between firewall security and efficient connectivity. This is discussed further in Section 4.6 below. 👑

We also need to note that these mechanisms can only optimize the path within the local SM. 🌈 When the SM is only one segment of the path between source and receiver, removing hops locally may stop you from switching to globally better paths that show up after routing changes. Consider Ha->...Hx, where host Hx sits outside the SM that Ha is attached to. Say the shortest global path to Hx goes through some border router Rb1. Local optimization (the techniques below) will remove the extra hops inside the SM and give you Ha->Rb1->...Hx. ✨ Now imagine a later route change outside the SM makes Ha->Rb2->...Hx the better global path, where Rb2 is another border router. 💀 Ha doesn't take part in the routing protocol, so it has no idea it should switch to Rb2. Rb2 might not realize it either. This is the situation:

GC(Ha->Rb2->...Hx) < GC(Ha->Rb1->Rb2->...Hx) < GC(Ha->Rb1->...Hx)

Here GC() stands for some global cost function of the specified path.

Note that ARP requires LL broadcast. 📢 Even if the SM supports broadcast, admins will probably put up firewalls to keep broadcasts local to their LIS. 🧱

There are three cases to optimize. 🎯 Say H and H' are hosts and Rb and Rb' are border routers connected to the same SM. Then the following one-hop paths should be possible:

H -> H':  Host to host within the SM

H -> Rb: Host to exit router

Rb -> Rb': Entry border router to exit border router,
            for transit traffic.

We may or may not be able to remove the extra hop implicit in Rb -> R -> H, where Rb, R, and H are all within the same SM but the ultimate source is outside it. 🤷‍♀️ Removing that hop would mean distributing host routes, not just network routes, between routers R and Rb. That would hurt routing scalability, which is a big no. 🚫

There are a number of important requirements for any architectural solution to these problems. 📋

  • Interoperability
    • Modified hosts and routers must interoperate with unmodified nodes.
  • Practicality
    • Minimal software changes should be required.
  • Robustness
    • The new scheme must be at least as robust against errors in software, configuration, or transmission as the existing architecture.
  • Security
    • The new scheme must be at least as securable against subversion as the existing architecture.

The host vs. router distinction is a huge deal from an engineering viewpoint. 🥺 A global change to host software is way harder than changing router software, because there are many more hosts and host vendors than routers and router vendors, and hosts are less centrally administered than routers. If we have to change what a host does (and we do), then we must minimize how big that change is. 🫶

4. SOME SOLUTIONS TO THE SM PROBLEMS 🎀

Four different approaches have been suggested for solving these SM problems. 💖

(1) Hop-by-Hop Redirection In this approach, the host Redirect mechanism gets extended to collapse multiple-hop paths within the same shared medium, hop-by-hop. 🦋 A router is allowed to send, and a host allowed to accept, a Redirect message that specifies a foreign IP address within the same SM. This is called a "foreign Redirect". Section 4.1 breaks this approach down in detail.

(2) Extended Routing Routing protocols can be modified to know about the SM and to provide LL addresses. 🗺️

(3) Extended Proxy ARP This is a form of the proxy ARP approach, where the routing problem gets solved implicitly by an extended address resolution mechanism at the LL. 🧚 It was described by Heinanen [Heinanen93] and by Garrett et al [Garratt93].

(4) Route Query Messages This approach was suggested by Halpern [Halpern93]. 🔍 Instead of adding info to routing, it adds a new IP-layer mechanism that uses end-to-end query and reply datagrams.

We'll go through these four in the next four subsections. ✨

4.1 Hop-by-Hop Redirection 🦋

The first scheme we look at operates at the IP layer. 💅 It cuts out extra hops one by one, with each router in the path working on local information only. This approach needs both host and router changes, but no routing protocol changes. Iconic, right?

The basic idea is that the first-hop router, once it sees the next hop is inside the same SM, sends a foreign Redirect to the source and points it at that next hop. 🔥 Each intermediate router running this algorithm in turn will eventually produce a direct path from source host to destination host, as long as both are in the same SM. 👑

Say Ha wants to send a datagram to Hd. 🌸 We use IP.a for the IP address of entity a, and LL.a for its corresponding LL address. Each line below shows an IP datagram and the path it follows, separated by a colon. The notation Redirect( h, IP.a) means a Redirect specifying IP.a as the best next hop to reach host h.

(1)  Datagram 1: Ha -> R2 -> R3 -> R4 -> Hd
(2)  Redirect(Hd, IP.R3): R2 -> Ha
(3)  Datagram 2: Ha -> R3 -> R4 -> Hd
(4)  Redirect(Hd, IP.R4): R3 -> Ha
(5)  Datagram 3: Ha -> R4 -> Hd
(6)  Redirect(Hd, IP.Hd): R4 -> Ha
(7)  Datagram 4: Ha -> Hd

To make hop-by-hop redirection work, there are three problems to solve. 🧩 We're labelling them HH1, HH2, and HH3.

HH1: Each router must be able to resolve the LL address of the source Ha, to send a (foreign) Redirect. 🕵️‍♀️

Let's assume the link layer provides the source LL address when an IP datagram arrives. If the router decides a Redirect should be sent, it goes to the source LL address of the received datagram. Simple and clean. 💖

HH2: A source host must be able to perform address resolution to obtain the LL address of each router to which it is redirected. 📬

Each router R could, when it sends a Redirect to Ha, also send an unsolicited ARP Reply point-to-point to LL.Ha, updating Ha's ARP cache with LL.R. 🎀 BUT there's no guarantee that this unsolicited ARP Reply gets delivered. If it's lost, you get a forwarding black hole. 🕳️ The host could recover by starting over from the original default router, but that may be way too inefficient. 😩

A much more direct and efficient fix would be an extended ICMP Redirect message (call it XRedirect) that carries the LL address as well as the IP address of the target. 🙌 This takes care of the reliable-delivery worry with the unsolicited ARP, because the fate of the LL address is shared with the IP target address. Both get delivered, or neither does. (An XRedirect is essentially the same as a Redirect in the OSI ES-IS protocol.) 🤓

Using XRedirect, the previous example becomes:

(1)  Datagram 1: Ha -> R2 -> R3 -> R4 -> Hd
(2)  XRedirect(Hd, IP.R3, LL.R3): R2 -> Ha
(3)  Datagram 2: Ha -> R3 -> R4 -> Hd
(4)  XRedirect(Hd, IP.R4, LL.R4): R3 -> Ha
(5)  Datagram 3: Ha -> R4 -> Hd
(6)  XRedirect(Hd, IP.Hd, LL.Hd): R4 -> Ha
(7)  Datagram 4: Ha -> Hd

HH3: Each router should be able to recognize when it is the first hop in the path, since a Redirect should be sent only by the first hop router. 🫣

This is only possible if the LL address corresponding to the IP source address has been cached from an earlier event. A router in this chain figures out the source's LL address from the arriving datagram (see HH1 above). If it can't determine whether it's the first hop, a router must always send an [X]Redirect. 😬 That one will be spurious if the router isn't the first hop. ✨

Okay so these spurious [X]Redirects 💀 still get sent to the IP address of the source host ✨, but they carry the LL address of the previous-hop router 🦋. The propagation scope of [X]Redirects can be limited to a single IP hop (see below), so they go no further than the previous-hop router, where they get tossed 🗑️. However, there is still some router overhead to process these useless [X]Redirects.

Next up, we're talking about the host and router changes needed for hop-by-hop redirection 🎀.

Host Changes 💖

The Host Requirements RFC [RFC-1122] describes how a host routes an outbound datagram: it sends it straight to a local destination, or else to the first hop router when the destination is foreign [RFC-1122 3.3.1]. Even though this mechanism assumes a local address, a foreign address for a first-hop router should work just as well 💅.

The target address in the routing cache gets updated by Redirect messages 🔄. Right now there's a restriction on which target addresses can be accepted from Redirect messages [RFC-1122 3.2.2.2], and that would block foreign Redirects from working 🙅‍♀️:

A Redirect message SHOULD be silently discarded if the new router address it specifies is not on the same connected (sub-) net through which the Redirect arrived, or if the source of the Redirect is not the current first-hop router for the specified destination.

To support foreign Redirects, you just remove the first validity check ✂️. The second check stays: an acceptable Redirect has to come from the node that the triggering datagram was sent to. The same validity check would be used for XRedirects.

To send a datagram to the target address in the routing cache, a host must resolve the IP address into a LL address. No change should be necessary in the host's IP-to-LL resolution mechanism to handle a foreign rather than a local address 🫶.

Hop-by-hop redirection changes the semantics of the IP address that an ICMP Redirect is allowed to carry 🤯. Under the present definition [Postel81b], an ICMP Redirect message can only carry the IP address of a router. For hop-by-hop redirection to eliminate all router hops, letting two hosts on the same SM talk directly, a [X]Redirect message has to be able to carry the IP address of the destination host 🧚.

Router Changes 🛣️

The router changes for hop-by-hop redirection are way more extensive than the host changes 😭. The examples from earlier showed the extra router functions that would be needed.

Consider a router connected to an SM. When it receives a datagram from the SM, it tests whether the next hop is on the same SM. If it is, it sends a foreign XRedirect to the source host, using the link layer address the datagram arrived with 📬.

A router should avoid sending more than a limited number of successive foreign Redirects to the same host 🚦. This is necessary because an unmodified host may legitimately ignore a Redirect to a foreign network and keep forwarding datagrams to the same router 🙃. A router can accomplish this limit by keeping a cache of the foreign Redirects it has sent.

Note that foreign Redirects generated by routers under these rules, like the current local Redirects, may travel exactly one link-layer hop. It is therefore reasonable and desirable to set their TTL to 1, so they cannot stray outside the SM 🔒.

The extra check needed to determine whether to generate a Redirect may add processing and cause a performance degradation ⚡. To avoid this, a router may skip the check entirely and just forward the packet. The [X]Redirect scheme is not applicable to such a router 🙅.

Finally, hop-by-hop redirection is only applicable when the source host is connected to an SM, since routers do not listen to Redirects 🎧. To optimize the forwarding of transit traffic between entry and exit border routers, an extension to routing is required, as discussed in the following section ✨. An extension to the routing protocol cannot be used to optimize forwarding traffic from a host connected to the SM, though, since a host should not listen to routing protocols 💀.

4.2. Extended Routing 🛤️

The routing protocols may be modified to carry additional information that is specific to the SM 🗺️. The router could use the attribute "SameSM" for a route to deduce the shortest path to be reported to its neighbors. It could also carry the LL addresses with each router IP address.

For example, the extended routing protocol would allow R2 to know that R4 is the best next-hop to reach the destination network in the same SM, and to know both IP.R4 and LL.R4, leading to the path Ha->R2->R4->Hb. Further optimization cannot be done with extended routing alone, since the host does not participate in routing, and because we want the routing protocol to handle only per-network information, not per-host information. Hop-by-hop redirection could then be used to eliminate all router hops, as in the following sequence:

    (1) Datagram 1: Ha -> R2 -> R4 -> Hd

    (2) XRedirect(Hd, IP.R4, LL.R4): R2 -> Ha

    (3) Datagram 2: Ha -> R4 -> Hd

    (4) XRedirect(Hd, IP.Hd, LL.Hd): R4 -> Ha

    (5) Datagram 3: Ha -> Hd

There are three aspects to the routing protocol extension:

  • (1) the ability to pass "third-party" information -- a router should be able to specify the address (IP address and perhaps LL address) of some other router as the next-hop;
  • (2) knowledge of the "SameSM" attribute for routes; and
  • (3) knowledge of LL addresses corresponding to IP addresses of routers within the same SM.

A router must be able to determine that a particular IP address (e.g., the source address) is in the same SM. There are several possible ways to make this information available to a router in the SM 🕵️.

  • (1) A router may use a single physical interface to an SM; this implies that all its logical interfaces lie within the same SM.
  • (3) There might be some administrative structure in the IP addresses, e.g., all IP addresses within a particular national SM might have a common prefix string.
  • (3) There might be configuration information, either local to the router or available from some centralized server (e.g, the DNS). Note that a router could consult this server in the background while continuing to forward datagrams without delay. The only consequence of a delay in obtaining the "SameSM" information would be some unnecessary (but temporary) hops.
the original really numbers that list (1), (3), (3) 💀 we kept it exactly like that so nothing gets lost in translation, bestie

4.3. Extended Proxy ARP 🧚‍♀️

The approach of Heinanen [Heinanen93] was intended to solve the problem of address resolution in a shared medium with no broadcast mechanism ("Non-Broadcast, MultiAccess" or NBMA) 🙌. Imagine the shared medium has a single IP network number, so it's one network "cloud" ☁️. Heinanen envisions a set of AR Servers within this medium, and these AR Servers run some routing protocol among themselves. A source host issues an ARP Request (via a point-to-point LL transmission) to an AR Server it's associated with. This ARP Request is forwarded hop-by-hop at the link layer through the AR Servers, toward the AR Server associated with the destination host. That AR Server resolves the address (using information learned from either host advertisement or a configuration file), and returns an ARP Reply back through the AR Servers to the source host 📮.

              Ha           Hb           Hc           Hd

              |            |            |            |
         ---- | ---------- | ---------- | ---------- | ----
        (                                                  )
        (        Shared Medium (One Logical Network)       )
        (                                                  )
         ----|--|---------|------------|----------|----|---
             |  |         |            |          |    |
       - R1 -   |         |            |          |    --- R5 ---
            ____|__     __|____      __|____     _|_____
           | AR Sa |   | AR Sb |    | AR Sc |   | AR Sd |
           |_______|   |_______|    |_______|   |_______|

Figure 3. Single-Cloud Shared Medium

Figure 3 suggests that each of the hosts Ha, ... Hd is associated with a corresponding AR Server "AR Sa", ..."AR Sd".

This same scheme could be applied to the LIS model of Figure 2 🧠. The AR Servers would be implemented in the routers, and if the medium supports broadcast then the hosts would be configured for proxy ARP. That is, the host would be told that all destinations are local, so it will always issue an ARP request for the final destination. The set of AR Servers would resolve this request.

Since routing loops are a constant possibility 🔁, Heinanen's proposal includes the addition of a hop count to ARP requests and replies.

Like all proxy ARP schemes, this one has a seductive simplicity 😌. However, solving the SM problem at the LL has several costs 💸. It requires a complete round-trip time before the first datagram can flow. It requires a hop count in the ARP packet. This seems like a tip-off that the link layer may not be the most appropriate place to solve the SM problem 👀.

4.4. Routing Query Messages 🔍

This scheme [Halpern93] introduces a new IP level mechanism: SM routing query and reply messages 📩. These messages are forwarded as IP datagrams hop-by-hop in the direction of the destination address. The exit router can return a reply, again hop-by-hop, that finally reaches the source host as an XRedirect. It would also be possible (but not necessary) to modify hosts to initiate these queries.

The query/reply pair is supplying the same information that we would add to routing protocols under Extended Routing 🧩. However, the Query/Reply messages would allow us to keep the current routing protocols unchanged, and would also provide the extra information only for the routes that are actually needed, thus reducing the routing overhead 📉. Note that the Query/Reply sequence can happen in parallel with forwarding the initial datagram hop-by-hop, so it does not add an extra round-trip delay ⏩.

4.5. Stale Routing Information ⏳

We must consider what happens when the network topology changes 👀 The extended routing trick (see Section 4.2) can give you pretty solid assurances that stale info gets purged from the system within the convergence time of whatever routing protocol you're running ✨

BUT the other three techniques (hop-by-hop redirection, extended Proxy ARP, and routing query messages) only give you minimal-hop forwarding as long as the topology stays the same since the info was acquired 😬 If the minimal-hop path changes, the first-hop router might not be the right pick anymore. If the host using that first-hop router doesn't know about the change, it could end up on a path that's now suboptimal, maybe even highly sub-optimal, in terms of hop count 💀

Also, using info from extended Proxy ARP or routing query messages to optimize routing between routers on the same SM is highly problematic 🙈 Stale info sitting on routers could cause forwarding loops that might persist for as long as the info isn't purged. Neither approach handles stale info properly 😭

4.6. Implications of Filtering (Firewalls) 🧱

For a bunch of reasons, an admin of a LIS may put up IP Layer firewalls (IP-layer filtering) to constrain LL connectivity between the hosts/routers in the LIS and the hosts/routers in other LISs within the same SM 🔒 To avoid disruption in forwarding, the mechanisms in this document need to take these firewalls into account.

Using [X]Redirects requires a router that generates an [X]Redirect to be super aware of possible LL connectivity constraints between the router that's specified as the Next Hop in the Redirect and the host that's the target of the Redirect 🎯

Using extended routing requires a router that originates and/or propagates "third-party" information to be cognizant of possible LL connectivity constraints 🧠 Specifically, a router should not propagate "third-party" information when there is a lack of LL connectivity between the router depicted by the information and the router that's the immediate recipient of that information 🙅‍♀️

Using extended proxy ARP requires an ARP Server not to propagate an ARP Request to another ARP server if there are LL connectivity constraints between the originator of the ARP Request and that other ARP server 🚫

Using SM routing query and reply messages requires the routers that pass the messages to be aware of possible LL connectivity constraints. The flow of messages need to reflect these constraints 🌊

5. Security Considerations 🔐

We should discuss the security issues raised by our suggested changes. We should note that we are not talking about "real" security here 🙃 Real Internet security will require cryptographic techniques on an end-to-end basis. However, it should not be easy to subvert the basic delivery mechanism of IP to cause datagrams to flow to unexpected places 🚨

With that understanding, the security problems show up in two places: the ICMP Redirect messages and the ARP replies 👀

ICMP Redirect Security 🛡️

We may reasonably require that the routers be secure. They're generally under centralized administrative control, and we may assume that the routing protocols will contain sufficient authentication mechanisms (even if that isn't currently true). Therefore, a host can reasonably trust a Redirect that comes from a router 💅

However, it will NOT be reasonable for a host to trust another host 😤 Suppose that the target host in the examples of Section 4.1 is untrustworthy. There's no way to prevent it from issuing a new Redirect to some other destination, anywhere in the Internet 😭 On the other hand, this exposure is no worse than it was. The target host, once subverted, could always act as a hidden router to forward traffic elsewhere 🕵️‍♀️

ARP Security 🕸️

Currently, an ARP Reply can only come from the local network, and a physically isolated network can be administratively secured from subversion of ARP 🔐 However, an ARP Reply can come from anywhere within the SM, and an evil-doer can use this fact to divert the traffic flow from any host within the SM [Bellovin89] 💀

The XRedirect closes this security hole 🙌 Validating the XRedirect (as coming from the node to which the last datagram was sent) will also validate the LL address ✅

Another approach is to validate the source address from which the ARP Reply was received (assuming the link layer protocol carries the source address and the driver supplies it). An acceptable ARP reply for destination IP address D can only come from LL address x, where the routing cache maps D -> E and the ARP cache gives x as the translation of E. This validation, involving both routing and ARP caches, might be ugly to implement in a strictly-layered implementation 🥴 It would be natural if layering were already violated by combining the ARP cache and routing cache 🫠

It's possible for the link layer to have security mechanisms that could interfere with IP-layer connectivity. In particular, there could possibly be non-transitivity of logical interconnection within a shared medium. For example, some large public data networks may include configuration options that could allow Net A to talk to Net B and Net B to talk to Net C, but prevent A from talking directly to C 🙃 In this case, the routing protocols have to be sophisticated enough to handle such anomalies 🧩

6. Conclusions 🎉

We've discussed four possible extensions to the Internet architecture to allow hop-efficient forwarding of IP datagrams within shared media, when this optimization is allowed by IP-layer firewalls 💖 We do not draw any conclusions in this paper about the best mechanisms 🤷‍♀️

Our suggested extensions are evolutionary, leaving intact the basic ideas of the current Internet architecture 🌸 It would be possible to make (and some have suggested) much more radical changes to accommodate shared media. In the extreme, one could entirely abolish the inner clouds in Figure 2, so that there would be no logical network structure within the SM. The IP addresses would then be logical, and some mechanism of distributed servers would be needed to find routes within this random haze 🌫️ We think this approach ignores all the requirements for management and security in today's Internet. It might make a good research paper, but it would not be good Internet design strategy 💅

7. Acknowledgments 🫶

We are grateful to Keith McGloghrie, Joel Halpern, and others who rubbed our noses in this problem 😭 We also acknowledge Tony Li (cisco), Greg Minshall (Novell), and John Garrett (AT&T) for their review and constructive comments 💜 We are also grateful to Gerri Gilliland, who supplied the paper tablecloth, colored crayons, and fine food that allowed these ideas to be assembled initially 🍓

8. References 📚

[Bellovin89] Bellovin, S., "Security Problems in the TCP/IP Protocol Suite", ACM CCR, v. 19. no. 2, April 1989.

[Garrett93] Garrett, J., Hagan, J. and J. Wong, "Directed ARP", RFC 1433, AT&T Bell Laboratories, University of Pennsylvania, March 1993.

[Plummer82] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37, RFC 826, MIT, November 1982.

[Halpern93] Halpern, J., Private Communication, July 1993.

[Heinanen93] Heinanen, J., "NBMA Address Resolution Protocol (NBMA ARP)", Work in Progress, June 1993.

[Laubach93] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, Hewlett-Packard Laboratories, January 1994.

[Postel81a] Postel, J., "Internet Protocol - DARPA Internet Program Protocol Specification", STD 5, RFC 791, DARPA, September 1981.

[Postel81b] Postel, J., "Internet Control Message Protocol- DARPA Internet Program Protocol Specification", STD 5, RFC 792, ISI, September 1981.

[PSC81] Postel, J., Sunshine, C., and D. Cohen, "The ARPA Internet Protocol", Computer Networks 5, pp. 261-271, 1983.

[RFC-1122] Braden, R., Editor, "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, USC/Information Sciences Institutue, October 1989.

Authors' Addresses 💌

     Bob Braden
     Information Sciences Institute
     University of Southern California
     4676 Admiralty Way
     Marina del Rey, CA 90292

     Phone: (310) 822-1511
     EMail: Braden@ISI.EDU


     Jon Postel
     Information Sciences Institute
     University of Southern California
     4676 Admiralty Way
     Marina del Rey, CA 90292

     Phone: (310) 822-1511
     EMail: Postel@ISI.EDU


     Yakov Rekhter
     Office 32-017
     T.J. Watson Research Center, IBM Corp.
     P.O. Box 218,
     Yorktown Heights, NY 10598

     Phone: (914) 945-3896
     EMail: Yakov@WATSON.IBM.COM
📦 where this page comes from