rfc917.txt

RFC 相关的技术文档

RFC 917                                                     October 1984
Internet Subnets


      - Be used only on singly-homed hosts, and not as a gateway.

      - Be used on a broadcast LAN.

      - Use an Address Resolution Protocol (ARP), such [7].

      - Not be required to maintain connections in the case of gateway
        crashes.

   In this case, one can modify the ARP server module in a subnet
   gateway so that when it receives an ARP request, it checks the target
   Internet address to see if it is along the best route to the target.
   If it is, it sends to the requesting host an ARP response indicating
   its own hardware address.  The requesting host thus believes that it
   knows the hardware address of the destination host, and sends packets
   to that address.  In fact, the packets are received by the gateway,
   and forwarded to the destination host by the usual means.

   This method requires some blurring of the layers in the gateways,
   since the ARP server and the Internet routing table would normally
   not have any contact.  In this respect, it is somewhat
   unsatisfactory.  Still, it is fairly easy to implement, and does not
   have significant performance costs.  One problem is that if the
   original gateway crashes, there is no way for the source host to
   choose an alternate route even if one exists; thus, a connection that
   might otherwise have been maintained will be broken.

   One should not confuse this method of "ARP-based subnetting" with the
   superficially similar use of ARP-based bridges.  ARP-based subnetting
   is based on the ability of a gateway to examine an IP address and
   deduce a route to the destination, based on explicit subnet topology.
   In other words, a small part of the routing decision has been moved
   from the source host into the gateway.  An ARP-based bridge, in
   contrast, must somehow locate each host without any assistance from a
   mapping between host address and topology.  Systems built out of
   ARP-based bridges should not be referred to as "subnetted".

   N.B.: the use of ARP-based subnetting is complicated by the use of
   broadcasts.  An ARP server [7] should never respond to a request
   whose target is a broadcast address.  Such a request can only come
   from a host that does not recognize the broadcast address as such,
   and so honoring it would almost certainly lead to a forwarding loop.
   If there are N such hosts on the physical network that do not
   recognize this address as a broadcast, then a packet sent with a
   Time-To-Live of T could potentially give rise to T**N spurious
   re-broadcasts.



Mogul                                                          [Page 12]



RFC 917                                                     October 1984
Internet Subnets


4. Case Studies

   In this section, we briefly sketch how subnets have been used by
   several organizations.

   4.1. Stanford University

      At Stanford, subnets were introduced initially for historical
      reasons.  Stanford had been using the Pup protocols [1] on a
      collection of several Experimental Ethernets [5] since 1979,
      several years before Internet protocols came into use.  There were
      a number of Pup gateways in service, and all hosts and gateways
      acquired and exchanged routing table information using a simple
      broadcast protocol.

      When the Internet Protocol was introduced, the decision was made
      to use an eight-bit wide subnet number; Internet subnet numbers
      were chosen to match the Pup network number of a given Ethernet,
      and the Pup host numbers (also eight bits) were used as the host
      field of the Internet address.

      The Pup-only gateways were then modified to forward Internet
      datagrams according to their Pup routing tables; they otherwise
      had no understanding of Internet packets and in fact did not
      adjust the Time-to-live field in the Internet header.  This seems
      to be acceptable, since bugs that caused forwarding loops have not
      appeared.  The Internet hosts that are multi-homed and thus can
      serve as gateways do adjust the Time-to-live field; since all of
      the currently also serve as Pup gateways, no additional routing
      information exchange protocol was needed.

      Internet host implementations were modified to understand subnets
      (in several different ways, but with identical effects).  Since
      all already had Pup implementations, the Internet routing tables
      were maintained by the same process that maintained the Pup
      routing tables, simply translating the Pup network numbers into
      Internet subnet numbers.

      When 10Mbit Ethernets were added, the gateways were modified to
      use the ARP-based scheme described in an earlier section; this
      allowed unmodified hosts to be used on the 10Mbit Ethernets.

      IP subnets have been in use since early 1982; currently, there are
      about 330 hosts, 18 subnets, and a similar number of subnet
      gateways in service.  Once the Pup-only gateways are converted to
      be true Internet gateways, an Internet-based routing exchange
      protocol will be introduced, and Pup will be phased out.


Mogul                                                          [Page 13]



RFC 917                                                     October 1984
Internet Subnets


   4.2. MIT

      MIT was the first IP site to accumulate a large collection of
      local network links.  Since this happened before network numbers
      were divided into classes, to have assigned each link at MIT its
      own IP network number would have used up a good portion of the
      available address space.  MIT decided to use one IP network
      number, and to manage the 24-bit "rest" field itself, by dividing
      it into three 8-bit fields; "subnet", "reserved, must be zero",
      and "host".   Since the CHAOS protocol already in use at MIT used
      an 8-bit subnet number field, it was possible to assign each link
      the same subnet number in both protocols.  The IP host field was
      set to 8 bits since most available local net hardware at that
      point used 8 bit addresses, as did the CHAOS protocol; it was felt
      that reserving some bits for the future was wise.

      The initial plan was to use a dynamic routing protocol between the
      IP subnet gateways; several such protocols have been mooted but
      nobody has bothered to implement one; static routing tables are
      still used.  It is likely that this change will finally be made
      soon.

      To solve the problem that imported IP software always needed
      modification to work in the subnetted environment, MIT searched
      for a model of operation that led to the least change in host IP
      software.  This led to a model where IP gateways send ICMP Host
      Redirects rather than Network Redirects.  All internal MIT IP
      gateways now do so.  With hosts that can maintain IP routing
      tables for non-local communication on a per host basis, this hides
      most of the subnet structure.  The "minimum adjustment" for host
      software to work correctly in both subnetted and non-subnetted
      environments is the bit-mask algorithm mentioned earlier.

      MIT has no immediate plans to move toward a single "approved"
      protocol; this is due partly to the degree of local autonomy and
      the amount of installed software, and partly to the lack of a
      single prominent industry standard.  Rather, the approach taken
      has been to provide a single set of physical links and packet
      switches, and to layer several "virtual" protocol nets atop the
      single set of links.  MIT has had some bad experiences with trying
      to exchange routing information between protocols and wrap one
      protocol in another; the general approach is to keep the protocols
      strictly separated except for sharing the basic hardware.  Using
      ARP to hide the subnet structure is not much in favor; it is felt
      that this overloads the address resolution operation.  In a
      complicated system (i.e. one with loops, and variant link speeds),



Mogul                                                          [Page 14]



RFC 917                                                     October 1984
Internet Subnets


      a more sophisticated information interchange will be needed
      between gateways; making this an explicit mechanism (but one
      insulated from the hosts) was felt to be best.

   4.3. Carnegie-Mellon University

      CMU uses a Class B network currently divided into 11 physical
      subnets (two 3Mbit Experimental Ethernets, seven 10Mbit Ethernets,
      and two ProNet rings.) Although host numbers are assigned so that
      all addresses with a given third octet will be on the same subnet
      (but not necessarily vice versa), this is essentially an
      administrative convenience.  No software currently knows the
      specifics of this allocation mechanism or depends on it to route
      between cables.

      Instead, an ARP-based bridge scheme is used.  When a host
      broadcasts an ARP request, all bridges which receive it cache the
      original protocol address mapping and then forward the request
      (after the appropriate adjustments) as an ARP broadcast request
      onto each of their other connected cables.  When a bridge receives
      a non-broadcast ARP reply with a target protocol address not its
      own, it consults its ARP cache to determine the cable onto which
      the reply should be forwarded.  The bridges thus attempt to
      transparently extend the ARP protocol into a heterogenous
      multi-cable environment.  They are therefore required to turn ARP
      broadcasts on a single cable into ARP broadcasts on all other
      connected cables even when they "know better".  This algorithm
      works only in the absence of cycles in the network connectivity
      graph (which is currently the case).  Work is underway to replace
      this simple-minded algorithm with a protocol implemented among the
      bridges, in support of redundant paths and to reduce the
      collective broadcast load.  The intent is to retain the ARP base
      and host transparency, if possible.

      Implementations supporting the 3Mbit Ethernet and 10Mb proNET ring
      at CMU use RFC-826 ARP (instead of some wired-in mapping such as
      simply using the 8-bit hardware address as the the fourth octet of
      the IP address).

      Since there are currently no redundant paths between cables, the
      issue of maintaining connections across bridge crashes is moot.
      With about 150 IP-capable hosts on the net, the bridge caches are
      still of reasonable size, and little bandwidth is devoted to ARP
      broadcast forwarding.

      CMU's network is likely to grow from its relatively small,
      singly-connected configuration centered within their CS/RI


Mogul                                                          [Page 15]



RFC 917                                                     October 1984
Internet Subnets


      facility to a campus-wide intra-departmental configuration with
      5000-10000 hosts and redundant connections between cables.  It is
      possible that the ARP-based bridge scheme will not scale to this
      size, and a system of explicit subnets may be required.  The
      medium-term goal, however, is an environment into which unmodified
      extant (especially 10Mb ethernet based) IP implementations can be
      imported; the intent is to stay with a host-transparent (thus
      ARP-based) routing mechanism as long as possible.  CMU is
      concerned that even if subnets become part of the IP standard they
      will not be widely implemented; this is the major obstacle to
      their use at CMU.






































Mogul                                                          [Page 16]



RFC 917                                                     October 1984
Internet Subnets


I. Address Format ICMP

   Address Format Request or Address Format Reply

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |      Code     |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Identifier          |       Sequence Number         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      IP Fields:

         Addresses

            The address of the source in an address format request
            message will be the destination of the address format reply
            message.  To form an address format reply message, the
            source address of the request becomes the destination
            address of the reply, the source address of the reply is set
            to the replier's address, the type code changed to A2, the
            subnet field width inserted into the Code field, and the
            checksum recomputed.  However, if the source address in the