rfc917.txt

RFC 相关的技术文档

      If a self-encoding scheme is not used, it is clear that a
      variable-width subnet field is appropriate.  Since there must in
      any case be some per-network "flag" to indicate if subnets are in
      use, the additional cost of using an integer (the subnet field
      width) instead of a boolean is negligible.  The advantage of using
      a variable-width subnet field is that it allows each organization
      to choose the best way to allocate relatively scarce bits of local
      address to subnet and host numbers.

      Our proposal, therefore, is that the Internet address be
      interpreted as:

         <network-number><subnet-number><host-number>

      where the <network-number> field is as in [8], the <host-number>
      field is at least one bit wide, and the width of the
      <subnet-number> field is constant for a given network. No further
      structure is required for the <subnet-number> or <host-number>
      fields.  If the width of the <subnet-number> field is zero, then
      the network is not subnetted (i.e., the interpretation of [8] is
      used.)




Mogul                                                           [Page 6]



RFC 917                                                     October 1984
Internet Subnets


      For example, on a Class A network with an eight bit wide subnet
      field, an address is broken down like this:

                           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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|    NETWORK    |     SUBNET    |         Host number         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      We expect that, for reasons of simplicity and efficient
      implementation, that most organizations will choose a subnet field
      width that is a multiple of eight bits.  However, an
      implementation must be prepared to handle other possible widths.

      We reject the use of "recursive subnets", the division of the host
      field into "sub-subnet" and host parts, because:

         - There is no obvious need for a four-level hierarchy.

         - The number of bits available in an IP address is not large
           enough to make this useful in general.

         - The extra mechanism required is complex.

   2.2. Changes to Host Software to Support Subnets

      In most implementations of IP, there is  code in the module that
      handles outgoing packet that does something like:

         IF ip_net_number(packet.ip_dest) = ip_net_number(my_ip_addr)
             THEN
                 send_packet_locally(packet, packet.ip_dest)
             ELSE
                 send_packet_locally(packet,
                    gateway_to(ip_net_number(packet.ip_dest)))

      (If the code supports multiple connected networks, it will be more
      complicated, but this is irrelevant to the current discussion.)

      To support subnets, it is necessary to store one more 32-bit
      quantity, called my_ip_mask.  This is a bit-mask with bits set in
      the fields corresponding to the IP network number, and additional
      bits set corresponding to the subnet number field.  For example,
      on a Class A network using an eight-bit wide subnet field, the
      mask would be 255.255.0.0.

      The code then becomes:


Mogul                                                           [Page 7]



RFC 917                                                     October 1984
Internet Subnets


         IF bitwise_and(packet.ip_dest, my_ip_mask)
                          = bitwise_and(my_ip_addr, my_ip_mask)
             THEN
                 send_packet_locally(packet, packet.ip_dest)
             ELSE
                 send_packet_locally(packet,
                    gateway_to(bitwise_and(packet.ip_dest, my_ip_mask)))

      Of course, part of the expression in the conditionally can be
      pre-computed.

      It may or may not be necessary to modify the "gateway_to"
      function, so that it performs comparisons in the same way.

      To support multiply-connected hosts, the code can be changed to
      keep  the "my_ip_addr" and "my_ip_mask" quantities on a
      per-interface basis; the expression in the conditional must then
      be evaluated for each interface.

   2.3. Subnets and Broadcasting

      In the absence of subnets, there are only two kinds of broadcast
      possible within the Internet Protocol <2>: broadcast to all hosts
      on a specific network, or broadcast to all hosts on "this
      network"; the latter is useful when a host does not know what
      network it is on.

      When subnets are used, the situation becomes slightly more
      complicated.  First, the possibility now exists of broadcasting to
      a specific subnet.  Second, broadcasting to all the hosts on a
      subnetted network requires additional mechanism; in [6] the use of
      "Reverse Path Forwarding" [3] is proposed.  Finally, the
      interpretation of a broadcast to "this network" is that it should
      not be forwarded outside of the original subnet.

      Implementations must therefore recognize three kinds of broadcast
      addresses, in addition to their own host addresses:

      This physical network

         A destination address of all ones (255.255.255.255) causes the
         a datagram to be sent as a broadcast on the local physical
         network; it must not be forwarded by any gateway.






Mogul                                                           [Page 8]



RFC 917                                                     October 1984
Internet Subnets


      Specific network

         The destination address contains a valid network number; the
         local address part is all ones (e.g., 36.255.255.255).

      Specific subnet

         The destination address contains a valid network number and a
         valid subnet number; the host field is all ones (e.g.,
         36.40.255.255).

      For further discussion of Internet broadcasting, see [6].

      One factor that may aid in deciding whether to use subnets is that
      it is possible to broadcast to all hosts of a subnetted network
      with a single operation at the originating host.  It is not
      possible to broadcast, in one step, to the same set of hosts if
      they are on distinct networks.

   2.4. Determining the Width of the Subnet Field

      How can a host (or gateway) determine what subnet field width is
      in use on a network to which it is connected?  The problem is
      analogous to several other "bootstrapping" problems for Internet
      hosts: how a host determines its own address, and how it locates a
      gateway on its local network.  In all three cases, there are two
      basic solutions: "hardwired" information, and broadcast-based
      protocols.

      "Hardwired" information is that available to a host in isolation
      from a network.  It may be compiled-in, or (preferably) stored in
      a disk file.  However, for the increasingly common case of a
      diskless workstation that is bootloaded over a LAN, neither
      hard-wired solution is satisfactory.  Instead, since most LAN
      technology supports broadcasting, a better method is for the
      newly-booted host to broadcast a request for the necessary
      information.  For example, for the purpose of determining its
      Internet address, a host may use the "Reverse Address Resolution
      Protocol" [4].

      We propose to extend the ICMP protocol [9] by adding a new pair of
      ICMP message types, "Address Format Request" and "Address Format
      Reply", analogous to the "Information Request" and "Information
      Reply" ICMP messages.  These are described in detail in
      Appendix I.

      The intended use of these new ICMPs is that a host, when booting,


Mogul                                                           [Page 9]



RFC 917                                                     October 1984
Internet Subnets


      broadcast an "Address Format Request" message <3>.  A gateway (or
      a host acting in lieu of a gateway) that receives this message
      responds with an "Address Format Reply".  If there is no
      indication in the request which host sent it (i.e., the IP Source
      Address is zero), the reply is broadcast as well.  The requesting
      host will hear the response, and from it determine the width of
      the subnet field.

      Since there is only one possible value that can be sent in an
      "Address Format Reply" on any given LAN, there is no need for the
      requesting host to match the responses it hears against the
      request it sent; similarly, there is no problem if more than one
      gateway responds.  We assume that hosts reboot infrequently, so
      the broadcast load on a network from use of this protocol should
      be small.

      If a host is connected to more than one LAN, it must use this
      protocol on each, unless it can determine (from a response on one
      of the LANs) that several of the LANs are part of the same
      network, and thus must have the same subnet field width.

      One potential problem is what a host should do if it receives no
      response to its "Address Format Request", even after a reasonable
      number of tries.  Three interpretations can be placed on the
      situation:

         1. The local net exists in (permanent) isolation from all other
            nets.

         2. Subnets are not in use, and no host supports this ICMP
            request.

         3. All gateways on the local net are (temporarily) down.

      The first and second situations imply that the subnet field width
      is zero.  In the third situation, there is no way to determine
      what the proper value is; the safest choice is thus zero.
      Although this might later turn out to be wrong, it will not
      prevent transmissions that would otherwise succeed.  It is
      possible for a host to recover from a wrong choice: when a gateway
      comes up, it should broadcast an "Address Format Reply"; when a
      host receives such a message that disagrees with its guess, it
      should adjust its data structures to conform to the received
      value.  No host or gateway should send an "Address Format Reply"
      based on a "guessed" value.




Mogul                                                          [Page 10]



RFC 917                                                     October 1984
Internet Subnets


      Finally, note that no host is required to use this ICMP protocol
      to discover the subnet field width; it is perfectly reasonable for
      a host with non-volatile storage to use stored information.

3. Subnet Routing Methods

   One problem that faces all Internet hosts is how to determine a route
   to another host.  In the presence of subnets, this problem is only
   slightly modified.

   The use of subnets means that there are two levels to the routing
   process, instead of one.  If the destination host is on the same
   network as the source host, the routing decision involves only the
   subnet gateways between the hosts.  If the destination is on a
   different network, then the routing decision requires the choice both
   of a gateway out of the source host's network, and of a route within
   the network to that gateway.

   Fortunately, many hosts can ignore this distinction (and, in fact,
   ignore all routing choices) by using a "default" gateway as the
   initial route to all destinations, and relying on ICMP Host Redirect
   messages to define more appropriate routes.  However, this is not an
   efficient method for a gateway or for a multi-homed host, since a
   redirect may not make up for a poor initial choice of route.  Such
   hosts should use a routing information exchange protocol, but that is
   beyond the scope of this document; in any case, the problem arises
   even when subnets are not used.

   The problem for a singly-connected host is thus to find at least one
   neighbor gateway.  Again, there are basic two solutions to this: use
   hard-wired information, or use broadcasts.  We believe that the
   neighbor-gateway acquisition problem is the same with or without
   subnets, and thus the choice of solution is not affected by the use
   of subnets.

   However, one problem remains: a source host must determine if
   datagram to a given destination address must be sent via a gateway,
   or sent directly to the destination host.  In other words, is the
   destination host on the same physical network as the source?  This
   particular phase of the routing process is the only one that requires
   an implementation to be explicitly aware of subnets; in fact, if
   broadcasts are not used, it is the only place where an Internet
   implementation must be modified to support subnets.

   Because of this, it is possible to use some existing implementations
   without modification in the presence of subnets <4>.  For this to
   work, such implementations must:


Mogul                                                          [Page 11]