rfc950.txt

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

Network Working Group                                J. Mogul (Stanford)
Request for Comments: 950                                J. Postel (ISI)
                                                             August 1985

                 Internet Standard Subnetting Procedure


Status Of This Memo

   This RFC specifies a protocol for the ARPA-Internet community.  If
   subnetting is implemented it is strongly recommended that these
   procedures be followed.  Distribution of this memo is unlimited.

Overview

   This memo discusses the utility of "subnets" of Internet networks,
   which are logically visible sub-sections of a single Internet
   network.  For administrative or technical reasons, many organizations
   have chosen to divide one Internet network into several subnets,
   instead of acquiring a set of Internet network numbers.  This memo
   specifies procedures for the use of subnets.  These procedures are
   for hosts (e.g., workstations).  The procedures used in and between
   subnet gateways are not fully described.  Important motivation and
   background information for a subnetting standard is provided in
   RFC-940 [7].

Acknowledgment

   This memo is based on RFC-917 [1].  Many people contributed to the
   development of the concepts described here.  J. Noel Chiappa, Chris
   Kent, and Tim Mann, in particular, provided important suggestions.
   Additional contributions in shaping this memo were made by Zaw-Sing
   Su, Mike Karels, and the Gateway Algorithms and Data Structures Task
   Force (GADS).



















Mogul & Postel                                                  [Page 1]



RFC 950                                                      August 1985
Internet Standard Subnetting Procedure


1.  Motivation

   The original view of the Internet universe was a two-level hierarchy:
   the top level the Internet as a whole, and the level below it
   individual networks, each with its own network number.  The Internet
   does not have a hierarchical topology, rather the interpretation of
   addresses is hierarchical.  In this two-level model, each host sees
   its network as a single entity; that is, the network may be treated
   as a "black box" to which a set of hosts is connected.

   While this view has proved simple and powerful, a number of
   organizations have found it inadequate, and have added a third level
   to the interpretation of Internet addresses.  In this view, a given
   Internet network is divided into a collection of subnets.

   The three-level model is useful in networks belonging to moderately
   large organizations (e.g., Universities or companies with more than
   one building), where it is often necessary to use more than one LAN
   cable to cover a "local area".  Each LAN may then be treated as a
   subnet.

   There are several reasons why an organization might use more than one
   cable to cover a campus:

      - Different technologies:  Especially in a research environment,
        there may be more than one kind of LAN in use; e.g., an
        organization may have some equipment that supports Ethernet, and
        some that supports a ring network.

      - Limits of technologies:  Most LAN technologies impose limits,
        based on electrical parameters, on the number of hosts
        connected, and on the total length of the cable.  It is easy to
        exceed these limits, especially those on cable length.

      - Network congestion:  It is possible for a small subset of the
        hosts on a LAN to monopolize most of the bandwidth.  A common
        solution to this problem is to divide the hosts into cliques of
        high mutual communication, and put these cliques on separate
        cables.

      - Point-to-Point links:  Sometimes a "local area", such as a
        university campus, is split into two locations too far apart to
        connect using the preferred LAN technology.  In this case,
        high-speed point-to-point links might connect several LANs.

   An organization that has been forced to use more than one LAN has
   three choices for assigning Internet addresses:


Mogul & Postel                                                  [Page 2]



RFC 950                                                      August 1985
Internet Standard Subnetting Procedure


      1. Acquire a distinct Internet network number for each cable;
         subnets are not used at all.

      2. Use a single network number for the entire organization, but
         assign host numbers without regard to which LAN a host is on
         ("transparent subnets").

      3. Use a single network number, and partition the host address
         space by assigning subnet numbers to the LANs ("explicit
         subnets").

   Each of these approaches has disadvantages.  The first, although not
   requiring any new or modified protocols, results in an explosion in
   the size of Internet routing tables.  Information about the internal
   details of local connectivity is propagated everywhere, although it
   is of little or no use outside the local organization.  Especially as
   some current gateway implementations do not have much space for
   routing tables, it would be good to avoid this problem.

   The second approach requires some convention or protocol that makes
   the collection of LANs appear to be a single Internet network.  For
   example, this can be done on LANs where each Internet address is
   translated to a hardware address using an Address Resolution Protocol
   (ARP), by having the bridges between the LANs intercept ARP requests
   for non-local targets, see RFC-925 [2].  However, it is not possible
   to do this for all LAN technologies, especially those where ARP
   protocols are not currently used, or if the LAN does not support
   broadcasts.  A more fundamental problem is that bridges must discover
   which LAN a host is on, perhaps by using a broadcast algorithm.  As
   the number of LANs grows, the cost of broadcasting grows as well;
   also, the size of translation caches required in the bridges grows
   with the total number of hosts in the network.

   The third approach is to explicitly support subnets.  This does have
   a disadvantage, in that it is a modification of the Internet
   Protocol, and thus requires changes to IP implementations already in
   use (if these implementations are to be used on a subnetted network).
   However, these changes are relatively minor, and once made, yield a
   simple and efficient solution to the problem.  Also, the approach
   avoids any changes that would be incompatible with existing hosts on
   non-subnetted networks.

   Further, when appropriate design choices are made, it is possible for
   hosts which believe they are on a non-subnetted network to be used on
   a subnetted one, as explained in RFC-917 [1].  This is useful when it
   is not possible to modify some of the hosts to support subnets
   explicitly, or when a gradual transition is preferred.


Mogul & Postel                                                  [Page 3]



RFC 950                                                      August 1985
Internet Standard Subnetting Procedure


2.  Standards for Subnet Addressing

   This section first describes a proposal for interpretation of
   Internet addresses to support subnets.  Next it discusses changes to
   host software to support subnets.  Finally, it presents a procedures
   for discovering what address interpretation is in use on a given
   network (i.e., what address mask is in use).

   2.1. Interpretation of Internet Addresses

      Suppose that an organization has been assigned an Internet network
      number, has further divided that network into a set of subnets,
      and wants to assign host addresses: how should this be done?
      Since there are minimal restrictions on the assignment of the
      "local address" part of the Internet address, several approaches
      have been proposed for representing the subnet number:

         1. Variable-width field:  Any number of the bits of the local
            address part are used for the subnet number; the size of
            this field, although constant for a given network, varies
            from network to network.  If the field width is zero, then
            subnets are not in use.

         2. Fixed-width field:  A specific number of bits (e.g., eight)
            is used for the subnet number, if subnets are in use.

         3. Self-encoding variable-width field:  Just as the width
            (i.e., class) of the network number field is encoded by its
            high-order bits, the width of the subnet field is similarly
            encoded.

         4. Self-encoding fixed-width field:  A specific number of bits
            is used for the subnet number.

         5. Masked bits:  Use a bit mask ("address mask") to identify
            which bits of the local address field indicate the subnet
            number.

      What criteria can be used to choose one of these five schemes?
      First, should we use a self-encoding scheme?  And, should it be
      possible to tell from examining an Internet address if it refers
      to a subnetted network, without reference to any other
      information?

         An interesting feature of self-encoding is that it allows the




Mogul & Postel                                                  [Page 4]



RFC 950                                                      August 1985
Internet Standard Subnetting Procedure


         address space of a network to be divided into subnets of
         different sizes, typically one subnet of half the address space
         and a set of small subnets.

            For example, consider a class C network that uses a
            self-encoding scheme with one bit to indicate if it is the
            large subnet or not and an additional three bits to identify
            the small subnet.  If the first bit is zero then this is the
            large subnet, if the first bit is one then the following
            bits (3 in this example) give the subnet number.  There is
            one subnet with 128 host addresses, and eight subnets with
            16 hosts each.

         To establish a subnetting standard the parameters and
         interpretation of the self-encoding scheme must be fixed and
         consistent throughout the Internet.

         It could be assumed that all networks are subnetted.  This
         would allow addresses to be interpreted without reference to
         any other information.

            This is a significant advantage, that given the Internet
            address no additional information is needed for an
            implementation to determine if two addresses are on the same
            subnet.  However, this can also be viewed as a disadvantage:
            it may cause problems for networks which have existing host
            numbers that use arbitrary bits in the local address part.
            In other words, it is useful to be able to control whether a
            network is subnetted independently from the assignment of
            host addresses.

         The alternative is to have the fact that a network is subnetted
         kept separate from the address.  If one finds, somehow, that
         the network is subnetted then the standard self-encoded
         subnetted network address rules are followed, otherwise the
         non-subnetted network addressing rules are followed.

      If a self-encoding scheme is not used, there is no reason to use a
      fixed-width field scheme: 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 (a subnet field width or
      address mask) instead of a boolean is negligible.  The advantage
      of using the address mask scheme is that it allows each
      organization to choose the best way to allocate relatively scarce
      bits of local address to subnet and host numbers.  Therefore, we
      choose the address-mask scheme: it is the most flexible scheme,
      yet costs no more to implement than any other.


Mogul & Postel                                                  [Page 5]



RFC 950                                                      August 1985
Internet Standard Subnetting Procedure


      For example, the Internet address might be interpreted as:

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

      where the <network-number> field is as defined by IP [3], the
      <host-number> field is at least 1-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 [3] is
      used).

      For example, on a Class B network with a 6-bit wide subnet field,
      an address would be 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1 0|        NETWORK            |  SUBNET   |    Host Number    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Since the bits that identify the subnet are specified by a
      bitmask, they need not be adjacent in the address.  However, we
      recommend that the subnet bits be contiguous and located as the
      most significant bits of the local address.

      Special Addresses:

         From the Assigned Numbers memo [9]:

            "In certain contexts, it is useful to have fixed addresses
            with functional significance rather than as identifiers of
            specific hosts.  When such usage is called for, the address
            zero is to be interpreted as meaning "this", as in "this
            network".  The address of all ones are to be interpreted as
            meaning "all", as in "all hosts".  For example, the address
            128.9.255.255 could be interpreted as meaning all hosts on
            the network 128.9.  Or, the address 0.0.0.37 could be
            interpreted as meaning host 37 on this network."

         It is useful to preserve and extend the interpretation of these
         special addresses in subnetted networks.  This means the values
         of all zeros and all ones in the subnet field should not be
         assigned to actual (physical) subnets.

            In the example above, the 6-bit wide subnet field may have
            any value except 0 and 63.


Mogul & Postel                                                  [Page 6]