rfc1219.txt

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

Network Working Group                                        P. Tsuchiya
Request for Comments: 1219                                      Bellcore
                                                              April 1991


                  On the Assignment of Subnet Numbers

Status Of This Memo

   This memo suggests a new procedure for assigning subnet numbers.  Use
   of this assignment technique within a network would be a purely local
   matter, and would not effect other networks.  Therefore, the use of
   these procedures is entirely discretionary.

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Overview

   RFC-950 [2] specifies a procedure for subnetting Internet addresses
   using a bit-mask.  While RFC-950 allows the "ones" in the subnet mask
   to be non-contiguous, RFC-950 recommends that 1) they be contiguous,
   and 2) that they occupy the most significant bits of the "host" part
   of the internet address.

   RFC-950 did not specify whether different subnets of the same network
   may have different masks.  This ambiguity was unfortunate, as it
   resulted in development of routing protocols that do not support
   different masks; see e.g., RIP [6].  The Gateway Requirements RFC [7]
   settled the issue in favor of allowing different masks, and therefore
   future routing protocols may be expected to support this feature;
   OSPF [3] is an example.

   The network administrator must of course determine the mask for each
   subnet.  This involves making an estimate of how many hosts each
   subnet is expected to have.  As it is often impossible to predict how
   large each subnet will grow, inefficient choices are often made, with
   some subnets under-utilized, and others possibly requiring
   renumbering because of exceeded capacity.

   This memo specifies a procedure for assigning subnet numbers that
   eliminates the need to estimate subnet size.  Essentially, host bits
   (mask = 0) are assigned from the least significant bit working
   towards the most, and subnet bits (mask = 1) are assigned from the
   most significant bit working towards the least.  As subnets grow,
   more host bits are assigned.  As the number of subnets grows, more
   subnet bits are assigned.  While this process does sometimes result



Tsuchiya                                                        [Page 1]

RFC 1219          On the Assignment of Subnet Numbers         April 1991


   in new subnet masks, no host ever need change addresses.

   This technique is not new, but it is also not widely known, and even
   less widely implemented.  With the development of new routing
   protocols such as OSPF, it is possible to take full advantage of this
   technique.  The purpose of this memo, then, is to make this technique
   widely known, and to specify it exactly.

   This memo requires no changes to existing Internet standards.  It
   does, however, require that the intra-domain routing protocol handle
   multiple different subnet masks.

Acknowledgments

   The author would like to thank Phil Karn, Charles Lynn, Jeff Mogul,
   and Charles Wolverton for their helpful suggestions.  Special thanks
   go to Joel Halpern for his painstaking debugging of the detailed
   specification and the examples.

1.  Motivation

   The Subnetting standard, RFC-950, specifies that the Host part of the
   formally 2-level Internet address can be divided into two fields,
   Subnet and Host.  This gives the Internet address a third level of
   hierarchy, and the concomitant firewalls and savings in routing
   overhead.  It also introduces increased inefficiency in the
   allocation of addresses.

   This inefficiency arises from the fact that the network administrator
   typically over-estimates the size (number of hosts) of any single
   subnetwork, in order to prevent future re-addressing of subnets.  It
   may also occur if the routing protocol being used does not handle
   different length subnets, and the administrator must therefore give
   every subnet an amount of space equivalent to that received by the
   largest subnet. (This RFC does not help in the latter case, as the
   technique herein requires different length subnets.)

   The administrative hassle associated with changing the subnet
   structure of a network can be considerable.  For instance, consider
   the following case.  A network has three subnets A, B, and C.  Assume
   that the lowest significant byte is the host part, and the next byte
   is the subnet part (that is, the mask is 255.255.255.0).  Assume
   further that A has subnet 1.0, B has subnet 2.0, and C has subnet
   3.0.

   Now, assume that B grows beyond its allocation of 254 hosts.
   Ideally, we would like to simply change B's mask without changing any
   of the host addresses in B.  However, the subnets numerically above



Tsuchiya                                                        [Page 2]

RFC 1219          On the Assignment of Subnet Numbers         April 1991


   and below B are already taken by A and C.  (If say 3.0 was not taken
   by C, B's mask could be changed from 255.0 (ff00) to 254.0 (fe00).
   In this case, all of B's existing addresses would still match the new
   subnet.  Indeed, if non-contiguous masks were in use, it might be
   possible for B to find some other mask bit to change to 0.  However,
   non-contiguous masks are generally not in favor, as they impose
   limitations on certain forwarding table lookup algorithms.  Indeed,
   RFC-950 discourages their use.)

   So, the choices available to the network administrator are to 1) form
   two subnets out of the existing one, or 2) renumber the subnet so
   that the subnet ends up with a smaller (fewer 1's) mask.  Choice 1
   can either be accomplished physically or logically.  Physically
   forming two subnets requires partitioning the subnet and inserting a
   gateway between the two partitions.  For obvious reasons, this is not
   a desirable course of action.  Logically forming two subnets can be
   done by simply assigning another subnet number (say 4.0) to the same
   subnet, and assigning host addresses under the new subnet.  The
   result of this logical partition is that the hosts with different
   subnet numbers will not recognize that the others are on the same
   subnet, and will send packets to the default gateway rather than
   directly to the host.  In fact, this is not such a bad solution,
   because assuming that the gateway is capable of recognizing multiple
   subnet numbers on the same subnet, the gateway will simply send the
   host an ICMP Redirect [4], and subsequent packets will go directly to
   the host [1] (this may not work correctly on all hosts).

   If, however, neither choice is acceptable or possible, then the
   network administrator must assign a new subnet number to B, thus
   renumbering the existing hosts, modifying the Domain Name System
   entries, and changing any other configuration files that have
   hardwired addresses for hosts in subnet B.

2. A More Flexible and Efficient Technique for Assigning Subnet Numbers

   In order to help explain the new technique, we shall show what is
   wrong with what is currently done now.  Currently, most subnets are
   assigned by splitting the host part of the address in two fields; the
   subnet field and the host field.  Mask bits are one for subnet field
   bits, and 0 for host field bits.  (In all of our addresses, the least
   significant bit (LSB) is on the right, the most significant bit (MSB)
   is on the left.)

        MSB                                LSB
        --------------------------------------
       | subnet field    | host field         |
        --------------------------------------




Tsuchiya                                                        [Page 3]

RFC 1219          On the Assignment of Subnet Numbers         April 1991


   The subnet field could be different lengths for different size
   subnets.  For instance, say a network had two large subnets and the
   rest small subnets (by large subnet we mean a large number of hosts).
   Then the network administrator might assign two types of addresses:

        --------------------------------------
       | subnet |               host          |  large subnets
        --------------------------------------

        --------------------------------------
       |         subnet             |  host   |  small subnets
        --------------------------------------

   In this case, the full range of subnet numbers would not be available
   to the small subnets, as the bits in the small subnet that correspond
   to those in the large subnet could not have the same values as those
   in the large subnets.  For instance, say that the large subnets had
   4-bit subnet numbers, and the small subnets had 8-bit subnet numbers.
   If the large subnets had values 0001 and 0010, then subnet numbers in
   the range 00010000 to 00101111 could not be assigned to the small
   subnets, otherwise there will be addresses that would match both
   subnets.

   In any event, a network administrator will typically assign values to
   the two fields in numerical order.  For example, within a given
   subnet, hosts will be numbered 1, 2, 3, etc.  Within a given network,
   subnets will be numbered 1, 2, 3, etc.  The result is that some
   number of bits on the right side of the subnet and host fields will
   be ones for some hosts and zeros for others, and some number of bits
   on the left side of the subnet and host fields will be zeros for all
   subnets and hosts.  The "all zeros" bits represent room for growth,
   and the "ones and zeros" bits represent bits already consumed by
   growth.

        --------------------------------------
       | subnet field    | host field         |
       |-----+-----------+-------+------------|
       |     |           |       |            |
       | 0's | 1's & 0's |  0's  | 1's & 0's  |
          /\                /\
          ||                ||
        subnets can         hosts can grow here
        grow here

   Now, let's assume that the number of hosts in a certain subnet grows
   to the maximum allowed, but that there is still room in the subnet
   field to assign more addresses.  We then have the following:




Tsuchiya                                                        [Page 4]

RFC 1219          On the Assignment of Subnet Numbers         April 1991


        --------------------------------------
       | subnet field    | host field         |
       |-----+-----------+--------------------|
       |     |           |                    |
       | 0's | 1's & 0's |     1's & 0's      |


   While the host field can no longer grow, there is still room in the
   address for growth.  The problem is that because of where the growth
   areas are situated, the remaining growth has been effectively
   reserved for subnets only.

   What should be done instead is to assign subnet numbers so that the
   ones start from the left of the subnet field and work right.  In this
   case we get the following:

        --------------------------------------
       | subnet field    | host field         |
       |-----------+-------------+------------|
       |           |             |            |
       | 1's & 0's |    0's      | 1's & 0's  |
                         /\
                         ||
                    Both hosts and subnets can
                    grow here

   Now, both hosts and subnets individually have considerably more
   growing space than before, although the combined growing space is the
   same.  Since one can rarely predict how many hosts might end up in a
   subnet, or how many subnets there might eventually be, this
   arrangement allows for the maximum flexibility in growth.

   Actually, the previous figure is misleading.  The boundary between
   the host and subnet fields is being shown in the middle of the growth
   area.  However, the boundary could exist anywhere within the growth
   area.  Note that it is the mask itself that determines where the
   boundary is.  Ones in the mask indicate subnet bits, and zeros
   indicate host bits.  We will show later that in fact the boundary
   should lie somewhere in the middle.  Putting it there minimizes the
   number of times that the masks must be changed in hosts.

   2.1  Specification of the New Technique

   Having given the appropriate explanatory material, we can now specify
   the procedure for subnet number assignment.  We need the following
   definitions:

   Host-assigned Bits (h-bits):  These are the bits, contiguous from



Tsuchiya                                                        [Page 5]

RFC 1219          On the Assignment of Subnet Numbers         April 1991


      the right, for which host values, within a given subnet, contain
      both ones and zeros.  Different subnets may have different h-bits.

   Subnet-assigned Bits (s-bits):  These are the bits, contiguous from
      the left, which 1) are not h-bits, AND 2) are required to
      distinguish one subnet from another, AND 3) include all bits
      to the left of and including the right-most one.  Notice that
      different subnets may have different s-bits.

   Growth Bits (g-bits):  These are the "all zeros" bits in between
      the h-bits and s-bits.

   s-mask:  For a given subnet, the mask whereby all s-bits are one,
      and all g-bits and h-bits are zero.

   g-mask:  For a given subnet, the mask whereby all s-bits and g-bits
      are one, and all h-bits are zero.

   Subnet Field:  These are the one bits in the subnet mask (as
      defined in RFC-950).  These bits are on the left.  The subnet
      field must at least include all of the s-bits, and may
      additionally include some or all of the g-bits.

   Host Field:  These are the zero bits in the subnet mask.
      These bits are on the right.  The host field must at least
      include all of the h-bits, and may additionally include some
      or all of the g-bits.

   Mirror-image Counting:  Normal counting, in binary, causes one
      bits to start at the right and work left.  This is how host
      values are assigned.  However, for subnet assignment, we want
      the one bits to start at the left and work right.  This process
      is the mirror image of normal counting, where the MSB is swapped
      with the LSB, the second MSB is swapped with the second LSB, and
      so on.  So, where normal counting is:

                0       (reserved to mean "this host")
               01
               10
              011
              100
              101
              :
              :
        11...1110
        11...1111       (reserved to mean "all hosts")

      and so on, Mirror-image, or MI counting, is:



Tsuchiya                                                        [Page 6]

RFC 1219          On the Assignment of Subnet Numbers         April 1991


        0       (reserved to mean "this subnet")
        10
        01
        110
        001
        101
          :
          :
        011...11
        111...11        (reserved to mean "all subnets")

      and so on.  If the current MI counting value is, say, 001,
      the "next" MI value is 101, and the "previous" MI value is 11.

   Now we can specify the algorithm.  We have the following functions:
   Initialize(), AddSubnet(), RemoveSubnet(subnet#), AddHost(subnet#),
   and RemoveHost(subnet#,host#).

   Notice that the algorithm is described as though one state machine is
   executing it.  In reality, there may be a root Address Authority
   (RootAA) that assigns subnet numbers (Initialize, AddSubnet, and
   RemoveSubnet), and subnet AA, that assign host numbers within a
   subnet (AddHost and RemoveHost).  While in general the AAs can act
   independently, there are two cases where "coordination" is required