As per Relevance of the word broadcast, we have this rfc below:
Network Working Group Smoot Carl-
Request for Comments: 1027 Texas Internet
John S.
Texas Internet
October 1987
Using ARP to Implement Transparent Subnet
Status of this
This RFC describes the use of the Ethernet Address
Protocol (ARP) by subnet gateways to permit hosts on the
subnets to communicate without being aware of the existence
subnets, using the technique of "Proxy ARP" [6]. It is based
RFC-950 [1], RFC-922 [2], and RFC-826 [3] and is a restricted
of the mechanism of RFC-925 [4]. Distribution of this memo
unlimited
The work described in this memo was performed while the authors
employed by the Computer Sciences Department of the University
Texas at Austin
The purpose of this memo is to describe in detail the
of transparent subnet ARP gateways using the technique of Proxy ARP
The intent is to document this widely used technique
1.
The Ethernet at the University of Texas at Austin is a
installation connecting over ten buildings. It currently has
than one hundred hosts connected to it [5]. The size of
Ethernet and the amount of traffic it handles prohibit tying
together by use of repeaters. The use of subnets provided
attractive alternative for separating the network into
distinct units
This is exactly the situation for which Internet subnets
described in RFC-950 are intended. Unfortunately, many vendors
not yet implemented subnets, and it was not practical to modify
more than half a dozen different operating systems running on
on the local networks
Carl-Mitchell & Quarterman [Page 1]
RFC 1027 ARP and Transparent Subnet Gateways October 1987
Therefore a method for hiding the existence of subnets from
was highly desirable. Since all the local area networks
ARP, an ARP-based method (commonly known as "Proxy ARP" or the "
hack") was chosen. In this memo, whenever the term "subnet"
the "RFC-950 subnet method" is assumed
2.
2.1 Basic
On a network that supports ARP, when host A (the source)
an ARP request for the network address corresponding to the
address of host B (the target), host B will recognize the IP
as its own and will send a point-to-point ARP reply. Host A
the IP-to-network-address mapping found in the reply in a
cache and uses it for later communication with host B
If hosts A and B are on different physical networks, host B will
receive the ARP broadcast request from host A and cannot respond
it. However, if the physical network of host A is connected by
gateway to the physical network of host B, the gateway will see
ARP request from host A. Assuming that subnet numbers are made
correspond to physical networks, the gateway can also tell that
request is for a host that is on a different physical network
the requesting host. The gateway can then respond for host B
saying that the network address for host B is that of the
itself. Host A will see this reply, cache it, and send future
packets for host B to the gateway. The gateway will forward
packets to host B by the usual IP routing mechanisms. The
is acting as an agent for host B, which is why this technique
called "Proxy ARP"; we will refer to this as a transparent
gateway or ARP subnet gateway
When host B replies to traffic from host A, the same
happens in reverse: the gateway connected to the network of host
answers the request for the network address of host A, and host
then sends IP packets for host A to gateway. The physical
of host A and B need not be connected to the same gateway. All
is necessary is that the networks be reachable from the gateway
With this approach, all ARP subnet handling is done in the
subnet gateways. No changes to the normal ARP protocol or
need to be made to the source and target hosts. From the host
of view, there are no subnets, and their physical networks
simply one big IP network. If a host has an implementation
subnets, its network masks must be set to cover only the IP
number, excluding the subnet bits, for the system to work properly
Carl-Mitchell & Quarterman [Page 2]
RFC 1027 ARP and Transparent Subnet Gateways October 1987
2.2
As part of the implementation of subnets, it is expected that
elements of routing tables will include network numbers
both the IP network number and the subnet bits, as specified by
subnet mask, where appropriate. When an ARP request is seen,
ARP subnet gateway can determine whether it knows a route to
target host by looking in the ordinary routing table. If
to reach foreign IP networks are eliminated early (see Sanity
below), only a request for an address on the local IP network
reach this point. We will assume that the same network mask
to every subnet of the same IP network. The network mask of
network interface on which the ARP request arrived can then
applied to the target IP address to produce the network part to
looked up in the routing table
In 4.3BSD (and probably in other operating systems), a default
is possible. This default route specifies an address to forward
packet to when no other route is found. The default route must
be used when checking for a route to the target host of an
request. If the default route were used, the check would
succeed. But the host specified by the default route is unlikely
know about subnet routing (since it is usually an Internet gateway),
and thus packets sent to it will probably be lost. This
case in the routing lookup method is the only implementation
needed to the routing mechanism
If the network interfaces on which the request was received
through which the route to the target passes are the same,
gateway must not reply. In this case, either the target host is
the same physical network as the gateway (and thus the host
reply for itself), or this gateway is not on the most direct path
the desired network, i.e., there is another gateway on the
physical network that is on a more direct path and the other
should respond
RFC-925 [4] describes a general mechanism for dynamic subnet
using Proxy ARP and routing caches in the gateways. Our
is restricted subset of RFC-925, in which we use static
routes which are determined administratively. As a result,
transparent subnet gateways require no new network routing
entries nor ARP cache entries; the only tables which are
are the ARP caches in the host
In our implementation, routing loops are prevented by
administration of the subnet routing tables in the gateways
Carl-Mitchell & Quarterman [Page 3]
RFC 1027 ARP and Transparent Subnet Gateways October 1987
2.3 Multiple
The simplest subnet organization to administer is a tree structure
which cannot have loops. However, it may be desirable
reliability or traffic accommodation to have more than one
(or path) between two physical networks. ARP subnet gateways may
used in such a situation: a requesting host will use the first
response it receives, even if more than one gateway supplies one
This may even provide a rudimentary load balancing service, since
two gateways are otherwise similar, the one most lightly loaded
the more likely to reply first
More complex mechanisms could be built in the form of gateway-to
gateway protocols, and will no doubt become necessary in
with large numbers of subnets and gateways, in the same way
gateway-to-gateway protocols are generally necessary among
gateways
2.4 Sanity
Care must be taken by the network and gateway administrators to
the network masks the same on all the subnet gateway machines.
most common error is to set the network mask on a host without
subnet implementation to include the subnet number. This causes
host to fail to attempt to send packets to hosts not on its
subnet. Adjusting its routing tables will not help, since it
not know how to route to subnets
If the IP networks of the source and target hosts of an ARP
are different, an ARP subnet gateway implementation should
reply. This is to prevent the ARP subnet gateway from being used
reach foreign IP networks and thus possibly bypass security
provided by IP gateways
An ARP subnet gateway implementation must not reply if the
networks of the source and target of an ARP request are the same
In this case, either the target host is presumably either on
same physical network as the source host and can answer for itself
or the target host lies in the same direction from the gateway
does the source host, and an ARP reply from the would cause a loop
An ARP request for a broadcast address must elicit no reply
regardless of the source address or physical networks involved.
the gateway were to respond with an ARP reply in this situation,
would be inviting the original source to send actual traffic to
broadcast address. This could result in the "Chernobyl effect
wherein every host on the network replies to such traffic,
network "meltdown".
Carl-Mitchell & Quarterman [Page 4]
RFC 1027 ARP and Transparent Subnet Gateways October 1987
2.5 Multiple logical subnets per physical
The most straightforward way to assign subnet numbers is one to
with physical networks. There are, however, circumstances in
multiple logical subnets per physical network are quite useful.
of the more common is when it is planned that a group
workstations will be put on their own physical network but
gateway to the new physical network needs to be tested first. (
repeater might be used when the gateway was not usable). If a
of one subnet per physical network is enforced, the addresses of
workstations must be changed every time the gateway is tested.
they may be assigned addresses using a new subnet number while
are still on the old physical network, no further address
are needed
To permit multiple subnets per physical network, an ARP
gateway must use the physical network interface, not the
number to determine when to reply to an ARP request. That is,
should send a proxy ARP reply only when the source network
differs from the target network interface. In addition,
routing table entries for these "phantom" subnets must be added
the subnet gateway routing tables
2.6 Broadcast
There are two kinds of IP broadcast addresses: main IP
network broadcast and subnet broadcast. An IP network
address consists of the network number plus a well-known value
the rest (local part) of the address. An IP subnet broadcast
similar, except both the IP network number and the subnet
bits are included. RFC-922 standardized the use of all ones in
local part, but there were two conventions in use before that:
ones and all zeros. For example, 4.2BSD used all zeros, and 4.3
uses all ones. Thus there are four kinds of IP directed
addresses still currently in use on many networks
With transparent subnetting a subnet gateway must not issue an
broadcast using the subnet broadcast address, e.g., 128.83.138.255.
Hosts on the physical network that receive the broadcast will
understand such an address as a broadcast address, since they
not have subnets enabled (or will not have subnet implementations).
In fact, 4.2BSD hosts (with or without subnet implementations)
instead treat an address with all ones in the local part as
specific host address and try to forward the packet. Since there
no such target host, there will be no entry in the forwarding host'
ARP tables and it will generate an ARP request for the target host
This presents the scenario (actually observed) of a 4.3BSD
running the rwho program, which broadcasts a packet once a minute
Carl-Mitchell & Quarterman [Page 5]
RFC 1027 ARP and Transparent Subnet Gateways October 1987
causing every 4.2BSD host on the local physical network to
an ARP request at the same time. The same problem occurs with
subnet broadcast address, whether the local part is all zeros or
ones
Thus a subnet gateway in a network with hosts that do not
subnets must take care not to use subnet broadcast addresses
instead it must use the IP network directed broadcast
instead
Finally, since many hosts running out-of-date software will still
using (and expecting) old-style all-zeros IP network
addresses, the gateway must send its broadcast addresses out in
form, e.g., 128.83.0.0. It might be safe to also send a
packet with all ones in the local part, e.g., 128.83.255.255. It
not clear whether the local network broadcast address of all ones
255.255.255.255, will cause ill effects, but it is very likely
it will not be recognized by many hosts that are running
software
3. Implementation in 4.3
Subnet gateways using ARP have been implemented by a number
different people. The particular method described in this memo
first implemented in 4.2BSD on top of retrofitted beta-test 4.3
subnet code, and has since been reimplemented as an add-on to
distributed 4.3BSD sources. The latter implementation is
here
Most of the new kernel code for the subnet ARP gatewaying
is in the generic Ethernet interface module, netinet/if_ether.c.
consists of eight lines in in_arpinput that perform a couple
quick checks (to ensure that the facility is enabled on the
interface and that the source and target addresses are on
subnets), call a new routine, if_subarp, for further checks,
then build the ARP response if all checks succeed. This code
only reached when an ARP request is received, and does nothing
the facility is not enabled on the source interface.
performance of the gateway should be very little degraded by
addition. (Performance of the requesting host should also
similar to the latter case, as the only difference there is
efficiency of the ARP cache and of the routing tables).
The routine if_subarp (about sixty lines) ensures that the
and target addresses are on the same IP network and that the
address is none of the four kinds of directed broadcast address.
then attempts to find a path to the target either by finding
network interface with the desired subnet or by looking in
Carl-Mitchell & Quarterman [Page 6]
RFC 1027 ARP and Transparent Subnet Gateways October 1987
routing tables. Even if a network interface is found that leads
the target, for a reply to be sent the ARP gateway must be
on that interface and the target and source interfaces must
different
The file netinet/route.c has a static routing entry
definition added, and modifications of about eight lines are made
the main routing table lookup routine, rtalloc, to recognize
pointer to that structure (when passed by if_subarp) as a
to not use the default route in this routing check. The
priority level (critical section protection) around the
routing lookup check is changed to a higher value, as the
may now be called from network interface interrupts as well as
the internal software interrupts that drive processing of IP
other high level protocols. This raised processor priority
conceivably slow the whole kernel somewhat if there are many
checks, but since the critical section is fast, the effect should
small
A key kernel modification is about fifteen lines added to
routine ip_output in netinet/ip_output.c. It changes
broadcast addresses in packets originating at the gateway to
network broadcast addresses so that hosts without subnet code (
with their network masks set to ignore subnets) will recognize
as broadcast addresses. This section of code is only used if
ARP gateway is turned on for the outgoing interface, and
affects subnet broadcast addresses
A new routine, in_mainnetof, of about fifteen lines, is added
netinet/in.c to return the IP network number (without subnet number
from an IP address. It is called from if_subarp and ip_output
Two kernel parameter files have one line added to each: net/if.
has a definition of a bit in the network interface structure
indicate whether subnet ARP gateways are enabled, and netinet/in.
refers to in_mainnetof
In addition to these approximately 110 lines of kernel
additions, there is one user-level modification. The source to
command ifconfig, which is used to set addresses and network
of network interfaces, has four lines added to allow it to turn
subnet ARP gateway facility on or off, for each interface. This
documented in eleven new lines in the manual entry for that command
Carl-Mitchell & Quarterman [Page 7]
RFC 1027 ARP and Transparent Subnet Gateways October 1987
4.
The 4.3BSD implementation is currently available by anonymous
(login anonymous, password guest) from sally.utexas.edu
pub/subarp, which is a 4.3BSD "diff -c" listing from the 4.3
sources that were distributed in September 1986.
This implementation was not included in the 4.3BSD
proper because U.C. Berkeley CSRG thought that that would reduce
incentive for vendors to implement subnets per RFC-950. The
concur. Nonetheless, there are circumstances in which the use
transparent subnet ARP gateways is indispensable
1. Mogul, J., and J. Postel, "Internet Standard
Procedure", RFC-950, Stanford University and USC/
Sciences Institute, August 1985.
2. Mogul, J., "Broadcasting Internet Datagrams in the Presence
Subnets", RFC-922, Computer Science Department,
University, October 1984.
3. Plummer, D., "An Ethernet Address Resolution Protocol
Converting Network Protocol Addresses to 48-bit
Addresses for Transmission on Ethernet Hardware", RFC-826,
Symbolics, November 1982.
4. Postel, J., "Multi-LAN Address Resolution", RFC-925,
USC/Information Sciences Institute, October 1984.
5. Carl-Mitchell, S., and J. S. Quarterman, "Nameservers in a
Domain", SIGCUE Outlook, Vol.19, No.1/2, pp.78-88, ACM
Computer Uses in Education, P.O. Box 64145, Baltimore, MD 21264,
Spring/Summer 1986.
6. Braden, R., and J. Postel, "Requirements for Internet Gateways",
RFC-1009, USC/Information Sciences Institute, June 1987.
Carl-Mitchell & Quarterman [Page 8]
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
