doc: Add RFC documents

1 files changed, 949 insertions, 0 deletions

diff --git a/doc/rfc/rfc1029.txt b/doc/rfc/rfc1029.txt
new file mode 100644
index 0000000..2b8e25b
--- /dev/null
+++ b/doc/rfc/rfc1029.txt
@@ -0,0 +1,949 @@
+Network Working Group                                           G. Parr
+Request For Comments: 1029                         University of Ulster
+                                                               May 1988
+
+
+        A MORE FAULT TOLERANT APPROACH TO ADDRESS RESOLUTION FOR
+                    A MULTI-LAN SYSTEM OF ETHERNETS
+
+STATUS OF THIS MEMO
+
+   This memo discusses an extension to a Bridge Protocol to detect and
+   disclose changes in neighbouring host address parameters in a Multi-
+   LAN system of Ethernets.  The problem is one which is appearing more
+   and more regularly as the interconnected systems grow larger on
+   Campuses and in Commercial Institutions.  This RFC suggests a
+   protocol enhancement for the Internet community, and requests
+   discussion and suggestions for improvements.  Distribution of this
+   memo is unlimited.
+
+ABSTRACT
+
+   Executing a protocol P, a sending host S decides, through P's routing
+   mechanism, that it wants to transmit to a target host T located
+   somewhere on a connected piece of 10Mbit Ethernet cable which
+   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 corresponding Ethernet address (being different address space
+   byte orderings or values).  A protocol is presented which allows
+   dynamic distribution of the information required to build tables that
+   translate a host's address in protocol P's address space into a 48
+   bit Ethernet address.  An extension is incorporated to allow such a
+   protocol to be flexible enough to exist in a Transparent Bridge, or
+   generic Host.  The capability of the Bridge to detect host reboot
+   conditions in a multi-LAN environment is also discussed, emphasising
+   particularly the effect on channel bandwidth.  To illustrate the
+   operation of the protocol mechanisms, 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.
+
+DEFINITIONS:
+
+      CATENET: a group of IP networks linked together
+      IP     : Internet Protocol
+
+
+
+
+
+
+Parr                                                            [Page 1]
+
+RFC 1029           Fault Tolerant ARP for Multi-LANs            May 1988
+
+
+                                 PART 1
+
+INTRODUCTION
+
+   In the Ethernet, while all packets are broadcast, the hardware
+   interface selects only those with either the explicit hardware
+   broadcast address or the individual hardware address of this
+   interface.  Packets which do not have one of these two addresses are
+   rejected by the interface and do not get passed to the host software.
+   This saves a great deal of otherwise wasted effort by the host
+   software having to examine packets and reject them.  If the interface
+   hardware selected packets to pass to the host software by means of
+   the protocol address, there would be no need for any translation from
+   protocol to Ethernet address.  Although it is very important to
+   minimize the number of packets which each host must examine, so
+   reducing especially needless inspections, use of the hardware
+   broadcast address should be confined to those situations where it is
+   uniquely beneficial.  Perhaps if one were designing a new local
+   network one could eliminate the need for an address translation, but
+   in the real world of existing networks it fills a very important
+   purpose.  A rare use of the broadcast hardware address, which avoids
+   putting any processing load on the other hosts of the Ethernet, is
+   where hosts obtain the information they need to use the specific and
+   individual hardware addresses to exchange most of their packets.
+
+REASONING BEHIND ADDRESS RESOLUTION
+
+   The process of converting from the logical host address to the
+   physical Ethernet address has been termed ADDRESS RESOLUTION, and has
+   prompted research into a method which can be easily interfaced,
+   whilst at the same time remaining portable.
+
+   The Ethernet requires 48 bit addresses on the physical cable [11] due
+   to the fact that the manufacturers of the LAN interface controllers
+   assign a unique 48 bit address during production.  Of course, Network
+   Managers do not want to be bothered using this address to identify
+   the destination at the higher-level.  Rather, they would prefer to
+   assign their logical names to the hosts within their supervision, and
+   allow some lower level protocol to perform a resolving operation.
+   Most of these logical protocol addresses are not 48 bits long, nor do
+   they necessarily have any relationship to the 48 bit address space.
+
+   For example, IP addresses have a 32 bit address space [6], thus
+   giving rise to the need to distribute dynamically the correspondences
+   between a <PROTOCOLTYPE,PROTOCOL-ADDRESS> pair, and a 48 bit Ethernet
+   address.
+
+
+
+
+
+Parr                                                            [Page 2]
+
+RFC 1029           Fault Tolerant ARP for Multi-LANs            May 1988
+
+
+EXAMPLE ARP OPERATION
+
+   Here is a review of the operation of ARP as defined in RFC-826 [5].
+   Let hosts X and Y exist on the same Ethernet cable.  They have
+   physical Ethernet addresses EA(X), and EA(Y), and DoD Internet
+   addresses IPA(X), and IPA(Y).  Let the Ethernet type of Internet be
+   ET(IP).  Host X begins an application, and sooner or later wishes to
+   communicate an Internet packet to host Y.  Host X has knowledge of
+   the Internet address of Y, i.e., (IPA(Y)), and informs the lower
+   level that it wishes to talk to IPA(Y).  The lower-level subsequently
+   consults the ARP Module (ARM) to convert <ET(IP),IPA(Y)> into a 48
+   bit Ethernet address but because X has not talked to Y previously, it
+   does not have this information in its Translation Cache (TC).  It
+   discards (or queues) the Internet packet, and creates a 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)
+
+   It then broadcasts this packet to all hosts on the connecting cable.
+   Host Y picks up this packet and determines that it understands the
+   hardware type (Ethernet), that it speaks the indicated protocol
+   (Internet), and that the packet is for it, that is, TARGET PROTOCOL
+   ADDRESS = IPA(Y).  Replacing any previous entry, it enters the
+   information that <ET(IP),IPA(X) translates to EA(X).  It then learns
+   that this is an ARREQ packet, so it swaps fields, placing EA(Y) in
+   the new sender Ethernet address field SOURCE HARDWARE ADDRESS, EA(X)
+   as TARGET HARDWARE ADDRESS, IPA(X) as TARGET PROTOCOL ADDRESS, IPA(Y)
+   as SOURCE PROTOCOL ADDRESS, and sets the opcode to REPLY.  The packet
+   is then sent with direct routing address information to EA(X).  Thus,
+   Y now knows how to send to X, but X still doesn't know EA(Y).
+
+
+
+Parr                                                            [Page 3]
+
+RFC 1029           Fault Tolerant ARP for Multi-LANs            May 1988
+
+
+   When X receives the ARREP packet from Y, it gets the address
+   information into its translation cache ET(IP),IPA(Y)>-->EA(Y),
+   notices that it is a REPLY, and discards the packet (i.e., disposes
+   of the dynamic packet buffer).  However, if the original Internet
+   Module packet had been queued, it could have been accessed and given
+   the full addressing information from the translation cache.
+   Alternatively, had it been discarded, the higher level would have
+   succeeded on a subsequent attempt, and the Internet packet would be
+   transmitted immediately.
+
+OBTAINING GREATER NETWORKING RANGE
+
+   There are many benefits to be gained in dividing a large multiuser
+   network into smaller, more manageable networks.  These include : Data
+   Security; Overall Network Reliability; Performance Enhancement; not
+   to mention the most obvious: Greater Networking Range.  In some
+   network technologies, cable length may be stipulated not to exceed a
+   certain range due to electrical limitations.  By installing a Bridge,
+   this restriction is effectively eliminated.  An important
+   consideration is the effect the induced Bridge delays will have on
+   the protocol timeouts in operation on each LAN/Subnet.  Careful
+   analysis of upper bounds on timeouts would have to be made in order
+   to gain full benefit from the increased range.  In the case of
+   Ethernet the following system parameters exist [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 a decision has being taken to subnet, the resulting subLANs may
+   be connected by including a Bridge to link them together and
+   providing a protocol which makes the collection of subnets appear as
+   a single network.  The basic idea of the Bridge providing 'repeater'
+   facilities would not suffice in this application.  Moreover, the
+   Bridge would have to have further 'intelligence' to enable it to
+   select those packets which are destined for remote networks based on
+
+
+
+Parr                                                            [Page 4]
+
+RFC 1029           Fault Tolerant ARP for Multi-LANs            May 1988
+
+
+   the protocol address of the target host.  Thereby preventing it from
+   forwarding packets needlessly that will not be accepted.  If this
+   procedure was not adhered to, the channel bandwidth on the remote
+   networks would be inundated with packets, causing local valid traffic
+   to backoff and the efficiency of the respective networks to rapidly
+   decrease.
+
+   One problem fundamental to the operation of the Bridge is how it
+   discovers on which LAN a particular host is interfaced.  If there are
+   only two LANs in the system, each will have a dedicated cache at the
+   Bridge, and when a packet is received at the particular interface,
+   the source host's address parameters are entered in the respective
+   LAN cache.  However, when we consider a Multi-LAN environment, the
+   procedure becomes 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 would receive a packet on E4,
+   they would both update the caches on their E4 interface.  In
+   addition, a method must be provided to permit B4 to distinguish
+   between packets arriving on E4 from E1, E2, E3, and those which
+   actually originated on E4.
+
+
+
+Parr                                                            [Page 5]
+
+RFC 1029           Fault Tolerant ARP for Multi-LANs            May 1988
+
+
+   This is so that packets can be categorized as being of remote or
+   local source and processed accordingly.  The most obvious solution is
+   for each Bridge to act as an AGENT and plug in its address as the
+   source of any packets it cascades to a remote network, instead of the
+   packet being cascaded with its original source address.  At Bridge
+   boot, it may issue a broadcast request for all locally connected
+   hosts/devices to return their local network protocol addresses.  On
+   subsequent receipt of this information, the Bridge could then update
+   the cache for each of its interfaces so that it would now have a base
+   from which to perform future operations.
+
+   The alternative to this automatic procedure is to permit manual
+   intervention in the Bridge software which could be activated by the
+   network manager in order to key in the addresses of the hosts
+   connected to each LAN interface.
+
+   Thus, having provided a means for the Bridge to obtain the original
+   state of the LAN addresses when it boots, how then does the Bridge
+   distinguish the arrival of a new host on the locally connected system
+   from transmissions which were sent from a remote source and cascaded
+   by an adjacent Bridge?  Two approaches are currently under
+   consideration to solve this problem, namely Explicit Subnets, and
+   Transparent Subnets [4], [7], [9], [14].
+
+   In the Explicit Subnet approach, the location of the host in the
+   system is important.  The address of the host in the protocol suite
+   will reflect which subnet the host is interfaced to.  Consequently
+   the protocol address space is divided into a three level hierarchy of
+   <network,subnet,host>.  Within the Internet there are five addressing
+   divisions in operation [10], classes A, B, C, D, and E.  Classes D
+   and E relate to an addressing technique that will be used for
+   management of multi-casting groups and will not be discussed here.
+   With such a structure, it is possible to provide an address mask at
+   each interface so that received packets may have their source address
+   fields examined and compared with the address mask of this LAN.  In
+   so doing, the component which is being verified is actually the
+   subnet address.  If the masking operation is successful the source
+   must exist on this LAN, otherwise it must be remote.
+
+   With the Transparent scheme, the first time a newly booted host
+   'speaks' it will be looking for addressing information (probably
+   using BOOTSTRAP [1], RARP [2] or ARP [5]).  Accordingly, the Bridge
+   will detect these respective requests and be in a position to perform
+   operations on the address parameters.  The current approach in
+   Transparent Subnetting is that before any such requests can be
+   cascaded by the Bridge to an adjacent LAN, that Bridge will place its
+   interface address parameters into the source address fields, thus
+   acting as the AGENT.  Therefore, this Bridge will 'see' either
+
+
+
+Parr                                                            [Page 6]
+
+RFC 1029           Fault Tolerant ARP for Multi-LANs            May 1988
+
+
+   packets arriving from the remote Bridge address, or local packets.
+   By virtue of the RARP/ARP operation, which hosts perform when they
+   first come up, any hi-level packets received on to the network not
+   having the bridge address, and not having a mapping in the cache for
+   that LAN, can be considered as being remote.
+
+   Currently, there is a move toward the Transparent subnet proposal
+   originally described by Postel [7].  This has been due mainly to
+   practical problems of incompatible implementations from different
+   vendors, and the restrictions that the Explicit address space place
+   on the adaptability of the system to change (class C addresses are
+   not flexible enough for the Explicit scheme).  It is also the opinion
+   of the Author of this paper that the Agent technique adopted by the
+   Bridges could have shortcomings in a dynamic environment which would
+   be detrimental to its operation; for example, where the bridges
+   themselves relocate or crash, or in the management of the "Agent For
+   Who" cache at the bridge.  Insofar as Loop Resolution and
+   SelfStabilization after failure are Bridge problems that need to be
+   addressed, it is strongly felt their satisfactory solution will be
+   supported by elimination of the Agent technique [13].
+
+BRIDGE OPERATIONS
+
+   Referring to figure 1, assume that at some stage during its
+   processing [E1H3] wishes to communicate with [E2H19].  [E1H3] obtains
+   knowledge of the Internet address of [E2H19] from its translation
+   cache, but will not require the knowledge that [E2H19] exists on a
+   completely different subnet.  [E1H3] calls its Internet Module to
+   transmit the packet.  As detailed, the usual procedure of passing
+   control to its ARM is performed in an attempt to obtain a
+   translation.  If we assume that [E1H3], and [E2H19] have not talked
+   before, the ARM in [E1H3] will not be able to resolve the addresses
+   on the first attempt.
+
+   In such a case, an ARREQ packet is assembled and broadcast to all
+   hosts on the network [E1].  The packet traverses the cable and is
+   eventually picked up by the (B1) Bridge Address Resolution Module
+   (BARM), whereupon it determines whether or not it should intervene in
+   the request.  If the target is determined as remote (i.e., having no
+   match in the local cache), the BARM examines its Global Translation
+   Cache (GTC) to determine if it has an entry for <protocol,[E2H19]>.
+   Should a mapping be obtained at the Bridge, there is no need for the
+   broadcast REQUEST packet to be cascaded on to the remote network
+   [E2].  It is therefore assumed that the entries in the GTC reflect
+   the most current addressing information.  A match thus obtained, the
+   original ARREQ packet buffer is adapted as required and returned
+   directly to [E1H3] via the Bridges hardware interface IFE1.
+
+
+
+
+Parr                                                            [Page 7]
+
+RFC 1029           Fault Tolerant ARP for Multi-LANs            May 1988
+
+
+   On the other hand, should the Bridges' GTC have no information on
+   [E2H19], the BARM would have to perform the following steps:
+
+      1.  drop the current ARREQ from [E1H3],
+
+      2.  create its own ARREQ using the Bridge source addresses
+          and copy the target_internet_addr from the original
+          [E1H3] ARREQ packet,
+
+      3.  broadcast the ARREQ on network E2 via network interface
+          IFE2, and go into a timeout awaiting a REPLY.
+
+   Should this timeout period expire, a number of retries will be
+   permitted under control of the BARM.  Alternatively, if a REPLY is
+   received within the timeout interval, then the BARM will update its
+   GTC.  The ARM of [E1H3] next will attempt to transmit another ARREQ,
+   but this time a mapping will be obtained at the BARM'S GTC, and the
+   appropriate REPLY will be returned.
+
+   Part 1 has described the state of the art of the behaviour of Address
+   Resolution.  Part 2 now extends the study to the more serious problem
+   of rebooting hosts in a multi-LAN system of Ethernets, and the
+   effects such changes have on the integrity of state information held
+   in ARP caches and routing tables.
+
+                                 PART 2
+
+THE CAPTURE OF REBOOTS
+
+   Because Address Resolution packets are broadcast, all hosts on the
+   connecting cable including the Transparent Bridge will pick them up
+   and determine what they are.  Referring to figure 1, it may well be
+   the case that a host on E1 wishes to communicate with a fellow host
+   on the same physical ether.  Hence, if Hx wishes to talk to Hw on the
+   same ether, but has not done so previously, it will broadcast an
+   Address Resolution packet in the normal fashion.  The Bridge will
+   also 'see' the packet as it passes by, and will act as described
+   above, unless that is, there is some method of preventing it doing
+   so; there is no point in the Bridge invoking its ARM, and wasting
+   processing time if the problem is going to be resolved locally.
+
+   It may occur however, that H1 wants to communicate with H5.  If
+   however, H5 has not talked with anyone before (i.e., it has been
+   "dormant"), H1 will issue an ARREQ.  The Bridge will not know that H5
+   is local because it won't have been entered in the local address
+   cache from previous conversations.  To avoid broadcasting an ARREQ to
+   all networks/subnets, one way around this problem is to set up the
+   contents of the local cache at Bridge startup time.  Therefore, the
+
+
+
+Parr                                                            [Page 8]
+
+RFC 1029           Fault Tolerant ARP for Multi-LANs            May 1988
+
+
+   Bridge will already know not to intervene.  Thus, if the Bridge (with
+   2 nets) finds that a particular IP destination address is not in the
+   local cache of interface 1, it would have to examine its GTC and scan
+   it for a mapping.  Should no mapping be obtained at interface 2, one
+   of two possibilities exist:
+
+        1. the target host doesn't exist locally
+
+        2. the caches are corrupt (the eventuality of this should
+           be negligible!)
+
+   If it is assumed that each of the translation caches contains have
+   the most recent addressing information regarding its own domain of
+   the network then, in this example, if the Bridge does not get a
+   mapping at the GTC it would appear that the host must exist remotely
+   from E1, and E2.
+
+   Such a conclusion would ignore cases in which a host unplugs from a
+   particular hardware interface and plugs into another hardware
+   interface, or where logical names are reassigned to different
+   interfaces due to host user change.  Either of these events could
+   happen had the host being accessed on E2, which would mean that a
+   REBOOT has taken place.
+
+   Anticipating these possiblities local caches are essential.  In
+   normal operation, the Bridge will process and forward IP packets
+   received from one network, and destined for another.  If the Bridge
+   picks up an ARREQ, it will first look for a mapping in its GTC before
+   discarding the original ARREQ, and transmitting its own to the remote
+   network.  In any case, the Bridge will always examine the local cache
+   entries at the receiving interface, so that it may determine if the
+   target address is local or remote.  When the Bridge first scans the
+   local cache, it does so with the source IP address as the key.  If no
+   mapping is retrieved, it then scans the GTC with the same key.
+   Should a mapping now be obtained, it remains for the Bridge to insert
+   the source IP into the local cache, where it has either been
+   previously deleted or corrupted.
+
+   However, if the source IP exists in the respective local cache, the
+   validity of the source Ethernet address should also be verified by
+   examining the respective entry in the GTC.  A scan of the GTC is then
+   performed 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 do
+   not match, then we have uncovered a Hardware Reboot condition (i.e.,
+   a change in Ethernet ID).  On the other hand, should the scan of the
+   GTC with <protocol,source_prot_addr> fail to obtain a mapping, then
+   the Bridge would scan the GTC with the current Ethernet address in
+
+
+
+Parr                                                            [Page 9]
+
+RFC 1029           Fault Tolerant ARP for Multi-LANs            May 1988
+
+
+   the packet header.  If this obtains a mapping, then a Protocol Reboot
+   condition (i.e., change in logical ID) has been detected.
+
+   In the next section, the implications of these forms of 'Reboot' are
+   discussed.
+
+REBOOT SCENARIO
+
+   In normal operation, packets will uneventfully traverse each subnet
+   either as complete Internet packets, broadcast ARREQ's, or direct
+   ARREP's.  The Bridge attached to each subnet will 'hear', and 'see'
+   all packets as they travel past its connected interfaces.  Because of
+   the existence of the local caches at each interface, the Bridge can
+   decide whether or not to intervene.  In general circumstances, each
+   host on the Catenet will have a translation cache containing
+   <protocol,source_prot_addr,source_et_addr> entries for all packets it
+   has observed.  Most of these entries will have been due to processing
+   ARREQ packets, which were broadcast, and by receiving REPLY packets.
+   In accordance with the foregoing , the Bridge will have a cache
+   attached to each subnet interface containing entries for protocol
+   addresses.
+
+   Within the Bridge's Global Translation Cache (GTC) will be entries of
+   all <protocol,source_prot_addr,source_hrd_addr> triplets relating to
+   valid hosts which have been recognised.  If we assume that we have
+   just connected up a Catenet such as that illustrated in figure 1,
+   then at power-up no stations will have knowledge 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 will be in existence will be the protocol
+   addresses stored in the local caches of the Bridges.
+
+   The hosts subsequently begin to run applications and will want to
+   communicate with one another.  The first ARREQ is broadcast on the
+   respective subnet and all hosts, including the Bridge's interface to
+   the subnet, will pick it up and store the details.  If, for example,
+   Hx issues an ARREQ for Hq, the Bridge will not intervene since there
+   is no need (providing no reboot has occurred at Hq).  However, if Hx
+   wishes to talk with Hz, B1 will determine that the target IP in the
+   respective ARREQ does not exist in the local cache of IFE1, so it
+   will examine the GTC, with the <protocol,target_prot_addr> of Hw as
+   the key.
+
+   It is assumed that there will be a timeout mechanism in operation at
+   the source of any packet.  In addition, the Bridge may also place the
+   target address in a 'search list' of currently sought hosts, so as to
+   prevent ARREQs from different sources being cascaded for the same
+   target.  Under these conditions, Hx may re-issue its original ARREQ,
+
+
+
+Parr                                                           [Page 10]
+
+RFC 1029           Fault Tolerant ARP for Multi-LANs            May 1988
+
+
+   but will be ignored until the host Hw has replied to the ARREQ
+   transmitted by the Bridge.
+
+NORMAL RUNNING STATE
+
+   Assuming that a few ARP's have been issued, IP packets will start
+   traversing the Catenet with full addressing information.  Again, the
+   Bridges will 'see' all the packets.  If we extend the situation one
+   step further, and assume that several conversations have taken place
+   across the Catenet, there will be entries in the translation caches
+   of the hosts concerned, regarding the
+   <protocol,target_prot_addr,target_hrd_addr> triplets of those hosts
+   with which the conversations took place.  The Bridges also, will have
+   details in their GTC's for packets which they cascaded.
+
+   If a host is relocated, any connections initiated by that host will
+   still work, provided that its own translation cache is cleared when
+   it does physically move.  However, any connections subsequently
+   initiated to it by other hosts on the Catenet will have no particular
+   reason to know to discard their old translation for that host.
+   Ideally, 48 bit Ethernet addresses will be unique and fixed for all
+   time.
+
+RECOGNITION OF THESE REBOOT CONDITIONS
+
+   With reference to figure 1, assume that for some reason a fault
+   occurs on the hardware interface of <E1He>.  The result of this is
+   that a new interface is installed with a newly acquired hardware
+   address.  When <E1He> is powered up, the previous contents of its
+   translation cache are cleared and it has no recollection of local, or
+   remote host addresses.  Accordingly, <E1He> begins to issue ARREQ's
+   to hosts it requires.  Whenever <E1He> transmits its first ARREQ, it
+   could be termed a 'HELLO PACKET', since everyone on the subnet can
+   pick up the packet, and store the relevant information in their
+   translation caches.  Within hosts, a mapping will be found on the old
+   <protocol,source_prot_addr> pair, and the current <et_addr> of the
+   packet header will replace whatever is entered in the translation
+   cache.
+
+   At this point it would be easy for each host with an entry to
+   recognise the Hardware Reboot situation and inform the subnet with a
+   respective broadcast reboot packet.  But allowing such a procedure
+   would be extremly inefficient on the broadcast medium, and would
+   drastically outweigh any improvements in performance which might be
+   obtained in the long term.  In any case, given the fact that the
+   ARREQ is broadcast, all stations on the subnet will recognise the
+   reboot.  The important point to consider is the effect such a reboot
+   will have on subsequent conversations which are initiated remotely.
+
+
+
+Parr                                                           [Page 11]
+
+RFC 1029           Fault Tolerant ARP for Multi-LANs            May 1988
+
+
+   Can redundant transmissions be thwarted before they tie up processing
+   time on hosts en-route to the rebooted target?  How these
+   difficulties are resolved is critical to the level of performance
+   obtained in a Catenet configuration.  Since it is not optimal for
+   hosts to inform the system of a reboot, it is left to the Bridge.
+   Whenever the Bridge receives a packet, be it IP, or ARP, it examines
+   the source address parameters in the packet header, in the hope of
+   detecting any incompatibilities between them and the entries in its
+   caches.  There are three distinct possibilities, namely, a difference
+   in the 48 bit hardware address only, a difference in the protocol
+   address, and two completely new addresses.  If an incompatibility is
+   discovered, a "REBOOT" packet is constructed and issued on all remote
+   interfaces containing the appropiate information, allowing Bridges to
+   update their GTC's and generic hosts their ARP caches.
+
+   The structure of the Reboot packet is as depicted 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
+
+
+
+Parr                                                           [Page 12]
+
+RFC 1029           Fault Tolerant ARP for Multi-LANs            May 1988
+
+
+   The following definitions apply:
+
+        PACKET FIELD              VALUE
+
+        OPCODE                    REBOOT
+
+        REBOOT OPCODE             HARDWARE
+
+        REBOOT OPCODE             PROTOCOL
+
+   The format is then as follows:
+
+        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 may be an advantage to have a
+   field which specifies the length of addresses in the Ethernet and
+   protocol address spaces.  Thus, the Reboot packet structure contains
+   the following:
+
+   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
+
+
+
+
+
+Parr                                                           [Page 13]
+
+RFC 1029           Fault Tolerant ARP for Multi-LANs            May 1988
+
+
+   As shown, depending on the REBOOT-OPCODE, the structure will continue
+   with either the 48 bit old hardware address or the 32 bit old
+   protocol address.  The choice of a variant packet structure is for
+   reasons of curtailing the size of the packet to the fields that are
+   truely necessary in each situation.  From this Reboot packet
+   structure, the process of generating such a packet can be considered.
+   When the Bridge algorithm detects a reboot, it should create a reboot
+   packet structure containing the relevant addressing information and
+   subsequently multicast it on the interface(s) which access(es) the
+   remote subnet(s).  The decision as to which interface(s) is/are
+   local, and which is/are remote, can be resolved automatically
+   whenever a packet is received.  With respect to this packet transfer
+   the receive interface at the Bridge becomes local, and all others are
+   tagged as remote.
+
+   Thus, hosts on the subnet remote from the reboot are informed of the
+   situation immediately as it is detected by the Bridge.  In the
+   Catenet configuration illustrated in fig 1, this will have the effect
+   of updating the Translation Cache within each host, whenever it
+   receives the packet.  If for example, <E4Hw> reboots under hardware,
+   B3 will detect this occurance.  There is no reason for the subnets
+   E1, E2, E3 to be aware of this episode.  In normal operation, B3 will
+   recognise the reboot from the first ARREQ issued from <E4Hw>.  With
+   this reboot detection facility, B3 will be in a position to inform
+   the hosts on E1, E2, and E3.  B3 can then create and issue the Reboot
+   packet via its interface with E3.  When B3 picks it up, it will
+   update its own caches and subsequently cascade the packet onto E2,
+   where it will be passed on to E1 via B1.
+
+ARGUMENTS FOR REBOOT PACKETS
+
+   It is envisaged that introducing Reboot packets, will serve to
+   enhance the bandwidth achievable within a Catenet system.  Problems
+   of addressing 'dead' hosts will no longer exist in a correctly
+   functioning configuration.  Translation Caches will have on hand the
+   most recent addressing information available, which should also serve
+   to enhance the performance of the routing strategy in operation.
+   Multiple, redundant processing of packets destined for 'dead' hosts
+   will be avoided.  Weighing this against the processing involved with
+   a single multicast of Reboot packets, it is expected that the latter
+   will be is the most economically viable in relation to the long-term
+   traffic presented to the system.
+
+CONCLUSION
+
+   It appears that reboots are becoming increasingly common on internet
+   networks.  Many sites use Personal Computers (PC) as terminals and
+   the typical way to finish a session is to switch them off!  With the
+
+
+
+Parr                                                           [Page 14]
+
+RFC 1029           Fault Tolerant ARP for Multi-LANs            May 1988
+
+
+   increasing popularity of multitasking Operating Systems on these
+   types of machines, problems are more likely to occur, particularly
+   when the PCs are diskless, or participating in a distributed file
+   system of some kind.  Given the importance of correct addressing in
+   communications networks running Ethernet, it is anticipated the
+   reboot mechanism described will serve to improve the correctness and
+   validity of the protocol/network address mappings which may be stored
+   in the translation caches.  To this degree, simulation is expected to
+   show that the volume of invalid traffic will decrease, to the benefit
+   of hosts, Bridges and servers alike.  Likewise, ratification of the
+   routing policy is anticipated and since redundant/obsolete packets
+   will be thwarted, the efficient utilization of available channel
+   bandwidth across the catenet is also expected to improve.  Thus,
+   effectively increasing Catenet throughput for 'valid' packets, and
+   therefore enhancing the level of service provided to the end users.
+
+   It is obvious that the proposed scheme implies the alteration of the
+   packet processing code in Bridges/Gateways.  The point to remember is
+   the increased favour with which larger, more complex Multi-LAN
+   systems of Ethernets are being received.  The recent adaption of
+   extra telephone cables to serve as the transmission media for the
+   Ethernet can only result in installation costs being reduced, therein
+   making the Ethernet more attractive within large corporate buildings,
+   etc.  It is sensible to suggest that the probability of host address
+   re-assignment shall increase in proportion to the number of physical
+   systems attached, 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 currently being developed to analyse the resultant
+   traffic patterns under this scheme, and it is hoped to highlight
+   thresholds where adoption of the scheme becomes a necessity.
+
+   In addition, the Author is currently extending the boundaries of this
+   problem to encompass the reboot, or relocation of Bridges themselves.
+   Involved with this are the phenomena of loop resolution, load sharing
+   and duplicate packet suppression.  It is envisaged that a Self-
+   Stabilizationg Bridge Protocol will result that will be more "light-
+   weight" than those adhering to the Spanning Tree Algorithm.
+
+   The Author would appreciate feedback/comments on this RFC.  My
+   network address is: CBAD13%UCVAX.ULSTER.AC.UK@CUNYVM.CUNY.EDU.
+
+ACKNOWLEDGEMENTS
+
+   The Author acknowledges with gratitute the help and comments
+   contributed by Mr. Piotr Bielkowitz (Supervisor) of the Computing
+   Science Department, and the time devoted my Mr. Raymond Robinson for
+   painstakingly preparing the first draft of this paper on 'Pagemaker'.
+
+
+
+Parr                                                           [Page 15]
+
+RFC 1029           Fault Tolerant ARP for Multi-LANs            May 1988
+
+
+   Thanks are due also 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 of which the Author
+   is extremely grateful.
+
+REFERENCES
+
+   [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
+
+
+
+Parr                                                           [Page 16]
+
+RFC 1029           Fault Tolerant ARP for Multi-LANs            May 1988
+
+
+        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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Parr                                                           [Page 17]
+