RFC 1029

More fault tolerant approach to address resolution for a Multi-LAN system of Ethernets

📅 published May 1988, from ietf

RFC 1029 🎀 A MORE FAULT TOLERANT APPROACH TO ADDRESS RESOLUTION FOR A MULTI-LAN SYSTEM OF ETHERNETS

okay bestie, the title block first 💖 this one is from the Network Working Group, written by G. Parr at the University of Ulster, dated May 1988 🦋 the original doesn't name a category, and it doesn't say it obsoletes or updates anything. this is Part 1 of 5 so buckle up 🧚

STATUS OF THIS MEMO ✨

okay so this memo talks about an extension to a Bridge Protocol that detects and discloses changes in neighbouring host address parameters in a Multi-LAN system of Ethernets 🌸 the problem keeps showing up more and more as these interconnected systems get bigger on campuses and in commercial institutions 😭 this RFC suggests a protocol enhancement for the Internet community and asks for discussion and suggestions for improvements 🫶 distribution of this memo is unlimited 💅

ABSTRACT 🦋

so picture a sending host S running a protocol P. through P's routing mechanism, S decides it wants to send to a target host T that's somewhere on a connected piece of 10Mbit Ethernet cable that conforms to IEEE 802.3 🔥 to actually transmit the Ethernet packet, a 48 bit Ethernet/hardware address must be generated 💀 the addresses assigned to hosts within protocol P are not always compatible with the matching Ethernet address, since they can use different address space byte orderings or values 🙈

here's the solution: a protocol that lets the information needed to build tables get distributed dynamically, so a host's address in protocol P's address space can be translated into a 48 bit Ethernet address ✨ there's also an extension so the protocol is flexible enough to live in a Transparent Bridge or a generic Host 👑 the post also talks about the Bridge's ability to detect host reboot conditions in a multi-LAN environment, with a big focus on the effect on channel bandwidth 🍓 to show how the protocol mechanisms work, the Internet Protocol (IP) is used as a benchmark [6], [8] 💜 Part 1 presents an introduction to Address Resolution, whilst Part 2 discusses a reboot detection process. the vibe is set, bestie 🌈

DEFINITIONS:

      CATENET: a group of IP networks linked together
      IP     : Internet Protocol

PART 1 🧚

INTRODUCTION

okay so on Ethernet, every packet gets broadcast, but the hardware interface only picks up the ones that have either the explicit hardware broadcast address or this interface's own individual hardware address 🫶 anything else gets rejected by the interface and never reaches the host software, which is honestly iconic because it saves the host a huge pile of wasted effort having to look at packets just to toss them 🗑️ if the interface instead chose packets for the host software based on the protocol address, there'd be zero need for any translation from protocol to Ethernet address 🤯

now, it's very important to minimize the number of packets each host has to examine, especially the needless inspections 🌸 so the hardware broadcast address should only be used in situations where it's uniquely beneficial 💅 if you were designing a brand new local network, maybe you could skip address translation altogether 🦋 but in the real world of existing networks, it does a super important job 😭 one rare use of the broadcast hardware address is worth calling out: it avoids putting any processing load on the other hosts of the Ethernet, and it's how hosts get the info they need to use specific, individual hardware addresses to exchange most of their packets ✨

REASONING BEHIND ADDRESS RESOLUTION

the process of going from the logical host address to the physical Ethernet address is called ADDRESS RESOLUTION 🎀 it has sparked research into a method that's easy to interface with and stays portable at the same time 💖

the Ethernet needs 48 bit addresses on the physical cable [11] because the manufacturers of the LAN interface controllers assign each one a unique 48 bit address during production 🏭 obviously, Network Managers don't want to be stuck using that address to identify destinations at the higher level 🙄 they'd much rather give their hosts logical names and let some lower level protocol handle the resolving 🫶 and the thing is, most of these logical protocol addresses aren't 48 bits long, and they don't necessarily have any relationship to the 48 bit address space 😭

for example, IP addresses have a 32 bit address space [6], so we need a way to dynamically distribute the correspondences between a <PROTOCOLTYPE,PROTOCOL-ADDRESS> pair and a 48 bit Ethernet address 🧚 that's the whole mission, bestie 💜

EXAMPLE ARP OPERATION

okay so let's walk through how ARP works, as defined in RFC-826 [5] 🦋 say hosts X and Y are on the same Ethernet cable 🌈 they have physical Ethernet addresses EA(X) and EA(Y), plus DoD Internet addresses IPA(X) and IPA(Y) ✨ the Ethernet type of Internet is ET(IP) 🎀

host X starts an application, and sooner or later it wants to send an Internet packet to host Y 💅 X already knows Y's Internet address, which is (IPA(Y)), so it tells the lower level it wants to talk to IPA(Y) 🫶 the lower level then asks the ARP Module (ARM) to convert <ET(IP),IPA(Y)> into a 48 bit Ethernet address 🙈 but X has never talked to Y before, so there's nothing in its Translation Cache (TC) yet 😭 so it discards (or queues) the Internet packet and creates a brand new Address Resolution packet with:

       PACKET FIELD             VALUE ASSIGNED

        HRDTYP                   ETHERNET

        PROTYP                   ET(IP)

        HRDLEN                   length (EA(X))

        PROTLEN                  length (IPA(X))

        ARPOPC                   REQUEST

        SOURCE HWR               EA(X)

        SOURCE PROT              IPA(X)

        TARGET HWR               don't know

        TARGET PROT              IPA(Y)

then X broadcasts this packet to every host on the connecting cable 📡 host Y picks it up and checks that it understands the hardware type (Ethernet), that it speaks the indicated protocol (Internet), and that the packet is for it, meaning TARGET PROTOCOL ADDRESS = IPA(Y) 👑 Y replaces any previous entry and saves the info that <ET(IP),IPA(X) translates to EA(X) 🍓 then Y realises this is an ARREQ packet, so it swaps the fields around 🔄 it puts EA(Y) in the new sender Ethernet address field SOURCE HARDWARE ADDRESS, EA(X) in TARGET HARDWARE ADDRESS, IPA(X) in TARGET PROTOCOL ADDRESS, and IPA(Y) in SOURCE PROTOCOL ADDRESS, then sets the opcode to REPLY 💖 the packet goes out with direct routing address information to EA(X) ✨ so now Y knows how to send to X, but X still doesn't know EA(Y) 😭

when X gets the ARREP packet from Y, it stores the address info in its translation cache as ET(IP),IPA(Y)>-->EA(Y) 🧚 X notices it's a REPLY and discards the packet, which means it disposes of the dynamic packet buffer 🗑️ but if the original Internet Module packet had been queued, it could've been pulled out and given the full addressing info from the translation cache 🦋 alternatively, if it had been discarded, the higher level would've succeeded on a later attempt, and the Internet packet would've gone out right away 🌸

ps: I kept the original's bracket typos exactly as written (like the missing < and > in the entries above), because implementers read these literally and the spec is the spec 💅

OBTAINING GREATER NETWORKING RANGE 🦋

Okay bestie, so splitting one big multiuser network into smaller, more manageable networks is literally such a glow-up 💖 The perks are Data Security, Overall Network Reliability, Performance Enhancement, and the most obvious one, Greater Networking Range 🌈 Some network technologies say cable length can't go past a certain range because of electrical limits 😭 but installing a Bridge basically erases that restriction ✨

Just one catch, babe 🙈 The Bridge delays you introduce will mess with the protocol timeouts running on each LAN/Subnet. You'd have to carefully analyse the upper bounds on those timeouts to get the full benefit of the extra range. No skipping this step 💅 For Ethernet, the system parameters that exist are [11], [12]:

the bus bandwidth is 10Mbit/s
the maximum node-to-node cable length is 1500 m
the maximum point-to-point link cable length is 1000 m
the maximum number of repeaters between two nodes is two
the worst case end-to-end bus propagation delay is 22.5 us
the jam time after collision is 32bit
the minimum interframe time is 9.6 us
the slot size is 512 bit = 51.2 us

Once you've decided to subnet, the resulting subLANs can be connected with a Bridge that links them together and runs a protocol making the whole collection of subnets look like one single network 🧚 The basic idea of a Bridge doing 'repeater' stuff just wouldn't cut it here 🙅‍♀️ The Bridge would also need extra 'intelligence' so it can pick out the packets meant for remote networks by looking at the protocol address of the target host. That way it doesn't forward packets that are just gonna get rejected anyway. If it skipped this, the remote networks' channel bandwidth would get flooded with packets, local valid traffic would back off, and efficiency would tank super fast 😩

One fundamental problem for the Bridge is figuring out which LAN a particular host is plugged into 🔍 If there are only two LANs, each one gets a dedicated cache at the Bridge. When a packet comes in on an interface, the source host's address parameters get entered into that LAN's cache. But once you're dealing with a Multi-LAN environment, things get way more complicated 🌀

   ___
    |
    |-----h3
    |                                            E4
    |-----hq                            |-----------------------|
    |                _                             |        |
    |-----hx        | | B1                         |        |
    |---------------| |                            |        |
    |-----h1        |_|                            |        |
    |                |     h19                     |        |      ______
    |                |    |                       | |        -----|______|  B4
    |                |    |                       | | B3              |
    |-----he       |-------------------| E2       |_|                 |
    |                    |                         |                  |
    |-----h5             |                         |                  |
    |                    |                         |                  |
    |                   ---                ---     |                  |
   ---                  | |                 |-------                  |
   E1                   | | B2              |                         |
                        | |-----------------|                         |
                        ---                 |                         |
                                            |          |---------------------
                                           ---                              |
                                            E3                              |
                                                                            |
                      FIGURE 1.  A MULTI-LAN TOPOLOGY

In the normal set-up, whenever B3 or B4 receives a packet on E4, they both update the caches on their E4 interface 👀 On top of that, there has to be a way to let B4 tell apart packets arriving on E4 from E1, E2, and E3 versus packets that actually originated on E4. Why? So packets can be sorted as coming from a remote or local source and handled accordingly 🫶

The most obvious fix is for each Bridge to act as an AGENT. It plugs in its own address as the source of any packet it passes along to a remote network, instead of keeping the packet's original source address 🕵️‍♀️ When the Bridge boots, it can broadcast a request asking all locally connected hosts/devices to send back their local network protocol addresses. Once that info comes in, the Bridge can update the cache for each of its interfaces, so it has a solid base to work from for everything after 📋

The other option is manual intervention. The network manager can step into the Bridge software and key in the addresses of the hosts on each LAN interface by hand ✍️

So, now the Bridge knows the original LAN addresses when it boots. But how does it tell a brand-new host showing up on the local system apart from transmissions sent by a remote source and passed along by an adjacent Bridge? 🤔 Two approaches are currently being considered for this: Explicit Subnets and Transparent Subnets [4], [7], [9], [14].

With the Explicit Subnet approach, where the host sits in the system really matters 📍 The host's protocol-suite address reflects which subnet it's plugged into. That means the protocol address space gets split into a three-level hierarchy of <network,subnet,host>. The Internet has five addressing divisions in operation [10]: classes A, B, C, D, and E. Classes D and E are for multicast group management and won't be covered here. With this structure, you can set an address mask on each interface, so received packets get their source address fields checked against this LAN's mask. What's actually being verified is the subnet address. If the mask matches, the source has to exist on this LAN. If it doesn't, the source must be remote 🎯

With the Transparent scheme, the first time a newly booted host 'speaks,' it's going to be looking for addressing info (probably using BOOTSTRAP [1], RARP [2], or ARP [5]) 🌱 So the Bridge catches those requests and gets in a position to work with the address parameters. The current Transparent Subnetting approach says that before any of those requests can be passed along by the Bridge to an adjacent LAN, the Bridge puts its own interface address parameters into the source address fields, so it's acting as the AGENT 💜 That means the Bridge will 'see' either packets arriving from the remote Bridge's address or local packets. Since hosts do RARP/ARP when they first come up, any hi-level packets hitting the network that don't have the bridge address and don't have a mapping in that LAN's cache can be treated as remote 🦋

Right now there's a move toward the Transparent subnet proposal Postel originally described [7]. The big reasons are practical problems with incompatible implementations from different vendors, and the way the Explicit address space restricts how easily the system can change (class C addresses just aren't flexible enough for the Explicit scheme) 🙄 The Author of this paper also thinks the Agent technique the Bridges use could have shortcomings in a dynamic environment, and that could hurt how it works. Examples are when the bridges themselves relocate or crash, or when it comes to managing the "Agent For Who" cache at the bridge 😬 Loop Resolution and Self-Stabilization after failure are Bridge problems that still need solving, and it's strongly felt that the best way to solve them is to get rid of the Agent technique [13] 🌸

BRIDGE OPERATIONS 🌸

Okay, now look at figure 1 🗺️ Say that at some point during its processing, [E1H3] wants to talk to [E2H19]. [E1H3] gets the Internet address of [E2H19] from its translation cache, but it doesn't need to know that [E2H19] is on a totally different subnet. [E1H3] calls its Internet Module to send the packet. The usual procedure kicks in: control gets passed to its ARM to try to get a translation. If [E1H3] and [E2H19] have never talked before, the ARM in [E1H3] won't be able to resolve the addresses on the first try 😅

So an ARREQ packet is put together and broadcast to all hosts on the network [E1]. It travels down the cable and gets picked up by the (B1) Bridge Address Resolution Module (BARM), which decides whether or not it should step in on the request 🦸‍♀️ If the target looks remote (i.e., there's no match in the local cache), the BARM checks its Global Translation Cache (GTC) for an entry for <protocol,[E2H19]>. If the Bridge does find a mapping, there's no need to cascade the broadcast REQUEST packet onto the remote network [E2]. It's assumed that the GTC entries reflect the most current addressing info. Once there's a match, the original ARREQ packet buffer gets adapted as needed and sent right back to [E1H3] through the Bridge's hardware interface IFE1 🎉

But if the Bridge's GTC has no info on [E2H19], the BARM has to do these steps:

drop the current ARREQ from [E1H3],
create its own ARREQ using the Bridge source addresses and copy the target_internet_addr from the original [E1H3] ARREQ packet,
broadcast the ARREQ on network E2 via network interface IFE2, and go into a timeout awaiting a REPLY.

If that timeout period expires, the BARM is allowed a number of retries 🔁 If a REPLY does show up within the timeout interval, the BARM updates its GTC ✅ Then the ARM of [E1H3] tries to send another ARREQ, and this time the BARM does have a mapping in its GTC, so the appropriate REPLY gets sent back 💖

Part 1 covered the state of the art when it comes to how Address Resolution behaves 📚 Part 2 now digs into the more serious problem of hosts rebooting in a multi-LAN system of Ethernets, and how those changes mess with the integrity of the state information held in ARP caches and routing tables 💀

PART 2 🎀

THE CAPTURE OF REBOOTS ✨

okay so bestie, Address Resolution packets are broadcast, which means every host on the connecting cable 📡 (including the Transparent Bridge!) picks them up and figures out what they're about. Look at figure 1. It's totally possible that a host on E1 wants to talk to a fellow host on that same physical ether. So if Hx wants to talk to Hw on the same ether and hasn't done so before, it broadcasts an Address Resolution packet the normal way. The Bridge also "sees" the packet as it passes by and will act as described above, unless there's some method of stopping it. Like, why would the Bridge fire up its ARM and waste processing time if the problem is going to get solved locally anyway? 🙄

It can also happen that H1 wants to talk to H5. But if H5 hasn't talked to anyone before (aka it's been "dormant" 😴), H1 will issue an ARREQ. The Bridge won't know that H5 is local, because H5 never got entered into the local address cache from earlier conversations. To avoid blasting an ARREQ out to every network/subnet, one way around this is to set up the contents of the local cache at Bridge startup time. That way the Bridge already knows not to step in. So if the Bridge (with 2 nets) finds that a particular IP destination address isn't in the local cache of interface 1, it has to check its GTC and scan it for a mapping. If no mapping turns up at interface 2, there are two possibilities:

the target host doesn't exist locally
the caches are corrupt (the eventuality of this should be negligible!)

If we assume that each translation cache holds the most recent addressing info for its own domain of the network, then in this example, if the Bridge doesn't get a mapping from the GTC, it would look like the host must exist remotely from E1 and E2. 🌍

But that conclusion ignores cases where a host unplugs from one hardware interface and plugs into another, or where logical names get reassigned to different interfaces because the host's user changed. Either of those could happen with the host being accessed on E2, and that would mean a REBOOT has taken place. 😬

This is why local caches are essential 💅. In normal operation, the Bridge processes and forwards IP packets received from one network that are destined for another. If the Bridge picks up an ARREQ, it first looks for a mapping in its GTC before discarding the original ARREQ and sending its own out to the remote network. In any case, the Bridge always examines the local cache entries at the receiving interface, so it can tell whether the target address is local or remote. When the Bridge first scans the local cache, it uses the source IP address as the key. If no mapping is retrieved, it then scans the GTC with that same key. If a mapping shows up now, the Bridge still has to insert the source IP into the local cache, where it has either been previously deleted or corrupted.

However, if the source IP does exist in the respective local cache, the validity of the source Ethernet address should also be verified by checking the respective entry in the GTC. The GTC is scanned with <protocol,source_prot_addr> as the key. If a mapping is retrieved, the respective <et_addr> should be checked against the source Ethernet address in the packet header. If the addresses don't match, we've uncovered a Hardware Reboot condition (i.e., a change in Ethernet ID) 🔴. On the other hand, if the scan of the GTC with <protocol,source_prot_addr> fails to get a mapping, the Bridge scans the GTC with the current Ethernet address in the packet header. If that gets a mapping, a Protocol Reboot condition (i.e., a change in logical ID) has been detected 💜.

In the next section, we look at what these forms of 'Reboot' actually imply 👀.

REBOOT SCENARIO 🔁

In normal operation, packets just traverse each subnet without drama, either as complete Internet packets, broadcast ARREQ's, or direct ARREP's. The Bridge attached to each subnet 'hears' and 'sees' every packet that travels past its connected interfaces. Because each interface has its own local cache, the Bridge can decide whether or not to intervene. In general, each host on the Catenet has a translation cache containing <protocol,source_prot_addr,source_et_addr> entries for all the packets it has observed. Most of these entries come from processing broadcast ARREQ packets and from receiving REPLY packets. In line with all that, the Bridge has a cache attached to each subnet interface, containing entries for protocol addresses.

Inside the Bridge's Global Translation Cache (GTC) you'll find entries for all the <protocol,source_prot_addr,source_hrd_addr> triplets relating to valid hosts that have been recognised ✅. Say we've just connected up a Catenet like the one in figure 1. At power-up, no stations know anything about their neighbours 🥺. If the Bridges are to remain transparent, the translation caches at each host will be totally empty. The only addressing details that exist will be the protocol addresses stored in the local caches of the Bridges.

Then the hosts start running applications and want to talk to one another 💬. The first ARREQ is broadcast on the respective subnet, and all hosts, including the Bridge's interface to that subnet, pick it up and store the details. If, for example, Hx issues an ARREQ for Hq, the Bridge won't intervene, since there's no need (as long as no reboot has happened at Hq). However, if Hx wants to talk with Hz, B1 will determine that the target IP in the respective ARREQ doesn't exist in the local cache of IFE1, so it examines the GTC, with the <protocol,target_prot_addr> of Hw as the key.

It's assumed that there will be a timeout mechanism in operation at the source of any packet ⏱️. In addition, the Bridge may place the target address in a 'search list' of currently sought hosts, so that ARREQs from different sources don't get cascaded for the same target. Under these conditions, Hx may re-issue its original ARREQ, but it'll be ignored until host Hw has replied to the ARREQ transmitted by the Bridge 🙃.

NORMAL RUNNING STATE 🌈

Once a few ARP's have been issued, IP packets start traversing the Catenet with full addressing information 🚀. Again, the Bridges 'see' all the packets. Now extend the situation one step further and assume several conversations have taken place across the Catenet. Then there will be entries in the translation caches of the hosts involved, covering the <protocol,target_prot_addr,target_hrd_addr> triplets of the hosts they talked with. The Bridges also have details in their GTC's for the packets they cascaded.

If a host is relocated, any connections initiated by that host will still work, provided that its own translation cache gets cleared when it physically moves 📦. However, any connections initiated to it later by other hosts on the Catenet won't have any particular reason to know they should discard their old translation for that host. Ideally, 48 bit Ethernet addresses will be unique and fixed forever 🫶.

RECOGNITION OF THESE REBOOT CONDITIONS 👑

okay so bestie, picture this 🎀. Figure 1 is our little Ethernet world, and <E1He>'s hardware interface faults out 💀. Now it has a brand new interface with a newly acquired hardware address, which is kind of a glow-up, ngl 🦋. When <E1He> powers back up, its translation cache is wiped clean. It has zero memories of local or remote host addresses, so it just starts sending ARREQ's to whoever it needs. The very first ARREQ it sends could be called a 'HELLO PACKET' 👋, because literally everyone on the subnet can pick it up and save the info into their own translation caches. Within each host, the old <protocol,source_prot_addr> pair gets found, and the current <et_addr> from the packet header overwrites whatever was sitting in the cache. Iconic, honestly ✨.

Now, you'd think each host with an entry could spot the Hardware Reboot situation and broadcast its own reboot packet to tell everyone 📢. But no, bestie 🙅‍♀️. That would be super inefficient on a broadcast medium and would totally cancel out any performance wins in the long run. Plus, since the ARREQ is broadcast, every station on the subnet already catches the reboot anyway 💅. The real question is what this reboot does to conversations that get started remotely 🤔.

Can we stop redundant transmissions before they waste processing time on the hosts sitting along the path to the rebooted target? How we handle that is a huge deal for performance in a Catenet configuration 😭. Since hosts shouldn't be the ones telling the system about a reboot, that job goes to the Bridge 🌉. Every time a Bridge gets a packet, whether it's IP or ARP, it checks the source address parameters in the header, hoping to catch any mismatch with what's in its caches 👀. There are three possible plot twists: the 48 bit hardware address is different but the protocol address is the same, the protocol address is different, or both addresses are brand new. If the Bridge finds an incompatibility, it builds a "REBOOT" packet and sends it out on all remote interfaces that have the right info 📦. That way Bridges can update their GTC's and generic hosts can update their ARP caches 🫶.

The Reboot packet is laid out like this, as shown in figure 2 🦋:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | P A C K E T     O P C O D E   |REB OPC|      S O U R C E      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        H A R D W A R E            A D D R E S S               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       S O U R C E   P R O T O C O L     A D D R E S S         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     M U L T I C A S T   T A R G E T    H A R D W A R E        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    A D D R E S S      |   M U L T I C A S T     T A R G E T   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   P R O T O C O L     |
   +-+-+-+-+-+-+-+-+-+-+-+-+

          ---------> NEXT FOLLOWS A VARIANT FIELD ON REBOOT  OPCODE

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  O L D         S O U R C E        H A R D W A R E             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  A D D R E S S        |
   +-+-+-+-+-+-+-+-+-+-+-+-+

    OR

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  O L D     S O U R C E    P R O T O C O L      A D D R E S S  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

FIGURE 2. REBOOT PACKET

Here are the definitions that apply 🧚:

     PACKET FIELD              VALUE

     OPCODE                    REBOOT

     REBOOT OPCODE             HARDWARE

     REBOOT OPCODE             PROTOCOL

And the format goes like this 💜:

     48 bit broadcast Ethernet address for the destination,

     48 bit Ethernet address of source Bridge,

     16 bit Protocol type = PACKET OPCODE - REBOOT.

For completeness and error checking, it's kind of a good idea to have a field that says how long the addresses are in the Ethernet and protocol address spaces 🔥. So the Reboot packet structure has these fields:

FIELD          FIELD SIZE                    DESCRIPTION

HRDLEN          4 bit             byte length of Ethernet address

PROTLEN         4 bit             byte length of Protocol address


SOURCE
PROTOCOL
ADDRESS        32 bit            current protocol address of host

TARGET
PROTOCOL
ADDRESS        32 bit           broadcast target protocol address

REBOOT
OPCODE          4 bit            will be either PROTOCOL or HARDWARE


if   PROTOCOL       32 bit         old protocol address

else HARDWARE       48 bit         old hardware  address

So depending on the REBOOT-OPCODE, the packet keeps going with either the 48 bit old hardware address or the 32 bit old protocol address 🌸. The reason for the variant structure is to keep the packet small, with only the fields that are truly necessary for each situation 🍓. Now we can talk about how a packet actually gets generated. When the Bridge algorithm detects a reboot, it should build a reboot packet structure with the relevant addressing info, then multicast it on the interface(s) that reach the remote subnet(s) 📡. Figuring out which interface(s) are local and which are remote can happen automatically whenever a packet comes in. For this packet transfer, the receiving interface at the Bridge counts as local, and all the others get tagged as remote 🏷️.

So hosts on subnets remote from the reboot find out right away, the moment the Bridge detects it 🚀. In the Catenet configuration from fig 1, this updates the Translation Cache in each host whenever it gets the packet 💖. Let's say <E4Hw> reboots under hardware. B3 is going to notice 👀. The subnets E1, E2, and E3 don't need to know about this episode at all 🙈. In normal operation, B3 spots the reboot from the very first ARREQ that <E4Hw> sends. With this detection, B3 is in a position to tell the hosts on E1, E2, and E3 ✨. B3 creates and sends the Reboot packet out its interface with E3. When B3 picks it up, it updates its own caches and then passes the packet along to E2, where it gets relayed to E1 through B1 🌈.

ARGUMENTS FOR REBOOT PACKETS 🦋

It's expected that introducing Reboot packets will boost the bandwidth you can get out of a Catenet system 💅. In a correctly working configuration, the problem of addressing 'dead' hosts just won't exist anymore 🙌. Translation Caches will hold the most recent addressing info available, which should also help the routing strategy perform better 🔥. Multiple, redundant processing of packets aimed at 'dead' hosts gets avoided 🛑. Weigh that against the processing cost of one multicast of Reboot packets, and the latter is expected to be the most economically viable option for the long-term traffic the system deals with 💰.

CONCLUSION 💜

It seems like reboots are becoming more and more common on internet networks 😭. Lots of sites use Personal Computers (PC) as terminals, and the typical way to end a session is to just switch them off! 💀 As multitasking Operating Systems get more popular on these machines, problems are more likely to happen, especially when the PCs are diskless or part of some kind of distributed file system 🫠. Since correct addressing matters so much on Ethernet networks, the reboot mechanism described here is expected to improve the correctness and validity of the protocol/network address mappings that can be stored in the translation caches ✨. Simulation is expected to show that the amount of invalid traffic goes down, which is good news for hosts, Bridges and servers alike 🎀. Ratifying the routing policy is also anticipated, and since redundant/obsolete packets get thwarted, efficient use of available channel bandwidth across the catenet should improve too 📈. So Catenet throughput for 'valid' packets goes up, and that means a better level of service for end users 🫶.

Okay, the proposed scheme obviously means changing the packet processing code in Bridges/Gateways 🛠️. The thing to remember is that bigger, more complex Multi-LAN systems of Ethernets are getting more and more love 💖. Using extra telephone cables as the transmission media for Ethernet can only lower installation costs, which makes Ethernet even more attractive inside large corporate buildings, etc. 🏢 It's fair to say the probability of host address re-assignment will go up with the number of physical systems attached, the component failure rate (for whatever reason), relocation of resources, and the size and turnover of the workforce (i.e., people moving from one room to another) 🚪. Simulation experiments are being developed right now to analyse the resulting traffic patterns under this scheme, and the hope is to highlight thresholds where adopting the scheme becomes a necessity 🔬.

Also, the Author is currently stretching the boundaries of this problem to cover the reboot, or relocation, of Bridges themselves 🌉. That brings in loop resolution, load sharing and duplicate packet suppression 🔁. The expectation is that a Self-Stabilizing Bridge Protocol will come out of this, one that is more "light-weight" than those following the Spanning Tree Algorithm 🪶.

The Author would love feedback and comments on this RFC 💌. The network address is: CBAD13%UCVAX.ULSTER.AC.UK@CUNYVM.CUNY.EDU 📬.

ACKNOWLEDGEMENTS 🫶

The Author gratefully acknowledges the help and comments from Mr. Piotr Bielkowitz (Supervisor) of the Computing Science Department 🎓, and the time Mr. Raymond Robinson gave to painstakingly preparing the first draft of this paper on 'Pagemaker' 💅.

Thanks are also due to Dr. M. W. A. Smith of Information Systems for his assistance 🌸. Finally, this work was supported under a grant from the Department of Education for Northern Ireland, and the Author is extremely grateful 🥹✨.

REFERENCES 📚✨

okay bestie, here's the full reading list 💅 every single source is kept exactly as written, so you can go grab them 🦋

[1] Croft, Bill, and John Gilmore, "Bootstrap Protocol", RFC-951, Stanford University, September 1985.

[2] Finlayson, Mann, Mogul, and Theimer, "A Reverse Address Resolution Protocol", RFC-903, Computer Science Dept, Stanford University, June 1984.

[3] Lorimer, Alan, and Jim Reid, "ARP Information Communique", Computer Science Dept, Strathclyde University, 1987.

[4] Mogul, Jeffrey, "Internet Subnets", RFC-917, Computer Science Dept, Stanford University, October 1984.

[5] Plummer, David, "An Ethernet Address Resolution Protocol", RFC-826, MIT, November 1982.

[6] Postel, Jon, "DARPA Internet Program Protocol Specification", RFC-791, USC/Information Sciences Institute, September 1981.

[7] Postel, Jon, "Multi-LAN Address Resolution", RFC-925, USC/Information Sciences Institute, October 1984.

[8] Postel, Jon, Carl Sunshine, and Danny Cohen, "The ARPA Internet Protocol", Computer Networks, no. 5, pp. 261-271, 1981.

[9] Postel, Jon, and Jeff Mogul, "Internet Standard Subnetting Procedure", RFC-950, USC/Information Sciences Institute and Stanford University, August 1985.

[10] Reynolds, Joyce, and Jon Postel, "Assigned Numbers", RFC-1010, USC/Information Sciences Institute, May 1987.

[11] "The Ethernet: a local area network, data link layer and physical layer specification", Version 1.0 DEC, Intel and Xerox Corporations, USA 30 September 1980).

[12] Hughes, H.D., and L. Li, "Simulation model of an Ethernet", Computer Performance, Vol 3, no. 4, December 1982.

[13] Parr, Gerald P., "Address Resolution For An Intelligent Filtering Bridge Running On A Subnetted Ethernet System", ACM SIGCOMM Computer Communication Review, (July/August 1987), vol. 17, no. 3.

[14] Smoot, Carl-Mitchell, and John S. Quarterman, "Using ARP to Implement Transparent Subnet Gateways", RFC-1027, Texas Internet Consulting, October 1987.

that's the whole squad 🌈💖 go read them all, you're literally so smart for even getting this far 🫶

📦 where this page comes from

ietf: rfc1029 1988-05
💖 girlified by claude-haiku-5-5 on 2026-10-15: a language model's rewrite of the original, under its terms