rfc950.txt

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

RFC 950                                                      August 1985
Internet Standard Subnetting Procedure


         Please note that there is no effect or new restriction on the
         addresses of hosts on non-subnetted networks.

   2.2. Changes to Host Software to Support Subnets

      In most implementations of IP, there is code in the module that
      handles outgoing datagrams to decide if a datagram can be sent
      directly to the destination on the local network or if it must be
      sent to a gateway.

      Generally the code is something like this:

         IF ip_net_number(dg.ip_dest) = ip_net_number(my_ip_addr)
             THEN
                 send_dg_locally(dg, dg.ip_dest)
             ELSE
                 send_dg_locally(dg,
                                  gateway_to(ip_net_number(dg.ip_dest)))

      (If the code supports multiply-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.

      The code then becomes:

         IF bitwise_and(dg.ip_dest, my_ip_mask)
                                   = bitwise_and(my_ip_addr, my_ip_mask)
             THEN
                 send_dg_locally(dg, dg.ip_dest)
             ELSE
                 send_dg_locally(dg,
                        gateway_to(bitwise_and(dg.ip_dest, my_ip_mask)))

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

      It may or may not be necessary to modify the "gateway_to"
      function, so that it too takes the subnet field bits into account
      when performing comparisons.

      To support multiply-connected hosts, the code can be changed to




Mogul & Postel                                                  [Page 7]



RFC 950                                                      August 1985
Internet Standard Subnetting Procedure


      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. Finding the Address Mask

      How can a host determine what address mask is in use on a subnet
      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
      hardwired 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" (RARP) [4].

      However, since a newly-booted host usually needs to gather several
      facts (e.g., its IP address, the hardware address of a gateway,
      the IP address of a domain name server, the subnet address mask),
      it would be better to acquire all this information in one request
      if possible, rather than doing numerous broadcasts on the network.
      The mechanisms designed to boot diskless workstations can also
      load per-host specific configuration files that contain the
      required information (e.g., see RFC-951 [8]).  It is possible, and
      desirable, to obtain all the facts necessary to operate a host
      from a boot server using only one broadcast message.

      In the case where it is necessary for a host to find the address
      mask as a separate operation the following mechanism is provided:

         To provide the address mask information the ICMP protocol [5]
         is extended by adding a new pair of ICMP message types,
         "Address Mask Request" and "Address Mask 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 ICMP messages is that a host,
         when booting, broadcast an "Address Mask Request" message.  A


Mogul & Postel                                                  [Page 8]



RFC 950                                                      August 1985
Internet Standard Subnetting Procedure


         gateway (or a host acting in lieu of a gateway) that receives
         this message responds with an "Address Mask 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 address mask.

         Since there is only one possible value that can be sent in an
         "Address Mask 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 might have to find
      the address mask for each.

      One potential problem is what a host should do if it can not find
      out the address mask, 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 can supply the address
            mask.

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

      The first and second situations imply that the address mask is
      identical with the Internet network number mask.  In the third
      situation, there is no way to determine what the proper value is;
      the safest choice is thus a mask identical with the Internet
      network number mask.  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
      Mask Reply"; when a host receives such a message that disagrees
      with its guess, it should change its mask to conform to the
      received value.  No host or gateway should send an "Address Mask
      Reply" based on a "guessed" value.

      Finally, note that no host is required to use this ICMP protocol
      to discover the address mask; it is perfectly reasonable for a
      host with non-volatile storage to use stored information
      (including a configuration file from a boot server).


Mogul & Postel                                                  [Page 9]



RFC 950                                                      August 1985
Internet Standard Subnetting Procedure


Appendix I.  Address Mask ICMP

   Address Mask Request or Address Mask 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         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Address Mask                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      IP Fields:

         Addresses

            The address of the source in an address mask request message
            will be the destination of the address mask reply message.
            To form an address mask 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 AM2, the address mask
            value inserted into the Address Mask field, and the checksum
            recomputed.  However, if the source address in the request
            message is zero, then the destination address for the reply
            message should denote a broadcast.

      ICMP Fields:

         Type

            AM1 for address mask request message

            AM2 for address mask reply message

         Code

            0 for address mask request message

            0 for address mask reply message

         Checksum

            The checksum is the 16-bit one's complement of the one's



Mogul & Postel                                                 [Page 10]



RFC 950                                                      August 1985
Internet Standard Subnetting Procedure


            complement sum of the ICMP message starting with the ICMP
            Type.  For computing the checksum, the checksum field should
            be zero.  This checksum may be replaced in the future.

         Identifier

            An identifier to aid in matching requests and replies, may
            be zero.

         Sequence Number

            A sequence number to aid in matching requests and replies,
            may be zero.

         Address Mask

            A 32-bit mask.

      Description

         A gateway receiving an address mask request should return it
         with the address mask field set to the 32-bit mask of the bits
         identifying the subnet and network, for the subnet on which the
         request was received.

         If the requesting host does not know its own IP address, it may
         leave the source field zero; the reply should then be
         broadcast.  However, this approach should be avoided if at all
         possible, since it increases the superfluous broadcast load on
         the network.  Even when the replies are broadcast, since there
         is only one possible address mask for a subnet, there is no
         need to match requests with replies.  The "Identifier" and
         "Sequence Number" fields can be ignored.

            Type AM1 may be received from a gateway or a host.

            Type AM2 may be received from a gateway, or a host acting in
            lieu of a gateway.











Mogul & Postel                                                 [Page 11]



RFC 950                                                      August 1985
Internet Standard Subnetting Procedure


Appendix II.  Examples

   These examples show how a host can find out the address mask using
   the ICMP Address Mask Request and Address Mask Reply messages.  For
   the following examples, assume that address 255.255.255.255 denotes
   "broadcast to this physical medium" [6].

   1.  A Class A Network Case

      For this case, assume that the requesting host is on class A
      network 36.0.0.0, has address 36.40.0.123, that there is a gateway
      at 36.40.0.62, and that a 8-bit wide subnet field is in use, that
      is, the address mask is 255.255.0.0.

      The most efficient method, and the one we recommend, is for a host
      to first discover its own address (perhaps using "RARP" [4]), and
      then to send the ICMP request to 255.255.255.255:

         Source address:          36.40.0.123
         Destination address:     255.255.255.255
         Protocol:                ICMP = 1
         Type:                    Address Mask Request = AM1
         Code:                    0
         Mask:                    0

      The gateway can then respond directly to the requesting host.

         Source address:          36.40.0.62
         Destination address:     36.40.0.123
         Protocol:                ICMP = 1
         Type:                    Address Mask Reply = AM2
         Code:                    0
         Mask:                    255.255.0.0

      Suppose that 36.40.0.123 is a diskless workstation, and does not
      know even its own host number.  It could send the following
      datagram:

         Source address:          0.0.0.0
         Destination address:     255.255.255.255
         Protocol:                ICMP = 1
         Type:                    Address Mask Request = AM1
         Code:                    0
         Mask:                    0

      36.40.0.62 will hear the datagram, and should respond with this
      datagram:


Mogul & Postel                                                 [Page 12]