rfc1027.txt

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

2.5  Multiple logical subnets per physical network

    The most straightforward way to assign subnet numbers is one to one
    with physical networks.  There are, however, circumstances in which
    multiple logical subnets per physical network are quite useful.  One
    of the more common is when it is planned that a group of
    workstations will be put on their own physical network but the
    gateway to the new physical network needs to be tested first.  (A
    repeater might be used when the gateway was not usable).  If a rule
    of one subnet per physical network is enforced, the addresses of the
    workstations must be changed every time the gateway is tested.  If
    they may be assigned addresses using a new subnet number while they
    are still on the old physical network, no further address changes
    are needed.

    To permit multiple subnets per physical network, an ARP subnet
    gateway must use the physical network interface, not the subnet
    number to determine when to reply to an ARP request.  That is, it
    should send a proxy ARP reply only when the source network interface
    differs from the target network interface. In addition, appropriate
    routing table entries for these "phantom" subnets must be added to
    the subnet gateway routing tables.

2.6  Broadcast addresses

    There are two kinds of IP broadcast addresses:  main IP directed
    network broadcast and subnet broadcast.  An IP network broadcast
    address consists of the network number plus a well-known value in
    the rest (local part) of the address.  An IP subnet broadcast is
    similar, except both the IP network number and the subnet number
    bits are included.  RFC-922 standardized the use of all ones in the
    local part, but there were two conventions in use before that:  all
    ones and all zeros.  For example, 4.2BSD used all zeros, and 4.3BSD
    uses all ones.  Thus there are four kinds of IP directed broadcast
    addresses still currently in use on many networks.

    With transparent subnetting a subnet gateway must not issue an IP
    broadcast using the subnet broadcast address, e.g., 128.83.138.255.
    Hosts on the physical network that receive the broadcast will not
    understand such an address as a broadcast address, since they will
    not have subnets enabled (or will not have subnet implementations).
    In fact, 4.2BSD hosts (with or without subnet implementations) will
    instead treat an address with all ones in the local part as a
    specific host address and try to forward the packet.  Since there is
    no such target host, there will be no entry in the forwarding host's
    ARP tables and it will generate an ARP request for the target host.
    This presents the scenario (actually observed) of a 4.3BSD gateway
    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 generate
    an ARP request at the same time.  The same problem occurs with any
    subnet broadcast address, whether the local part is all zeros or all
    ones.

    Thus a subnet gateway in a network with hosts that do not understand
    subnets must take care not to use subnet broadcast addresses:
    instead it must use the IP network directed broadcast address
    instead.

    Finally, since many hosts running out-of-date software will still be
    using (and expecting) old-style all-zeros IP network broadcast
    addresses, the gateway must send its broadcast addresses out in that
    form, e.g., 128.83.0.0.  It might be safe to also send a duplicate
    packet with all ones in the local part, e.g., 128.83.255.255.  It is
    not clear whether the local network broadcast address of all ones,
    255.255.255.255, will cause ill effects, but it is very likely that
    it will not be recognized by many hosts that are running older
    software.

3.  Implementation in 4.3BSD

    Subnet gateways using ARP have been implemented by a number of
    different people.  The particular method described in this memo was
    first implemented in 4.2BSD on top of retrofitted beta-test 4.3BSD
    subnet code, and has since been reimplemented as an add-on to the
    distributed 4.3BSD sources.  The latter implementation is described
    here.

    Most of the new kernel code for the subnet ARP gatewaying function
    is in the generic Ethernet interface module, netinet/if_ether.c.  It
    consists of eight lines in in_arpinput that perform a couple of
    quick checks (to ensure that the facility is enabled on the source
    interface and that the source and target addresses are on different
    subnets), call a new routine, if_subarp, for further checks, and
    then build the ARP response if all checks succeed.  This code is
    only reached when an ARP request is received, and does nothing if
    the facility is not enabled on the source interface.  Thus
    performance of the gateway should be very little degraded by this
    addition.  (Performance of the requesting host should also be
    similar to the latter case, as the only difference there is between
    efficiency of the ARP cache and of the routing tables).

    The routine if_subarp (about sixty lines) ensures that the source
    and target addresses are on the same IP network and that the target
    address is none of the four kinds of directed broadcast address.  It
    then attempts to find a path to the target either by finding a
    network interface with the desired subnet or by looking in the



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 to
    the target, for a reply to be sent the ARP gateway must be enabled
    on that interface and the target and source interfaces must be
    different.

    The file netinet/route.c has a static routing entry structure
    definition added, and modifications of about eight lines are made to
    the main routing table lookup routine, rtalloc, to recognize a
    pointer to that structure (when passed by if_subarp) as a direction
    to not use the default route in this routing check.  The processor
    priority level (critical section protection) around the inner
    routing lookup check is changed to a higher value, as the routine
    may now be called from network interface interrupts as well as from
    the internal software interrupts that drive processing of IP and
    other high level protocols.  This raised processor priority could
    conceivably slow the whole kernel somewhat if there are many routing
    checks, but since the critical section is fast, the effect should be
    small.

    A key kernel modification is about fifteen lines added to the
    routine ip_output in netinet/ip_output.c.  It changes subnet
    broadcast addresses in packets originating at the gateway to IP
    network broadcast addresses so that hosts without subnet code (or
    with their network masks set to ignore subnets) will recognize them
    as broadcast addresses.  This section of code is only used if the
    ARP gateway is turned on for the outgoing interface, and only
    affects subnet broadcast addresses.

    A new routine, in_mainnetof, of about fifteen lines, is added to
    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.h
    has a definition of a bit in the network interface structure to
    indicate whether subnet ARP gateways are enabled, and netinet/in.h
    refers to in_mainnetof.

    In addition to these approximately 110 lines of kernel source
    additions, there is one user-level modification.  The source to the
    command ifconfig, which is used to set addresses and network masks
    of network interfaces, has four lines added to allow it to turn the
    subnet ARP gateway facility on or off, for each interface.  This is
    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.  Availability

    The 4.3BSD implementation is currently available by anonymous FTP
    (login anonymous, password guest) from sally.utexas.edu as
    pub/subarp, which is a 4.3BSD "diff -c" listing from the 4.3BSD
    sources that were distributed in September 1986.

    This implementation was not included in the 4.3BSD distribution
    proper because U.C. Berkeley CSRG thought that that would reduce the
    incentive for vendors to implement subnets per RFC-950.  The authors
    concur.  Nonetheless, there are circumstances in which the use of
    transparent subnet ARP gateways is indispensable.

References

   1.  Mogul, J., and J. Postel, "Internet Standard Subnetting
       Procedure", RFC-950, Stanford University and USC/Information
       Sciences Institute, August 1985.

   2.  Mogul, J., "Broadcasting Internet Datagrams in the Presence of
       Subnets", RFC-922, Computer Science Department, Stanford
       University, October 1984.

   3.  Plummer, D., "An Ethernet Address Resolution Protocol or
       Converting Network Protocol Addresses to 48-bit Ethernet
       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 Campus
       Domain", SIGCUE Outlook, Vol.19, No.1/2, pp.78-88, ACM SIG
       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]