RFC 925

Multi-LAN Address Resolution 🎀

okay bestie, this one is RFC 925 💖, written by J. Postel at ISI and dated October 1984 🧚. It's part of the Network Working Group 🌸. The header doesn't list a category or status, and it doesn't say it obsoletes or updates any other RFC, so there's nothing else to chase down 💅. This is part 1 of 3 📖.

---

STATUS OF THIS MEMO ✨

This memo was prompted by RFC-917 by Jeffery Mogul on "Internet Subnets". In that memo, Mogul makes a case for "explicit subnets" in a multi-LAN environment. In this memo, Postel tries to make a case for "transparent subnets" 🦋. This RFC suggests a proposed protocol for the ARPA-Internet community, and it requests discussion and suggestions for improvements 💬. Distribution of this memo is unlimited 🌈.

INTRODUCTION 🌷

Treating a set of local area networks (LANs) as one Internet network has gotten some interest and concern 👀. It's inappropriate to give each LAN within a site its own distinct Internet network number 🙅‍♀️. It's desirable to hide the details of how the LANs are interconnected within a site from people, gateways, and hosts outside that site 🔒. The question is how to do this best, and even whether it can be done at all 😭.

One proposal is to use "explicit subnets" [1]. The explicit subnet scheme is basically a call to recursively apply the mechanisms the Internet uses to manage networks to the problem of managing LANs inside one network 🔁. Postel urges a different approach here: "transparent subnets", supported by a multi-LAN extension of the Address Resolution Protocol [2] 💅.

OVERVIEW 🌸

Quick refresher on the Address Resolution Protocol (ARP) 🧠. Each host on a broadcast LAN knows both its own physical hardware address (HA) on the LAN and its own Internet Address (IA) 🫶. When Host-A is given the IA of Host-B and told to send a datagram to it, Host-A must find the HA that corresponds to Host-B's IA 🎯. To do this, Host-A forms an ARP packet that contains its own HA and IA, plus the IA of the destination host (Host-B) 📦. Host-A broadcasts this ARP packet 📢. The hosts that receive it check whether they're the destination sought 👑. If they are, they (it should only be Host-B) send a reply addressed specifically to the originator of the query (Host-A), supplying the HA that was needed ✨. Now Host-A has both the HA and the IA of the destination (Host-B) 🥳. Host-A adds this info to a local cache for future use 🗂️.

Note: The ARP is actually more general purpose than this brief sketch indicates.

The idea in this memo is to extend ARP so it works in an environment of multiple interconnected LANs 🌐.

So let's imagine a "magic box" (BOX) that's connected as if it were an ordinary host to two (or more) LANs 🪄.

Hosts keep behaving exactly the way they do with basic ARP 🙌.

When any host broadcasts an ARP query, the BOX reads it (just like all the other hosts on that LAN do) 👀. On top of checking whether it's the host sought (and replying if so), the BOX checks its cache of IA:HA address mappings, the cache it keeps for each LAN it's attached to 🗃️.

Case 1: If the mapping for the host is in the cache for the LAN the query came from, the BOX does not respond, and lets the sought host respond for itself 🙈.

Case 2: If the mapping for the host is in the cache for a different LAN than the one the query came from, the BOX sends a reply giving its own HA on the LAN the query came from 🎭. The BOX acts as an agent for the destination host 🫡.

Case 3: If the mapping isn't found in any of the caches, the BOX must try to find out the address, and then respond as in Case 1 or Case 2 💀. This is where the BOX has to do some magic ✨.

For Case 3, the BOX keeps a search list of sought hosts 📝. Each entry includes the IA of the host sought, the interface the ARP was received on, and the source addresses of the original request 🧾. When Case 3 happens, the search list gets checked 🔍. If the sought host is already listed, the search is terminated 🛑. If it's not, the search gets propagated 📡.

To propagate the search, an entry is first made on the search list, and then the BOX composes and sends an ARP packet on each of its interfaces except the interface the instigating ARP packet was received on 🚀. If a reply comes back, the info gets entered into the appropriate cache, the entry is deleted from the search list, and a response to the search-instigating ARP is made as in Case 1 or Case 2 🎉. If no reply comes back, the BOX gives up and does nothing, so no response goes to the instigating host, and the entry stays on the search list 😔.

To terminate the search, the BOX gives up and does nothing 🙃. No response goes to the instigating host, and the entry stays on the search list 📌.

The entries in the caches and the search list must time out ⏳.

For every ARP request that's received, the BOX must also put the sending host's IA:HA address mapping into the cache for the LAN it was received on 💜.

When handling regular datagrams, the BOXes must decrement the IP datagram Time-To-Live field (TTL) and update the IP header check sum. If the TTL hits zero, the datagram gets discarded and is not forwarded. 💀

ARP, as currently defined, treats the most recent information as the best and most up-to-date. 🙈 In a messy multi-LAN setup with loops in the connectivity, you can easily get two (or more) responses to an ARP request for a host on some other LAN. The first response will probably come from the BOX on the most efficient path. ✨

The one change suggested for the host implementation of ARP is to stop later responses from replacing the mapping recorded from the first response. 🎀

Potential Problems

Bad Cache Entries

If some wrong information gets into a cache entry, it stays there for time T3. 😭 That lingering old info could block communication (for a while) if a host changed its IA:HA mapping. Not ideal, bestie.

One way to replace bad or out-of-date entries would be for the BOXes to explicitly interpret a broadcast ARP reply as requiring any entry with either this IA or HA to be replaced by this new IA:HA mapping. 🦋 Another idea is to have important servers send a broadcast ARP reply when they come up. 🌸

Non-ARP Hosts

It seems unrealistic to expect ARP hosts and non-ARP hosts on the same LAN to communicate with each other. 💅 If all the non-ARP hosts are on the same LAN, that situation is covered under the next heading (Non-Broadcast LANs).

Hosts that do not implement ARP must use some other means of address mapping. They either hold a complete table of all hosts, access some such table in a server via some protocol, or expect to make all routing decisions based on analysis of address fields. 🧚

Non-Broadcast LANs

BOXes connected to LANs that lack broadcast capability, and/or LANs where the hosts don't respond to ARP, may have a static or dynamic table of the IA:HA mappings for that LAN. The addresses may also be computed from one another. 🌈 All the hosts on that LAN must be in the table.

When a BOX needs to find the address mapping and would otherwise send an ARP request into a non-broadcast LAN (this can only happen when the sought host is not on that non-broadcast LAN, since all the hosts are in the table), it must instead send an ARP type request specifically to each of the other BOXes on that LAN. 👑

Size of Tables

The worst case for the size of the tables in the BOXes is the number of hosts in the set of LANs for each table. ⭐ So the table kept for each LAN interface may (in the worst case) grow to have an entry for every host in the entire set of LANs. 😳

Good news though: these tables are really caches of the entries needed for current communication activity, so the typical case will be far from the worst case. 💜 Most hosts talk mostly with other hosts on their own LAN and with a few hosts on other LANs. Most LAN communication is between workstation hosts and server hosts. 🫶 It can be expected that there will be frequent communication involving the main server hosts, and those server hosts will be in the tables of most of the BOXes most of the time. Main character servers, honestly. 👑

Infinite Transmission Loops

The possibility of infinite transmission loops through an interconnected set of LANs is prevented by keeping search lists in the BOXes and terminating the search when a request arrives for an address already on the list. 🔁

Transmission loops of regular datagrams can't persist, because the BOXes must decrement the TTL and discard the datagram if the TTL is reduced to zero. 🙅‍♀️ For debugging purposes, it would be useful for a BOX to report to the implementer any datagrams discarded for this reason. 🔍

Broadcast

Broadcast doesn't really have anything to do with transparent subnets or explicit subnets, so keep that separate in your head. 🧠

Since broadcast was discussed in [1], it will be discussed here too. Two of the three broadcast functions suggested in [1] work the same way and have the same effects. The third can be supported too. ✨

It's also argued that supporting a broadcast interpretation of IAs is a bigger issue than the explicit-versus-transparent subnets question, so it should be decided separately. 🤔

Some also suggest that broadcast isn't really what's wanted, and that multicast is the better function. 🦢 It may make sense to understand how to do an Internet multicast before adopting a broadcast scheme.

This IP Network

If the IA of this network number and an all-ones host number (e.g., 36.255.255.255) is used, an IP level broadcast to all hosts on this Network (all LANs) is intended. 📣 A BOX must forward this datagram. A BOX must also examine the datagram for potential significance to the BOX itself. 👀

To prevent infinite transmission loops, each BOX must keep a list of recent broadcasts. The entries on this list contain the source IA and the Identification field from the datagram header. If a broadcast is received and matches an entry on the list, it is discarded and not forwarded. 🛑 The entries on this list time out in time T2. ⏳

This LAN Only

If the IA of all ones (i.e., 255.255.255.255) is used, an IP level broadcast to all hosts on this LAN only is intended. 🏠 A BOX must not forward this datagram. A BOX must examine the datagram for potential significance to the BOX itself. 🫧

Another LAN Only

Since the LANs are not individually identified in the IA, this can't be supported in the same way. 🥲 Some have also argued that this is a silly capability to provide. 🙃

One way to provide it is to establish a specific IA for each LAN that means "broadcast on this LAN". For example, 36.255.255.128 means broadcast on LAN A, and 36.255.255.187 means broadcast on LAN B, and so on. 🎀 These addresses would be specially interpreted by the BOXes attached to the specific LAN where they have the special interpretation. Other BOXes would treat these addresses as any other IAs. 🧩 Where these addresses are specially interpreted, they are converted to the broadcast on this LAN only address. 🦋

DISCUSSION ✨

Okay so the big claim for the extended ARP scheme is that the average host doesn't even need to know it's in a multi-LAN environment 🫶

If a host took the trouble to analyze its local cache of IA:AH address mappings, it might discover that several of the IAs mapped to the same HA. And if it took timing measurements, it might discover that some hosts responded with less delay than others. And further, it might be able to find a correlation between these discoveries. But few hosts would take the trouble 🙈

Address Structure 🏠

In the explicit subnet scheme, some IA bits are devoted to identifying the subnet (aka the LAN). The address is broken up into network, subnet, and host fields. Generally, when more fields are used, the density of assigned addresses in the address space goes down, so the space is used less efficiently 📉. Significant implementation problems may show up if more subnets than planned get installed and you have to change the size of the subnet field 😬. It seems totally impractical to use the explicit subnet scheme with a class C IA 💀

In the extended ARP scheme, the address is simply the network and host fields. The extended ARP scheme may be used with any class of IA 🌈

Relocating Hosts 🦋

In the explicit subnet scheme, when a host is unplugged from one LAN and plugged into another, its IA must change.

In the extended ARP scheme, it may keep the same IA. Iconic 👑

One view of the situation suggests there are really two problems:

1. How does the host discover if the destination is on this LAN or some other LAN?

This question assumes that a host should know the difference, should do something different in the two cases, and that once it knows the answer, it also knows how to send the data (for example, directly to the host, or to the box).

The claim here is that hosts should not know the difference and should always do the same thing 💅

2. How do the BOXes that connect LANs know which BOXes are the routes to which LANs?

This question assumes that the BOXes need some kind of topological knowledge, and that they exchange BOX-to-BOX protocol information about connectivity.

The claim here is that the BOXes do not need topological knowledge, and do not need to explicitly know about the existence of other BOXes ✨

It has been suggested that there are two problems: first, how the hosts do routing; and second, how the BOXes do routing. A claim has been made that the competing strategies each have an approach to each problem, and you could pick a solution made up partly from one approach and partly from another 🧚

For example: use ARP within the LAN and have the BOX send ARP replies and act as an agent (as in the extended ARP scheme), but use a BOX-to-BOX protocol to get the "which hosts are where" information into the BOXes (as in the explicit subnet scheme). Mix-and-match energy 🍓

There are two places where code is involved: a large number of hosts, and a small number of BOXes. When you weigh the explicit subnet scheme against the extended ARP scheme, the work done in the hosts should count a lot more than the work done in the BOXes 🫶

What do hosts do? 💻

Explicit Subnet Scheme

The host must be able to decide if this IA is on this LAN or some other LAN. If it's on this LAN, then use some procedure to find the HA. If it's on some other LAN, then use some procedure to find the HA of a BOX.

Extended ARP Scheme

In every case, the host uses ARP to get an IA:HA mapping. Simple, no drama 🌸

What do the BOXes do? 📦

Explicit Subnet Scheme

The BOX must be able to decide which LAN within the site the destination host is on. The BOXes must have a routing table that tells, for each LAN in the site, which interface to send datagrams on. This routing table must be kept up to date, probably by a BOX-to-BOX protocol much like the Internet Gateway-to-Gateway protocol 🗺️

Extended ARP Scheme

The BOX must keep caches for each LAN it's attached to, holding IA:HA mappings, and it must keep a search list. It does not run any BOX-to-BOX protocol. It doesn't even know if any other BOXes exist 🙈

Topology and Implementation Complexity 🧩

Trees 🌳

If the organization of the LANs and the BOXes is tree structured, the BOXes can be very simple. They don't have to keep search lists at all, since there won't be any loops for the ARP-request to traverse. Easy mode ✨

Loops 🔁

If the organization has loops, then the search lists are essential. If the topology is kept balanced so there are no long loops (all loops are about the same size), and the LANs are reasonably compatible in delay characteristics, then the procedure described here will work well 💜

Complex 🌪️

If the organization is very complex, topologically unbalanced, and/or made up of a mix of different types of LANs with vastly different delay characteristics, then it may be better to use a BOX-to-BOX routing protocol. Know your limits, bestie 💀

---

SUMMARY 🎀

It would be useful if the Internet community could come to some agreement on a solution to the multi-LAN network problem, and could, with a unified voice, urge work station manufacturers to build that solution in 📣

I urge consideration of the extended ARP scheme explained here 🦋

I think most work stations will be connected to LANs that have a broadcast capability. I think most work stations will be used in situations that don't require explicit subnets, and most will be used in situations where class C Internet addresses would be appropriate (and explicit subnets impossible). So I think it would be best to ask manufacturers to include support for ARP in work stations off the shelf 🛒 I also think we ought to get busy and create, develop, test, and produce the magic boxes I suggest, so that they're available off the shelf too ✨

Please note that neither this note nor [1] proposes a specific routing procedure or BOX-to-BOX protocol. That's because such a routing procedure is a very hard problem 😭 The plan proposed here will let us get started on using multi-LAN environments in a reasonable way. And if we later decide on a routing procedure to be used between the BOXes, we can redo the BOXes without having to redo the hosts 🫶

---

GLOSSARY 📚

• ARP

Address Resolution Protocol (see [2]).

• BOX

Magic Box. A box (computer) connected to two or more LANs of the same Network. Also called an "ARP-based bridge".

• Bridge

A node (computer) connected to two or more administratively indistinguishable but physically distinct subnets, that automatically forwards datagrams when necessary, but whose existence is not known to other hosts. Also called a "software repeater".

• Datagram

The unit of communication at the IP level.

• Explicit Subnet

A Subnet explicitly identified in the Internet Address by a subnet address field, and so visible to others both inside and outside the Network.

• Gateway

A node (computer) connected to two or more administratively distinct networks and/or subnets, to which hosts send datagrams to be forwarded.

• HA

Hardware Address, the address used in a packet on a LAN.

• Host Number

The address of a host within a Network, the low-order part of an IA.

• IA

Internet Address, as defined in IP.

• Internet

The collection of connected Internet Networks (also known as the Catenet). A set of interconnected networks using IP.

• IP

Internet Protocol (see [3]).

• LAN

Local Area Network.

• Multi-LAN Network

A set of LANs treated as one Network, i.e., using one Network Number in common. The individual LANs may be either Explicit Subnets or Transparent Subnets.

• Network

A single Internet Network (possibly divided into subnets or composed of multiple LANs), identified by an individual Network Number.

• Network Number

An IP Network Number, the high-order part of an IA.

• Packet

The unit of communication at the LAN hardware level.

• Subnet

A subnet of a Network. A portion of a Network (either logical or physical).

• Transparent Subnet

A Subnet not identified in the Internet Address, and so invisible to others (see Multi-LAN Network).

• TTL

The IP Time-To-Live field.

---

REFERENCES 📖

[1] J. Mogul, "Internet Subnets", RFC-917, Stanford University, October 1984.

[2] D. Plummer, "An Ethernet Address Resolution Protocol or Converting Network Protocol Addresses to 48-bit Ethernet Addresses for Transmission on Ethernet Hardware", RFC-826, Symbolics, November 1982.

[3] J. Postel, "Internet Protocol", RFC-791, USC-ISI, September 1981.