rfc1027.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 446 行 · 第 1/2 页

Network Working Group                                Smoot Carl-Mitchell
Request for Comments: 1027                     Texas Internet Consulting
                                                      John S. Quarterman
                                               Texas Internet Consulting
                                                            October 1987


           Using ARP to Implement Transparent Subnet Gateways


Status of this Memo

    This RFC describes the use of the Ethernet Address Resolution
    Protocol (ARP) by subnet gateways to permit hosts on the connected
    subnets to communicate without being aware of the existence of
    subnets, using the technique of "Proxy ARP" [6].  It is based on
    RFC-950 [1], RFC-922 [2], and RFC-826 [3] and is a restricted subset
    of the mechanism of RFC-925 [4].  Distribution of this memo is
    unlimited.

Acknowledgment

    The work described in this memo was performed while the authors were
    employed by the Computer Sciences Department of the University of
    Texas at Austin.

Introduction

    The purpose of this memo is to describe in detail the implementation
    of transparent subnet ARP gateways using the technique of Proxy ARP.
    The intent is to document this widely used technique.

1.  Motivation

    The Ethernet at the University of Texas at Austin is a large
    installation connecting over ten buildings.  It currently has more
    than one hundred hosts connected to it [5].  The size of the
    Ethernet and the amount of traffic it handles prohibit tying it
    together by use of repeaters.  The use of subnets provided an
    attractive alternative for separating the network into smaller
    distinct units.

    This is exactly the situation for which Internet subnets as
    described in RFC-950 are intended.  Unfortunately, many vendors had
    not yet implemented subnets, and it was not practical to modify the
    more than half a dozen different operating systems running on hosts
    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 hosts
    was highly desirable.  Since all the local area networks supported
    ARP, an ARP-based method (commonly known as "Proxy ARP" or the "ARP
    hack") was chosen.  In this memo, whenever the term "subnet" occurs
    the "RFC-950 subnet method" is assumed.

2.  Design

2.1  Basic method

    On a network that supports ARP, when host A (the source) broadcasts
    an ARP request for the network address corresponding to the IP
    address of host B (the target), host B will recognize the IP address
    as its own and will send a point-to-point ARP reply.  Host A keeps
    the IP-to-network-address mapping found in the reply in a local
    cache and uses it for later communication with host B.

    If hosts A and B are on different physical networks, host B will not
    receive the ARP broadcast request from host A and cannot respond to
    it.  However, if the physical network of host A is connected by a
    gateway to the physical network of host B, the gateway will see the
    ARP request from host A.  Assuming that subnet numbers are made to
    correspond to physical networks, the gateway can also tell that the
    request is for a host that is on a different physical network from
    the requesting host.  The gateway can then respond for host B,
    saying that the network address for host B is that of the gateway
    itself.  Host A will see this reply, cache it, and send future IP
    packets for host B to the gateway.  The gateway will forward such
    packets to host B by the usual IP routing mechanisms.  The gateway
    is acting as an agent for host B, which is why this technique is
    called "Proxy ARP"; we will refer to this as a transparent subnet
    gateway or ARP subnet gateway.

    When host B replies to traffic from host A, the same algorithm
    happens in reverse: the gateway connected to the network of host B
    answers the request for the network address of host A, and host B
    then sends IP packets for host A to gateway.  The physical networks
    of host A and B need not be connected to the same gateway. All that
    is necessary is that the networks be reachable from the gateway.

    With this approach, all ARP subnet handling is done in the ARP
    subnet gateways.  No changes to the normal ARP protocol or routing
    need to be made to the source and target hosts.  From the host point
    of view, there are no subnets, and their physical networks are
    simply one big IP network.  If a host has an implementation of
    subnets, its network masks must be set to cover only the IP network
    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  Routing

    As part of the implementation of subnets, it is expected that the
    elements of routing tables will include network numbers including
    both the IP network number and the subnet bits, as specified by the
    subnet mask, where appropriate.  When an ARP request is seen, the
    ARP subnet gateway can determine whether it knows a route to the
    target host by looking in the ordinary routing table.  If attempts
    to reach foreign IP networks are eliminated early (see Sanity Checks
    below), only a request for an address on the local IP network will
    reach this point.  We will assume that the same network mask applies
    to every subnet of the same IP network.  The network mask of the
    network interface on which the ARP request arrived can then be
    applied to the target IP address to produce the network part to be
    looked up in the routing table.

    In 4.3BSD (and probably in other operating systems), a default route
    is possible.  This default route specifies an address to forward a
    packet to when no other route is found.  The default route must not
    be used when checking for a route to the target host of an ARP
    request.  If the default route were used, the check would always
    succeed.  But the host specified by the default route is unlikely to
    know about subnet routing (since it is usually an Internet gateway),
    and thus packets sent to it will probably be lost.  This special
    case in the routing lookup method is the only implementation change
    needed to the routing mechanism.

    If the network interfaces on which the request was received and
    through which the route to the target passes are the same, the
    gateway must not reply.  In this case, either the target host is on
    the same physical network as the gateway (and thus the host should
    reply for itself), or this gateway is not on the most direct path to
    the desired network, i.e., there is another gateway on the same
    physical network that is on a more direct path and the other gateway
    should respond.

    RFC-925 [4] describes a general mechanism for dynamic subnet routing
    using Proxy ARP and routing caches in the gateways.  Our technique
    is restricted subset of RFC-925, in which we use static subnet
    routes which are determined administratively.  As a result, our
    transparent subnet gateways require no new network routing table
    entries nor ARP cache entries; the only tables which are affected
    are the ARP caches in the host.

    In our implementation, routing loops are prevented by proper
    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 gateways

    The simplest subnet organization to administer is a tree structure,
    which cannot have loops.  However, it may be desirable for
    reliability or traffic accommodation to have more than one gateway
    (or path) between two physical networks.  ARP subnet gateways may be
    used in such a situation:  a requesting host will use the first ARP
    response it receives, even if more than one gateway supplies one.
    This may even provide a rudimentary load balancing service, since if
    two gateways are otherwise similar, the one most lightly loaded is
    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 networks
    with large numbers of subnets and gateways, in the same way that
    gateway-to-gateway protocols are generally necessary among IP
    gateways.

2.4  Sanity checks

    Care must be taken by the network and gateway administrators to keep
    the network masks the same on all the subnet gateway machines.  The
    most common error is to set the network mask on a host without a
    subnet implementation to include the subnet number.  This causes the
    host to fail to attempt to send packets to hosts not on its local
    subnet.  Adjusting its routing tables will not help, since it will
    not know how to route to subnets.

    If the IP networks of the source and target hosts of an ARP request
    are different, an ARP subnet gateway implementation should not
    reply.  This is to prevent the ARP subnet gateway from being used to
    reach foreign IP networks and thus possibly bypass security checks
    provided by IP gateways.

    An ARP subnet gateway implementation must not reply if the physical
    networks of the source and target of an ARP request are the same.
    In this case, either the target host is presumably either on the
    same physical network as the source host and can answer for itself,
    or the target host lies in the same direction from the gateway as
    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.  If
    the gateway were to respond with an ARP reply in this situation, it
    would be inviting the original source to send actual traffic to a
    broadcast address.  This could result in the "Chernobyl effect"
    wherein every host on the network replies to such traffic, causing
    network "meltdown".



Carl-Mitchell & Quarterman                                      [Page 4]

RFC 1027          ARP and Transparent Subnet Gateways       October 1987