home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1027 < prev    next >
Text File  |  1991-04-21  |  21KB  |  446 lines
  1. Network Working Group                                Smoot Carl-Mitchell
  2. Request for Comments: 1027                     Texas Internet Consulting
  3.                                                       John S. Quarterman
  4.                                                Texas Internet Consulting
  5.                                                             October 1987
  6.  
  7.  
  8.            Using ARP to Implement Transparent Subnet Gateways
  9.  
  10.  
  11. Status of this Memo
  12.  
  13.     This RFC describes the use of the Ethernet Address Resolution
  14.     Protocol (ARP) by subnet gateways to permit hosts on the connected
  15.     subnets to communicate without being aware of the existence of
  16.     subnets, using the technique of "Proxy ARP" [6].  It is based on
  17.     RFC-950 [1], RFC-922 [2], and RFC-826 [3] and is a restricted subset
  18.     of the mechanism of RFC-925 [4].  Distribution of this memo is
  19.     unlimited.
  20.  
  21. Acknowledgment
  22.  
  23.     The work described in this memo was performed while the authors were
  24.     employed by the Computer Sciences Department of the University of
  25.     Texas at Austin.
  26.  
  27. Introduction
  28.  
  29.     The purpose of this memo is to describe in detail the implementation
  30.     of transparent subnet ARP gateways using the technique of Proxy ARP.
  31.     The intent is to document this widely used technique.
  32.  
  33. 1.  Motivation
  34.  
  35.     The Ethernet at the University of Texas at Austin is a large
  36.     installation connecting over ten buildings.  It currently has more
  37.     than one hundred hosts connected to it [5].  The size of the
  38.     Ethernet and the amount of traffic it handles prohibit tying it
  39.     together by use of repeaters.  The use of subnets provided an
  40.     attractive alternative for separating the network into smaller
  41.     distinct units.
  42.  
  43.     This is exactly the situation for which Internet subnets as
  44.     described in RFC-950 are intended.  Unfortunately, many vendors had
  45.     not yet implemented subnets, and it was not practical to modify the
  46.     more than half a dozen different operating systems running on hosts
  47.     on the local networks.
  48.  
  49.  
  50.  
  51.  
  52. Carl-Mitchell & Quarterman                                      [Page 1]
  53.  
  54. RFC 1027          ARP and Transparent Subnet Gateways       October 1987
  55.  
  56.  
  57.     Therefore a method for hiding the existence of subnets from hosts
  58.     was highly desirable.  Since all the local area networks supported
  59.     ARP, an ARP-based method (commonly known as "Proxy ARP" or the "ARP
  60.     hack") was chosen.  In this memo, whenever the term "subnet" occurs
  61.     the "RFC-950 subnet method" is assumed.
  62.  
  63. 2.  Design
  64.  
  65. 2.1  Basic method
  66.  
  67.     On a network that supports ARP, when host A (the source) broadcasts
  68.     an ARP request for the network address corresponding to the IP
  69.     address of host B (the target), host B will recognize the IP address
  70.     as its own and will send a point-to-point ARP reply.  Host A keeps
  71.     the IP-to-network-address mapping found in the reply in a local
  72.     cache and uses it for later communication with host B.
  73.  
  74.     If hosts A and B are on different physical networks, host B will not
  75.     receive the ARP broadcast request from host A and cannot respond to
  76.     it.  However, if the physical network of host A is connected by a
  77.     gateway to the physical network of host B, the gateway will see the
  78.     ARP request from host A.  Assuming that subnet numbers are made to
  79.     correspond to physical networks, the gateway can also tell that the
  80.     request is for a host that is on a different physical network from
  81.     the requesting host.  The gateway can then respond for host B,
  82.     saying that the network address for host B is that of the gateway
  83.     itself.  Host A will see this reply, cache it, and send future IP
  84.     packets for host B to the gateway.  The gateway will forward such
  85.     packets to host B by the usual IP routing mechanisms.  The gateway
  86.     is acting as an agent for host B, which is why this technique is
  87.     called "Proxy ARP"; we will refer to this as a transparent subnet
  88.     gateway or ARP subnet gateway.
  89.  
  90.     When host B replies to traffic from host A, the same algorithm
  91.     happens in reverse: the gateway connected to the network of host B
  92.     answers the request for the network address of host A, and host B
  93.     then sends IP packets for host A to gateway.  The physical networks
  94.     of host A and B need not be connected to the same gateway. All that
  95.     is necessary is that the networks be reachable from the gateway.
  96.  
  97.     With this approach, all ARP subnet handling is done in the ARP
  98.     subnet gateways.  No changes to the normal ARP protocol or routing
  99.     need to be made to the source and target hosts.  From the host point
  100.     of view, there are no subnets, and their physical networks are
  101.     simply one big IP network.  If a host has an implementation of
  102.     subnets, its network masks must be set to cover only the IP network
  103.     number, excluding the subnet bits, for the system to work properly.
  104.  
  105.  
  106.  
  107.  
  108. Carl-Mitchell & Quarterman                                      [Page 2]
  109.  
  110. RFC 1027          ARP and Transparent Subnet Gateways       October 1987
  111.  
  112.  
  113. 2.2  Routing
  114.  
  115.     As part of the implementation of subnets, it is expected that the
  116.     elements of routing tables will include network numbers including
  117.     both the IP network number and the subnet bits, as specified by the
  118.     subnet mask, where appropriate.  When an ARP request is seen, the
  119.     ARP subnet gateway can determine whether it knows a route to the
  120.     target host by looking in the ordinary routing table.  If attempts
  121.     to reach foreign IP networks are eliminated early (see Sanity Checks
  122.     below), only a request for an address on the local IP network will
  123.     reach this point.  We will assume that the same network mask applies
  124.     to every subnet of the same IP network.  The network mask of the
  125.     network interface on which the ARP request arrived can then be
  126.     applied to the target IP address to produce the network part to be
  127.     looked up in the routing table.
  128.  
  129.     In 4.3BSD (and probably in other operating systems), a default route
  130.     is possible.  This default route specifies an address to forward a
  131.     packet to when no other route is found.  The default route must not
  132.     be used when checking for a route to the target host of an ARP
  133.     request.  If the default route were used, the check would always
  134.     succeed.  But the host specified by the default route is unlikely to
  135.     know about subnet routing (since it is usually an Internet gateway),
  136.     and thus packets sent to it will probably be lost.  This special
  137.     case in the routing lookup method is the only implementation change
  138.     needed to the routing mechanism.
  139.  
  140.     If the network interfaces on which the request was received and
  141.     through which the route to the target passes are the same, the
  142.     gateway must not reply.  In this case, either the target host is on
  143.     the same physical network as the gateway (and thus the host should
  144.     reply for itself), or this gateway is not on the most direct path to
  145.     the desired network, i.e., there is another gateway on the same
  146.     physical network that is on a more direct path and the other gateway
  147.     should respond.
  148.  
  149.     RFC-925 [4] describes a general mechanism for dynamic subnet routing
  150.     using Proxy ARP and routing caches in the gateways.  Our technique
  151.     is restricted subset of RFC-925, in which we use static subnet
  152.     routes which are determined administratively.  As a result, our
  153.     transparent subnet gateways require no new network routing table
  154.     entries nor ARP cache entries; the only tables which are affected
  155.     are the ARP caches in the host.
  156.  
  157.     In our implementation, routing loops are prevented by proper
  158.     administration of the subnet routing tables in the gateways.
  159.  
  160.  
  161.  
  162.  
  163.  
  164. Carl-Mitchell & Quarterman                                      [Page 3]
  165.  
  166. RFC 1027          ARP and Transparent Subnet Gateways       October 1987
  167.  
  168.  
  169. 2.3  Multiple gateways
  170.  
  171.     The simplest subnet organization to administer is a tree structure,
  172.     which cannot have loops.  However, it may be desirable for
  173.     reliability or traffic accommodation to have more than one gateway
  174.     (or path) between two physical networks.  ARP subnet gateways may be
  175.     used in such a situation:  a requesting host will use the first ARP
  176.     response it receives, even if more than one gateway supplies one.
  177.     This may even provide a rudimentary load balancing service, since if
  178.     two gateways are otherwise similar, the one most lightly loaded is
  179.     the more likely to reply first.
  180.  
  181.     More complex mechanisms could be built in the form of gateway-to-
  182.     gateway protocols, and will no doubt become necessary in networks
  183.     with large numbers of subnets and gateways, in the same way that
  184.     gateway-to-gateway protocols are generally necessary among IP
  185.     gateways.
  186.  
  187. 2.4  Sanity checks
  188.  
  189.     Care must be taken by the network and gateway administrators to keep
  190.     the network masks the same on all the subnet gateway machines.  The
  191.     most common error is to set the network mask on a host without a
  192.     subnet implementation to include the subnet number.  This causes the
  193.     host to fail to attempt to send packets to hosts not on its local
  194.     subnet.  Adjusting its routing tables will not help, since it will
  195.     not know how to route to subnets.
  196.  
  197.     If the IP networks of the source and target hosts of an ARP request
  198.     are different, an ARP subnet gateway implementation should not
  199.     reply.  This is to prevent the ARP subnet gateway from being used to
  200.     reach foreign IP networks and thus possibly bypass security checks
  201.     provided by IP gateways.
  202.  
  203.     An ARP subnet gateway implementation must not reply if the physical
  204.     networks of the source and target of an ARP request are the same.
  205.     In this case, either the target host is presumably either on the
  206.     same physical network as the source host and can answer for itself,
  207.     or the target host lies in the same direction from the gateway as
  208.     does the source host, and an ARP reply from the would cause a loop.
  209.  
  210.     An ARP request for a broadcast address must elicit no reply,
  211.     regardless of the source address or physical networks involved.  If
  212.     the gateway were to respond with an ARP reply in this situation, it
  213.     would be inviting the original source to send actual traffic to a
  214.     broadcast address.  This could result in the "Chernobyl effect"
  215.     wherein every host on the network replies to such traffic, causing
  216.     network "meltdown".
  217.  
  218.  
  219.  
  220. Carl-Mitchell & Quarterman                                      [Page 4]
  221.  
  222. RFC 1027          ARP and Transparent Subnet Gateways       October 1987
  223.  
  224.  
  225. 2.5  Multiple logical subnets per physical network
  226.  
  227.     The most straightforward way to assign subnet numbers is one to one
  228.     with physical networks.  There are, however, circumstances in which
  229.     multiple logical subnets per physical network are quite useful.  One
  230.     of the more common is when it is planned that a group of
  231.     workstations will be put on their own physical network but the
  232.     gateway to the new physical network needs to be tested first.  (A
  233.     repeater might be used when the gateway was not usable).  If a rule
  234.     of one subnet per physical network is enforced, the addresses of the
  235.     workstations must be changed every time the gateway is tested.  If
  236.     they may be assigned addresses using a new subnet number while they
  237.     are still on the old physical network, no further address changes
  238.     are needed.
  239.  
  240.     To permit multiple subnets per physical network, an ARP subnet
  241.     gateway must use the physical network interface, not the subnet
  242.     number to determine when to reply to an ARP request.  That is, it
  243.     should send a proxy ARP reply only when the source network interface
  244.     differs from the target network interface. In addition, appropriate
  245.     routing table entries for these "phantom" subnets must be added to
  246.     the subnet gateway routing tables.
  247.  
  248. 2.6  Broadcast addresses
  249.  
  250.     There are two kinds of IP broadcast addresses:  main IP directed
  251.     network broadcast and subnet broadcast.  An IP network broadcast
  252.     address consists of the network number plus a well-known value in
  253.     the rest (local part) of the address.  An IP subnet broadcast is
  254.     similar, except both the IP network number and the subnet number
  255.     bits are included.  RFC-922 standardized the use of all ones in the
  256.     local part, but there were two conventions in use before that:  all
  257.     ones and all zeros.  For example, 4.2BSD used all zeros, and 4.3BSD
  258.     uses all ones.  Thus there are four kinds of IP directed broadcast
  259.     addresses still currently in use on many networks.
  260.  
  261.     With transparent subnetting a subnet gateway must not issue an IP
  262.     broadcast using the subnet broadcast address, e.g., 128.83.138.255.
  263.     Hosts on the physical network that receive the broadcast will not
  264.     understand such an address as a broadcast address, since they will
  265.     not have subnets enabled (or will not have subnet implementations).
  266.     In fact, 4.2BSD hosts (with or without subnet implementations) will
  267.     instead treat an address with all ones in the local part as a
  268.     specific host address and try to forward the packet.  Since there is
  269.     no such target host, there will be no entry in the forwarding host's
  270.     ARP tables and it will generate an ARP request for the target host.
  271.     This presents the scenario (actually observed) of a 4.3BSD gateway
  272.     running the rwho program, which broadcasts a packet once a minute,
  273.  
  274.  
  275.  
  276. Carl-Mitchell & Quarterman                                      [Page 5]
  277.  
  278. RFC 1027          ARP and Transparent Subnet Gateways       October 1987
  279.  
  280.  
  281.     causing every 4.2BSD host on the local physical network to generate
  282.     an ARP request at the same time.  The same problem occurs with any
  283.     subnet broadcast address, whether the local part is all zeros or all
  284.     ones.
  285.  
  286.     Thus a subnet gateway in a network with hosts that do not understand
  287.     subnets must take care not to use subnet broadcast addresses:
  288.     instead it must use the IP network directed broadcast address
  289.     instead.
  290.  
  291.     Finally, since many hosts running out-of-date software will still be
  292.     using (and expecting) old-style all-zeros IP network broadcast
  293.     addresses, the gateway must send its broadcast addresses out in that
  294.     form, e.g., 128.83.0.0.  It might be safe to also send a duplicate
  295.     packet with all ones in the local part, e.g., 128.83.255.255.  It is
  296.     not clear whether the local network broadcast address of all ones,
  297.     255.255.255.255, will cause ill effects, but it is very likely that
  298.     it will not be recognized by many hosts that are running older
  299.     software.
  300.  
  301. 3.  Implementation in 4.3BSD
  302.  
  303.     Subnet gateways using ARP have been implemented by a number of
  304.     different people.  The particular method described in this memo was
  305.     first implemented in 4.2BSD on top of retrofitted beta-test 4.3BSD
  306.     subnet code, and has since been reimplemented as an add-on to the
  307.     distributed 4.3BSD sources.  The latter implementation is described
  308.     here.
  309.  
  310.     Most of the new kernel code for the subnet ARP gatewaying function
  311.     is in the generic Ethernet interface module, netinet/if_ether.c.  It
  312.     consists of eight lines in in_arpinput that perform a couple of
  313.     quick checks (to ensure that the facility is enabled on the source
  314.     interface and that the source and target addresses are on different
  315.     subnets), call a new routine, if_subarp, for further checks, and
  316.     then build the ARP response if all checks succeed.  This code is
  317.     only reached when an ARP request is received, and does nothing if
  318.     the facility is not enabled on the source interface.  Thus
  319.     performance of the gateway should be very little degraded by this
  320.     addition.  (Performance of the requesting host should also be
  321.     similar to the latter case, as the only difference there is between
  322.     efficiency of the ARP cache and of the routing tables).
  323.  
  324.     The routine if_subarp (about sixty lines) ensures that the source
  325.     and target addresses are on the same IP network and that the target
  326.     address is none of the four kinds of directed broadcast address.  It
  327.     then attempts to find a path to the target either by finding a
  328.     network interface with the desired subnet or by looking in the
  329.  
  330.  
  331.  
  332. Carl-Mitchell & Quarterman                                      [Page 6]
  333.  
  334. RFC 1027          ARP and Transparent Subnet Gateways       October 1987
  335.  
  336.  
  337.     routing tables.  Even if a network interface is found that leads to
  338.     the target, for a reply to be sent the ARP gateway must be enabled
  339.     on that interface and the target and source interfaces must be
  340.     different.
  341.  
  342.     The file netinet/route.c has a static routing entry structure
  343.     definition added, and modifications of about eight lines are made to
  344.     the main routing table lookup routine, rtalloc, to recognize a
  345.     pointer to that structure (when passed by if_subarp) as a direction
  346.     to not use the default route in this routing check.  The processor
  347.     priority level (critical section protection) around the inner
  348.     routing lookup check is changed to a higher value, as the routine
  349.     may now be called from network interface interrupts as well as from
  350.     the internal software interrupts that drive processing of IP and
  351.     other high level protocols.  This raised processor priority could
  352.     conceivably slow the whole kernel somewhat if there are many routing
  353.     checks, but since the critical section is fast, the effect should be
  354.     small.
  355.  
  356.     A key kernel modification is about fifteen lines added to the
  357.     routine ip_output in netinet/ip_output.c.  It changes subnet
  358.     broadcast addresses in packets originating at the gateway to IP
  359.     network broadcast addresses so that hosts without subnet code (or
  360.     with their network masks set to ignore subnets) will recognize them
  361.     as broadcast addresses.  This section of code is only used if the
  362.     ARP gateway is turned on for the outgoing interface, and only
  363.     affects subnet broadcast addresses.
  364.  
  365.     A new routine, in_mainnetof, of about fifteen lines, is added to
  366.     netinet/in.c to return the IP network number (without subnet number)
  367.     from an IP address.  It is called from if_subarp and ip_output.
  368.  
  369.     Two kernel parameter files have one line added to each:  net/if.h
  370.     has a definition of a bit in the network interface structure to
  371.     indicate whether subnet ARP gateways are enabled, and netinet/in.h
  372.     refers to in_mainnetof.
  373.  
  374.     In addition to these approximately 110 lines of kernel source
  375.     additions, there is one user-level modification.  The source to the
  376.     command ifconfig, which is used to set addresses and network masks
  377.     of network interfaces, has four lines added to allow it to turn the
  378.     subnet ARP gateway facility on or off, for each interface.  This is
  379.     documented in eleven new lines in the manual entry for that command.
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388. Carl-Mitchell & Quarterman                                      [Page 7]
  389.  
  390. RFC 1027          ARP and Transparent Subnet Gateways       October 1987
  391.  
  392.  
  393. 4.  Availability
  394.  
  395.     The 4.3BSD implementation is currently available by anonymous FTP
  396.     (login anonymous, password guest) from sally.utexas.edu as
  397.     pub/subarp, which is a 4.3BSD "diff -c" listing from the 4.3BSD
  398.     sources that were distributed in September 1986.
  399.  
  400.     This implementation was not included in the 4.3BSD distribution
  401.     proper because U.C. Berkeley CSRG thought that that would reduce the
  402.     incentive for vendors to implement subnets per RFC-950.  The authors
  403.     concur.  Nonetheless, there are circumstances in which the use of
  404.     transparent subnet ARP gateways is indispensable.
  405.  
  406. References
  407.  
  408.    1.  Mogul, J., and J. Postel, "Internet Standard Subnetting
  409.        Procedure", RFC-950, Stanford University and USC/Information
  410.        Sciences Institute, August 1985.
  411.  
  412.    2.  Mogul, J., "Broadcasting Internet Datagrams in the Presence of
  413.        Subnets", RFC-922, Computer Science Department, Stanford
  414.        University, October 1984.
  415.  
  416.    3.  Plummer, D., "An Ethernet Address Resolution Protocol or
  417.        Converting Network Protocol Addresses to 48-bit Ethernet
  418.        Addresses for Transmission on Ethernet Hardware", RFC-826,
  419.        Symbolics, November 1982.
  420.  
  421.    4.  Postel, J., "Multi-LAN Address Resolution", RFC-925,
  422.        USC/Information Sciences Institute, October 1984.
  423.  
  424.    5.  Carl-Mitchell, S., and J. S. Quarterman, "Nameservers in a Campus
  425.        Domain", SIGCUE Outlook, Vol.19, No.1/2, pp.78-88, ACM SIG
  426.        Computer Uses in Education, P.O. Box 64145, Baltimore, MD 21264,
  427.        Spring/Summer 1986.
  428.  
  429.    6.  Braden, R., and J. Postel, "Requirements for Internet Gateways",
  430.        RFC-1009, USC/Information Sciences Institute, June 1987.
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444. Carl-Mitchell & Quarterman                                      [Page 8]
  445.  
  446.