As per Relevance of the word solution, we have this rfc below:
Network Working Group J.
Request for Comments: 925
October 1984
Multi-LAN Address
STATUS OF THIS
This memo is prompted by RFC-917 by Jeffery Mogul on "
Subnets". In that memo, Mogul makes a case for the use of "
subnets" in a multi-LAN environment. In this memo, I attempt to
a case for "transparent subnets". This RFC suggests a
protocol for the ARPA-Internet community, and requests discussion
suggestions for improvements. Distribution of this memo
unlimited
The problem of treating a set of local area networks (LANs) as
Internet network has generated some interest and concern. It
inappropriate to give each LAN within an site a distinct
network number. It is desirable to hide the details of
interconnections between the LANs within an site from people
gateways, and hosts outside the site. The question arises on how
best do this, and even how to do it at all. One proposal is to
"explicit subnets" [1]. The explicit subnet scheme is a call
recursively apply the mechanisms the Internet uses to manage
to the problem of managing LANs within one network. In this note
urge another approach: the use of "transparent subnets" supported
a multi-LAN extension of the Address Resolution Protocol [2].
To quickly review the Address Resolution Protocol (ARP). Each
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
the IA of Host-B and told to send a datagram to it, Host-A must
the HA that corresponds to Host-B's IA. To do this Host-A forms
ARP packet that contains its own HA and IA and the IA of
destination host (Host-B). Host-A broadcasts this ARP packet.
hosts that receive this ARP packet check to see if they
destination sought. If so, they (it should be only Host-B) send
reply specifically addressed to the originator of the query (Host-A
and supplying the HA that was needed. The Host-A now has both the
and the IA of the destination (Host-B). The Host-A adds
information to a local cache for future use
Note: The ARP is actually more general purpose than this
sketch indicates
Postel [Page 1]
RFC 925 October 1984
Multi-LAN Address
The idea in this memo is to extend the ARP to work in an
of multiple interconnected LANs
To see how this could work let us imagine a "magic box" (BOX) that
connected as if it were an ordinary host to two (or more) LANs
Hosts continue to behave exactly as they do with the basic ARP
When an ARP query is broadcast by any host the BOX reads it (as
all the hosts on that LAN). In addition to checking whether it
the host sought (and replying if it is), the BOX checks its cache
IA:HA address mappings in the cache that it keeps for each LAN it
attached to
Case 1: If the mapping for the host is found in the cache for
LAN that the query came from, the BOX does not respond (
the sought host respond for itself).
Case 2: If the mapping for the host is found in the cache for
different LAN than the query came from, the BOX sends a
giving its own HA on the LAN the query came from. The BOX acts
an agent for the destination host
Case 3: If the mapping is not found in any of the caches then,
BOX must try to find out the the address, and then respond as
case 1 or 2.
In case 3, the BOX has to do some magic
The BOX keeps a search list of sought hosts. Each
includes the IA of the host sought, the interface the ARP
received on, and the source addresses of the original request
When case 3 occurs, the search list is checked. If the
host is already listed the search is terminated, if not
search is propagated
To propagate the search, an entry is first made on the
list, then the BOX composes and sends an ARP packet on each
its interfaces except the interface the instigating ARP
was received on. If a reply is received, the information
entered into the appropriate cache, the entry is deleted
the search list and a response to the search instigating ARP
made as in case 1 or 2. If no reply is received, give up
do nothing -- no response is sent to the instigating host (
entry stays on the search list).
Postel [Page 2]
RFC 925 October 1984
Multi-LAN Address
To terminate the search, give up and do nothing -- no
is sent to the instigating host (the entry stays on the
list).
The entries in the caches and the search list must time out
For every ARP request that is received, the BOX must also put
sending host's IA:HA address mapping into the cache for the LAN
was received on
THE MULTI-LAN ADDRESS RESOLUTION
The plan is to use ARP just as it is. The new element is the "
box" ("ARP-based bridge") that relays the ARP request
neighboring LANs and acts as an agent for relaying datagrams to
on other LANs
The
Hosts continue to behave exactly as they do with the basic ARP
The LANs are connected together by BOXes (computers that
attached to two or more LANs exactly as hosts are attached
LANs). The BOXes implement the following procedure
Each BOX keeps a table for each LAN it is connected to (or
each LAN interface). Entries in these tables time out, so
tables are caches of recent information. The entries in
caches are the IA:HA address pairs for that LAN
When an ARP query is broadcast by any host the BOX reads it (as
all the hosts on that LAN). In addition to checking to see if
is the host sought (and replying if it is), the BOX checks
cache of IA:HA address mappings in the table it keeps for each
it is attached to
Case 1: If the mapping for the host is found in the cache
the LAN that the query came from, the BOX does not
(letting the sought host respond for itself). The time out
this entry is not reinitialized
Case 2: If the mapping for the host is found in the cache for
different LAN than the query came from, the BOX sends a
giving its own HA on the LAN the query came from. The time
on this entry is not reinitialized
In this case the BOX is indicating that it will act as
Postel [Page 3]
RFC 925 October 1984
Multi-LAN Address
agent for the destination host. When an IP datagram
at the BOX, the BOX must attempt to forward it using
information in its address mapping caches
Case 3: If the mapping is not found in any of the caches,
the BOX must try to find out the the address, and then
as in case 1 or 2. In this case, the BOX has to do some magic
The BOX keeps a search list of sought (but not yet found
hosts. Each entry includes the IA of the host sought,
interface the ARP was received on, and the source
of the original request
When case 3 occurs, the search list is checked. If
sought host is already listed the search is terminated,
not the search is propagated
To propagate the search, an entry is first made on
search list, then the BOX composes and sends an ARP
on each of its interfaces. These ARP requests contain
IA and HA of the BOX and the IA of the sought host,
request the HA of the sought host. If a reply is
to the ARP request, the information is entered into
appropriate cache, the entry is deleted from the search
and a response to the search instigating ARP requests
made as in case 1 or 2 above. If no reply is received,
up and do nothing -- no response is sent to the
host (the entry stays on the search list).
Note that the BOX must make a reasonable effort with
ARP requests, if it is normal for ordinary hosts
retry ARP requests five times, then a BOX must also
it's ARP requests five times
To terminate the search, give up and do nothing --
response is sent to the instigating host (the entry stays
the search list).
There is no negative feedback from an ARP request, so
is no way to decide that a search was unsuccessful except
means of a time out
For every ARP request that is received, the BOX must also put
sending hosts IA:HA address mapping into the cache for the LAN
was received on
The entries in the caches and the search list must time out
Postel [Page 4]
RFC 925 October 1984
Multi-LAN Address
The search list must be kept and the termination rule followed
avoid an infinite relaying of an ARP request for a host that
not respond. Once a host is listed in the search list,
requests will not be relayed. If a host that is down (
otherwise not responding to ARP requests), comes up (or
begins responding to ARP requests) it will still not
available to hosts in other LANs until the search list entry
out
There are two approaches to this problem: first, to have
relatively short time out on the search list entries;
second, to have the BOX periodically send ARPs for each
on the search list
There are several time outs involved in this scheme
First, the hosts try to get the address resolved using ARP
They may actually make several attempts before giving up if
host is not responding. One must have an good estimate of
length of time that a host may keep trying. Call this time T1.
Second, there is the time that an entry stays on the
list, or the time between BOX generated ARPs to resolve
addresses. Call this time T2.
Note that this time (T2) must be greater than the sum of
T1s for the longest loop of LANs
Third, there is the time that entries stay in the cache
each LAN. Call this time T3.
The relationship must be T1 < T2 < T3.
One suggestion is that T1 be less than one minute, T2 be
minutes, and T3 be one hour
If the environment is very stable, making T3 longer will
in fewer searches (less overhead in ARP traffic). If
environment is very dynamic making T3 shorter will result
more rapid adaptation to the changes
Another possibility is to restart the timer on the
entries each time they are referenced, and have a small
for T3. This would result in entries that are frequently
staying in the cache, but infrequently used information
discarded quickly. Unfortunately there is no
relationship between frequency of use and correctness.
Postel [Page 5]
RFC 925 October 1984
Multi-LAN Address
method could result in an out-of-date entry persisting in
cache for a very long time if ARP requests for that
mapping were received at just less than the time out period
When handling regular datagrams, the BOXes must decrement the
datagram Time-To-Live field (TTL) and update the IP header
sum. If the TTL becomes zero the datagram is discarded (
forwarded).
ARP, as currently defined, will take the most recent
as the best and most up-to-date. In a complicated multi-
environment where there are loops in the connectivity it is
that one will get two (or more) responses to an ARP request for
host on some other LAN. It is probable that the first
will be from the BOX that is the most efficient path
The one change to the host implementation of ARP that is
here is to prevent later responses from replacing the
recorded from the first response
Potential
Bad Cache
If some wrong information get into a cache entry, it will
there for time T3. The persistence of old information
prevent communication (for a time) if a host changed its IA:
mapping
One way to replace bad or out-of-date entries in a cache
be to have the BOXes explicitly interpret a broadcast ARP
to require an entry with either this IA or HA to be
with this new IA:HA mapping. One could have important
send a broadcast ARP reply when they come up
Non-ARP
It seems unrealistic to expect to use both ARP hosts
non-ARP hosts on the same LAN and expect them to communicate
If all the non-ARP hosts are on the same LAN the situation
considered with under the next heading (Non-Broadcast LANs).
Hosts that do not implement ARP must use some other means
address mapping. Either they hold a complete table of
hosts, or they access some such table in a server via
protocol; or they expect to make all routing decisions based
analysis of address fields
Postel [Page 6]
RFC 925 October 1984
Multi-LAN Address
Non-Broadcast
BOXes that are connected to LANs that do not have
capability and/or LANs where the hosts do not respond to
may have a static or dynamic table of the IA:HA mappings
that LAN (or the addresses may be computed from one another).
All the hosts on that LAN must be in the table
When a BOX must find the address mapping and would
send an ARP request into a non-broadcast LAN (this can
happen when the sought host is not the non-broadcast LAN
all the hosts are in the table), it must instead send an
type request specifically to each of the other BOXes on
LAN
Size of
The worst case of the size of the tables in the BOXes is
number of hosts in the set of LANs for each table. That is
the table kept for each LAN interface may (in the worst case
grow to have an entry for each host in the entire set of LANs
However, these tables are really caches of the entries
for current communication activity and the typical case will
far from the worst case. Most hosts will communicate
with other hosts on their own LAN and with a few hosts on
LANs. Most communication on LANs is between work station
and server hosts. It can be expected that there will
frequent communication involving the main server hosts and
these server hosts will be entered in the tables of most of
BOXes most of the time
Infinite Transmission
The possibility of infinite transmission loops through
interconnected set of LANs is prevented by keeping search
in the BOXes and terminating the search when a request
received for an address already on the list
Transmission loops of regular datagrams can not persist
them the BOXes must decrement the TTL, and discard the
if the TTL is reduced to zero. For debugging purposes it
be useful for a BOX to report to the implementer any
discarded for this reason
Postel [Page 7]
RFC 925 October 1984
Multi-LAN Address
Note that broadcast does not really have anything to do
either transparent subnets or explicit subnets. Since it
discussed in [1], it will be discussed here, too. Two of
three broadcast functions suggested in [1] work just the
and have the same effects, the third can be supported, too
It is also argued that the support for a
interpretation of IAs is a bigger issue that the question
explicit subnets versus transparent subnets and it should
decided separately
It is also suggested that broadcast is not really what
desired, but rather multicast is the better function. It
make sense to understand how to do an Internet multicast
adopting a broadcast scheme
This IP
If the IA of this network number and an all ones host
(e.g., 36.255.255.255) is used, an IP level broadcast to
hosts on this Network (all LANs) is intended. A BOX
forward this datagram. A BOX must examine the datagram
potential significance to the BOX itself
To prevent infinite transmission loops each BOX must keep
list of recent broadcasts. The entries in this list
the source IA and the Identification field from the
header. If a broadcast is received and matches an entry
the list it is discarded and not forwarded. The entries
this list time out in time T2.
This LAN
If the IA of all ones (i.e., 255.255.255.255) is used an
level broadcast to all hosts on this LAN only is intended
A BOX must not forward this datagram. A BOX must
the datagram for potential significance to the BOX itself
Another LAN
Since the LANs are not individually identified in the
this can not be supported in the same way. Some have
argued that this is a silly capability to provide
One way to provide it is to establish a specific IA for
Postel [Page 8]
RFC 925 October 1984
Multi-LAN Address
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, etc. These addresses would
specially interpreted by the BOXes attached to the
LAN where they had the special interpretation, other
would treat these address as any other IAs. Where
addresses are specially interpreted they are converted
the broadcast on this LAN only address
The claim for the extended ARP scheme is that the average host
not even know it is in a multi-LAN environment
If a host took the trouble to analyze its local cache of IA:
address mappings it might discover that several of the IAs
to the same HA. And if it took timing measurements it
discover that some hosts responded with less delay that others
And further, it might be able to find a correlation between
discoveries. But few hosts would take the trouble
Address
In the explicit subnet scheme, some IA bits are devoted
identifying the subnet (i.e., the LAN). The address is broken
into network, subnet, and host fields. Generally, when fields
use the density of the assigned addresses in the address
goes down. That is, there is a less efficient use of the
space. Significant implementation problems may arise if
subnets than planned are installed and it becomes necessary
change the size of the subnet field. It seems totally
to use the explicit subnet scheme with a class C IA
In the extended ARP scheme the address is simply the network,
host fields. The extended ARP scheme may be used with any
of IA
Relocating
In the explicit subnet scheme when a host is unplugged from
LAN and plugged into another its IA must change
In the extended ARP scheme it may keep the same IA
Postel [Page 9]
RFC 925 October 1984
Multi-LAN Address
One view of the situation suggests that there are really
problems
1. How does the host discover if the destination is in this LAN
some other LAN
This question assumes that a host should know the
and should do something different in the two cases, and
that once the host knows the answer it also know how to
the data (e.g., directly to the host, or to the box).
The claim here is that the hosts should not know
difference and should always do the same thing
2. How do the BOXes that connect LANs know which BOXes are
routes to which LANs
This question assumes that the BOXes need some kind
topological knowledge, and exchange BOX-to-BOX
information about connectivity
The claim here is that the BOXes do not need
knowledge and do not need to explicitly know about
existence of other BOXes
It has been suggested that there are two problems: first, how
hosts do routing; and second, how the BOXes do routing. A claim
been made that the competing strategies each have an approach to
problems and one could select a solution made up partly from
approach and partly from another
For example: use ARP within the LAN and have the BOX send
replies and act as a agent (as in the extended ARP scheme),
use a BOX-to-BOX protocol to get the "which hosts are where
information into the BOXes (as in the explicit subnet scheme).
There are two places where code is involved: a large number of hosts
and a small number of BOXes. In considering the trade off
explicit subnet scheme and extended ARP scheme, the work done in
hosts should weigh a lot more than the work done in the BOXes
What do hosts do
Explicit Subnet
The host must be able to decide if this IA is on this LAN
Postel [Page 10]
RFC 925 October 1984
Multi-LAN Address
some other LAN. If on this LAN then use some procedure
find the HA. If on some other LAN then use some
to find the HA of a BOX
Extended ARP
In every case the host uses ARP to get a IA:HA mapping
What do the BOXes do
Explicit Subnet
The BOX must be able to decide which LAN within the site
destination host is on. The BOXes must have some
table that tells for each LAN in the site which interface
send datagrams on. This routing table must be kept up
date, probably by a BOX-to-BOX protocol much like
Internet Gateway-to-Gateway protocol
Extended ARP
The BOX must keep caches for each LAN it is attached to
IA:HA mappings, and it must keep a search list. It does
run any BOX-to-BOX protocol, It does not even know if
other BOXes exist
Topology and Implementation
If the organization of the LANs and the BOXes is
structured, the BOXes may be very simple, they don't have
keep the search lists at all, since there won't be any
for the ARP-request to traverse
If the organization has loops then the search lists
essential. If the topology is kept balanced so that there
no long loops (all loops are about the same size), and the
are reasonably compatible in delay characteristics, then
procedure described here will work well
If the organization is very complex, topologically unbalanced
Postel [Page 11]
RFC 925 October 1984
Multi-LAN Address
and/or composed of mix of different types of LANS with
different delay characteristics, then it may be better to use
BOX-to-BOX routing protocol
It would be useful if the Internet community could come to
agreement on a solution to the multi-LAN network problem and
with a unified voice urge work station manufacturers to provide
solution built in
I urge consideration of the extended ARP scheme expounded on here
I think that most work stations will be connected to LANs that have
broadcast capability. I think that most work stations will be
in situations that do not require explicit subnets, and most will
used in situations where a class C Internet addresses would
appropriate (and explicit subnets impossible). Thus, i think
would be best to ask manufacturers to include support for ARP in
stations off the shelf. I also think we ought to get busy
create, develop, test, and produce the magic boxes I suggest so
they too are available off the shelf
Please note that neither this note nor [1] proposes a
routing procedure or BOX-to-BOX protocol. This is because such
routing procedure is a very hard problem. The plan proposed
will let us get started on using multi-LAN environments in
reasonable way. If we later decide on a routing procedure to be
between the BOXes we can redo the BOXes without having to redo
hosts
Postel [Page 12]
RFC 925 October 1984
Multi-LAN Address
Address Resolution Protocol (see [2]).
Magic Box. A box (computer) connected to two or more LANs of
same Network. Also called an "ARP-based bridge".
A node (computer) connected to two or more
indistinguishable but physically distinct subnets,
automatically forwards datagrams when necessary, but
existence is not know to other hosts. Also called a "
repeater".
The unit of communication at the IP level
Explicit
A Subnet explicitly identified in the the Internet Address by
subnet address field, and so visible to others both in side
out side the Network
A node (computer) connected to two or more
distinct networks and/or subnets, to which hosts send datagrams
be forwarded
Hardware Address, the address used in a packet on a LAN
Host
The address of a host within an Network, the low-order part of
IA
Internet Address, as defined in IP
Postel [Page 13]
RFC 925 October 1984
Multi-LAN Address
The collection of connected Internet Networks (also known as
Catenet). A set of interconnected networks using IP
Internet Protocol (see [3]).
Local Area Network
Multi-LAN
A set of LANs treated as one Network, i.e., using one
Number in common. The individual LANs may be either
Subnets or Transparent Subnets
A single Internet Network (possibly divided into subnets
composed of multiple LANs), identified by an individual
Number
Network
An IP Network Number, the high-order part of an IA
The unit of communication at the LAN hardware level
A subnet of Network. A portion of a Network (either logical
physical).
Transparent
A Subnet not identified in the Internet Address, and so
to others, (see Multi-LAN Network).
The IP Time-To-Live field
Postel [Page 14]
RFC 925 October 1984
Multi-LAN Address
[1] J. Mogul, "Internet Subnets", RFC-917, Stanford University
October 1984.
[2] D. Plummer, "An Ethernet Address Resolution Protocol
Converting Network Protocol Addresses to 48-bit
Addresses for Transmission on Ethernet Hardware", RFC-826,
Symbolics, November 1982.
[3] J. Postel, "Internet Protocol", RFC-791, USC-ISI
September 1981.
Postel [Page 15]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
