home *** CD-ROM | disk | FTP | other *** search
/ Hackers Toolkit 2.0 / Hackers_Toolkit_v2.0.iso / HTML / archive / Texts / Rfc / RFC950.TXT < prev    next >
Encoding:
Text File  |  1999-11-04  |  37.1 KB  |  1,045 lines
  1. Network Working Group                                J. Mogul (Stanford)
  2. Request for Comments: 950                                J. Postel (ISI)
  3.                                                              August 1985
  4.  
  5.                  Internet Standard Subnetting Procedure
  6.  
  7.  
  8. Status Of This Memo
  9.  
  10.    This RFC specifies a protocol for the ARPA-Internet community.  If
  11.    subnetting is implemented it is strongly recommended that these
  12.    procedures be followed.  Distribution of this memo is unlimited.
  13.  
  14. Overview
  15.  
  16.    This memo discusses the utility of "subnets" of Internet networks,
  17.    which are logically visible sub-sections of a single Internet
  18.    network.  For administrative or technical reasons, many organizations
  19.    have chosen to divide one Internet network into several subnets,
  20.    instead of acquiring a set of Internet network numbers.  This memo
  21.    specifies procedures for the use of subnets.  These procedures are
  22.    for hosts (e.g., workstations).  The procedures used in and between
  23.    subnet gateways are not fully described.  Important motivation and
  24.    background information for a subnetting standard is provided in
  25.    RFC-940 [7].
  26.  
  27. Acknowledgment
  28.  
  29.    This memo is based on RFC-917 [1].  Many people contributed to the
  30.    development of the concepts described here.  J. Noel Chiappa, Chris
  31.    Kent, and Tim Mann, in particular, provided important suggestions.
  32.    Additional contributions in shaping this memo were made by Zaw-Sing
  33.    Su, Mike Karels, and the Gateway Algorithms and Data Structures Task
  34.    Force (GADS).
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54. Mogul & Postel                                                  [Page 1]
  55.  
  56.  
  57.  
  58.  
  59. RFC 950                                                      August 1985
  60. Internet Standard Subnetting Procedure
  61.  
  62.  
  63. 1.  Motivation
  64.  
  65.    The original view of the Internet universe was a two-level hierarchy:
  66.    the top level the Internet as a whole, and the level below it
  67.    individual networks, each with its own network number.  The Internet
  68.    does not have a hierarchical topology, rather the interpretation of
  69.    addresses is hierarchical.  In this two-level model, each host sees
  70.    its network as a single entity; that is, the network may be treated
  71.    as a "black box" to which a set of hosts is connected.
  72.  
  73.    While this view has proved simple and powerful, a number of
  74.    organizations have found it inadequate, and have added a third level
  75.    to the interpretation of Internet addresses.  In this view, a given
  76.    Internet network is divided into a collection of subnets.
  77.  
  78.    The three-level model is useful in networks belonging to moderately
  79.    large organizations (e.g., Universities or companies with more than
  80.    one building), where it is often necessary to use more than one LAN
  81.    cable to cover a "local area".  Each LAN may then be treated as a
  82.    subnet.
  83.  
  84.    There are several reasons why an organization might use more than one
  85.    cable to cover a campus:
  86.  
  87.       - Different technologies:  Especially in a research environment,
  88.         there may be more than one kind of LAN in use; e.g., an
  89.         organization may have some equipment that supports Ethernet, and
  90.         some that supports a ring network.
  91.  
  92.       - Limits of technologies:  Most LAN technologies impose limits,
  93.         based on electrical parameters, on the number of hosts
  94.         connected, and on the total length of the cable.  It is easy to
  95.         exceed these limits, especially those on cable length.
  96.  
  97.       - Network congestion:  It is possible for a small subset of the
  98.         hosts on a LAN to monopolize most of the bandwidth.  A common
  99.         solution to this problem is to divide the hosts into cliques of
  100.         high mutual communication, and put these cliques on separate
  101.         cables.
  102.  
  103.       - Point-to-Point links:  Sometimes a "local area", such as a
  104.         university campus, is split into two locations too far apart to
  105.         connect using the preferred LAN technology.  In this case,
  106.         high-speed point-to-point links might connect several LANs.
  107.  
  108.    An organization that has been forced to use more than one LAN has
  109.    three choices for assigning Internet addresses:
  110.  
  111.  
  112. Mogul & Postel                                                  [Page 2]
  113.  
  114.  
  115.  
  116.  
  117. RFC 950                                                      August 1985
  118. Internet Standard Subnetting Procedure
  119.  
  120.  
  121.       1. Acquire a distinct Internet network number for each cable;
  122.          subnets are not used at all.
  123.  
  124.       2. Use a single network number for the entire organization, but
  125.          assign host numbers without regard to which LAN a host is on
  126.          ("transparent subnets").
  127.  
  128.       3. Use a single network number, and partition the host address
  129.          space by assigning subnet numbers to the LANs ("explicit
  130.          subnets").
  131.  
  132.    Each of these approaches has disadvantages.  The first, although not
  133.    requiring any new or modified protocols, results in an explosion in
  134.    the size of Internet routing tables.  Information about the internal
  135.    details of local connectivity is propagated everywhere, although it
  136.    is of little or no use outside the local organization.  Especially as
  137.    some current gateway implementations do not have much space for
  138.    routing tables, it would be good to avoid this problem.
  139.  
  140.    The second approach requires some convention or protocol that makes
  141.    the collection of LANs appear to be a single Internet network.  For
  142.    example, this can be done on LANs where each Internet address is
  143.    translated to a hardware address using an Address Resolution Protocol
  144.    (ARP), by having the bridges between the LANs intercept ARP requests
  145.    for non-local targets, see RFC-925 [2].  However, it is not possible
  146.    to do this for all LAN technologies, especially those where ARP
  147.    protocols are not currently used, or if the LAN does not support
  148.    broadcasts.  A more fundamental problem is that bridges must discover
  149.    which LAN a host is on, perhaps by using a broadcast algorithm.  As
  150.    the number of LANs grows, the cost of broadcasting grows as well;
  151.    also, the size of translation caches required in the bridges grows
  152.    with the total number of hosts in the network.
  153.  
  154.    The third approach is to explicitly support subnets.  This does have
  155.    a disadvantage, in that it is a modification of the Internet
  156.    Protocol, and thus requires changes to IP implementations already in
  157.    use (if these implementations are to be used on a subnetted network).
  158.    However, these changes are relatively minor, and once made, yield a
  159.    simple and efficient solution to the problem.  Also, the approach
  160.    avoids any changes that would be incompatible with existing hosts on
  161.    non-subnetted networks.
  162.  
  163.    Further, when appropriate design choices are made, it is possible for
  164.    hosts which believe they are on a non-subnetted network to be used on
  165.    a subnetted one, as explained in RFC-917 [1].  This is useful when it
  166.    is not possible to modify some of the hosts to support subnets
  167.    explicitly, or when a gradual transition is preferred.
  168.  
  169.  
  170. Mogul & Postel                                                  [Page 3]
  171.  
  172.  
  173.  
  174.  
  175. RFC 950                                                      August 1985
  176. Internet Standard Subnetting Procedure
  177.  
  178.  
  179. 2.  Standards for Subnet Addressing
  180.  
  181.    This section first describes a proposal for interpretation of
  182.    Internet addresses to support subnets.  Next it discusses changes to
  183.    host software to support subnets.  Finally, it presents a procedures
  184.    for discovering what address interpretation is in use on a given
  185.    network (i.e., what address mask is in use).
  186.  
  187.    2.1. Interpretation of Internet Addresses
  188.  
  189.       Suppose that an organization has been assigned an Internet network
  190.       number, has further divided that network into a set of subnets,
  191.       and wants to assign host addresses: how should this be done?
  192.       Since there are minimal restrictions on the assignment of the
  193.       "local address" part of the Internet address, several approaches
  194.       have been proposed for representing the subnet number:
  195.  
  196.          1. Variable-width field:  Any number of the bits of the local
  197.             address part are used for the subnet number; the size of
  198.             this field, although constant for a given network, varies
  199.             from network to network.  If the field width is zero, then
  200.             subnets are not in use.
  201.  
  202.          2. Fixed-width field:  A specific number of bits (e.g., eight)
  203.             is used for the subnet number, if subnets are in use.
  204.  
  205.          3. Self-encoding variable-width field:  Just as the width
  206.             (i.e., class) of the network number field is encoded by its
  207.             high-order bits, the width of the subnet field is similarly
  208.             encoded.
  209.  
  210.          4. Self-encoding fixed-width field:  A specific number of bits
  211.             is used for the subnet number.
  212.  
  213.          5. Masked bits:  Use a bit mask ("address mask") to identify
  214.             which bits of the local address field indicate the subnet
  215.             number.
  216.  
  217.       What criteria can be used to choose one of these five schemes?
  218.       First, should we use a self-encoding scheme?  And, should it be
  219.       possible to tell from examining an Internet address if it refers
  220.       to a subnetted network, without reference to any other
  221.       information?
  222.  
  223.          An interesting feature of self-encoding is that it allows the
  224.  
  225.  
  226.  
  227.  
  228. Mogul & Postel                                                  [Page 4]
  229.  
  230.  
  231.  
  232.  
  233. RFC 950                                                      August 1985
  234. Internet Standard Subnetting Procedure
  235.  
  236.  
  237.          address space of a network to be divided into subnets of
  238.          different sizes, typically one subnet of half the address space
  239.          and a set of small subnets.
  240.  
  241.             For example, consider a class C network that uses a
  242.             self-encoding scheme with one bit to indicate if it is the
  243.             large subnet or not and an additional three bits to identify
  244.             the small subnet.  If the first bit is zero then this is the
  245.             large subnet, if the first bit is one then the following
  246.             bits (3 in this example) give the subnet number.  There is
  247.             one subnet with 128 host addresses, and eight subnets with
  248.             16 hosts each.
  249.  
  250.          To establish a subnetting standard the parameters and
  251.          interpretation of the self-encoding scheme must be fixed and
  252.          consistent throughout the Internet.
  253.  
  254.          It could be assumed that all networks are subnetted.  This
  255.          would allow addresses to be interpreted without reference to
  256.          any other information.
  257.  
  258.             This is a significant advantage, that given the Internet
  259.             address no additional information is needed for an
  260.             implementation to determine if two addresses are on the same
  261.             subnet.  However, this can also be viewed as a disadvantage:
  262.             it may cause problems for networks which have existing host
  263.             numbers that use arbitrary bits in the local address part.
  264.             In other words, it is useful to be able to control whether a
  265.             network is subnetted independently from the assignment of
  266.             host addresses.
  267.  
  268.          The alternative is to have the fact that a network is subnetted
  269.          kept separate from the address.  If one finds, somehow, that
  270.          the network is subnetted then the standard self-encoded
  271.          subnetted network address rules are followed, otherwise the
  272.          non-subnetted network addressing rules are followed.
  273.  
  274.       If a self-encoding scheme is not used, there is no reason to use a
  275.       fixed-width field scheme: since there must in any case be some
  276.       per-network "flag" to indicate if subnets are in use, the
  277.       additional cost of using an integer (a subnet field width or
  278.       address mask) instead of a boolean is negligible.  The advantage
  279.       of using the address mask scheme is that it allows each
  280.       organization to choose the best way to allocate relatively scarce
  281.       bits of local address to subnet and host numbers.  Therefore, we
  282.       choose the address-mask scheme: it is the most flexible scheme,
  283.       yet costs no more to implement than any other.
  284.  
  285.  
  286. Mogul & Postel                                                  [Page 5]
  287.  
  288.  
  289.  
  290.  
  291. RFC 950                                                      August 1985
  292. Internet Standard Subnetting Procedure
  293.  
  294.  
  295.       For example, the Internet address might be interpreted as:
  296.  
  297.          <network-number><subnet-number><host-number>
  298.  
  299.       where the <network-number> field is as defined by IP [3], the
  300.       <host-number> field is at least 1-bit wide, and the width of the
  301.       <subnet-number> field is constant for a given network.  No further
  302.       structure is required for the <subnet-number> or <host-number>
  303.       fields.  If the width of the <subnet-number> field is zero, then
  304.       the network is not subnetted (i.e., the interpretation of [3] is
  305.       used).
  306.  
  307.       For example, on a Class B network with a 6-bit wide subnet field,
  308.       an address would be broken down like this:
  309.  
  310.                            1                   2                   3
  311.        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
  312.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  313.       |1 0|        NETWORK            |  SUBNET   |    Host Number    |
  314.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  315.  
  316.       Since the bits that identify the subnet are specified by a
  317.       bitmask, they need not be adjacent in the address.  However, we
  318.       recommend that the subnet bits be contiguous and located as the
  319.       most significant bits of the local address.
  320.  
  321.       Special Addresses:
  322.  
  323.          From the Assigned Numbers memo [9]:
  324.  
  325.             "In certain contexts, it is useful to have fixed addresses
  326.             with functional significance rather than as identifiers of
  327.             specific hosts.  When such usage is called for, the address
  328.             zero is to be interpreted as meaning "this", as in "this
  329.             network".  The address of all ones are to be interpreted as
  330.             meaning "all", as in "all hosts".  For example, the address
  331.             128.9.255.255 could be interpreted as meaning all hosts on
  332.             the network 128.9.  Or, the address 0.0.0.37 could be
  333.             interpreted as meaning host 37 on this network."
  334.  
  335.          It is useful to preserve and extend the interpretation of these
  336.          special addresses in subnetted networks.  This means the values
  337.          of all zeros and all ones in the subnet field should not be
  338.          assigned to actual (physical) subnets.
  339.  
  340.             In the example above, the 6-bit wide subnet field may have
  341.             any value except 0 and 63.
  342.  
  343.  
  344. Mogul & Postel                                                  [Page 6]
  345.  
  346.  
  347.  
  348.  
  349. RFC 950                                                      August 1985
  350. Internet Standard Subnetting Procedure
  351.  
  352.  
  353.          Please note that there is no effect or new restriction on the
  354.          addresses of hosts on non-subnetted networks.
  355.  
  356.    2.2. Changes to Host Software to Support Subnets
  357.  
  358.       In most implementations of IP, there is code in the module that
  359.       handles outgoing datagrams to decide if a datagram can be sent
  360.       directly to the destination on the local network or if it must be
  361.       sent to a gateway.
  362.  
  363.       Generally the code is something like this:
  364.  
  365.          IF ip_net_number(dg.ip_dest) = ip_net_number(my_ip_addr)
  366.              THEN
  367.                  send_dg_locally(dg, dg.ip_dest)
  368.              ELSE
  369.                  send_dg_locally(dg,
  370.                                   gateway_to(ip_net_number(dg.ip_dest)))
  371.  
  372.       (If the code supports multiply-connected networks, it will be more
  373.       complicated, but this is irrelevant to the current discussion.)
  374.  
  375.       To support subnets, it is necessary to store one more 32-bit
  376.       quantity, called my_ip_mask.  This is a bit-mask with bits set in
  377.       the fields corresponding to the IP network number, and additional
  378.       bits set corresponding to the subnet number field.
  379.  
  380.       The code then becomes:
  381.  
  382.          IF bitwise_and(dg.ip_dest, my_ip_mask)
  383.                                    = bitwise_and(my_ip_addr, my_ip_mask)
  384.              THEN
  385.                  send_dg_locally(dg, dg.ip_dest)
  386.              ELSE
  387.                  send_dg_locally(dg,
  388.                         gateway_to(bitwise_and(dg.ip_dest, my_ip_mask)))
  389.  
  390.       Of course, part of the expression in the conditional can be
  391.       pre-computed.
  392.  
  393.       It may or may not be necessary to modify the "gateway_to"
  394.       function, so that it too takes the subnet field bits into account
  395.       when performing comparisons.
  396.  
  397.       To support multiply-connected hosts, the code can be changed to
  398.  
  399.  
  400.  
  401.  
  402. Mogul & Postel                                                  [Page 7]
  403.  
  404.  
  405.  
  406.  
  407. RFC 950                                                      August 1985
  408. Internet Standard Subnetting Procedure
  409.  
  410.  
  411.       keep  the "my_ip_addr" and "my_ip_mask" quantities on a
  412.       per-interface basis; the expression in the conditional must then
  413.       be evaluated for each interface.
  414.  
  415.    2.3. Finding the Address Mask
  416.  
  417.       How can a host determine what address mask is in use on a subnet
  418.       to which it is connected?  The problem is analogous to several
  419.       other "bootstrapping" problems for Internet hosts: how a host
  420.       determines its own address, and how it locates a gateway on its
  421.       local network.  In all three cases, there are two basic solutions:
  422.       "hardwired" information, and broadcast-based protocols.
  423.  
  424.       Hardwired information is that available to a host in isolation
  425.       from a network.  It may be compiled-in, or (preferably) stored in
  426.       a disk file.  However, for the increasingly common case of a
  427.       diskless workstation that is bootloaded over a LAN, neither
  428.       hardwired solution is satisfactory.
  429.  
  430.       Instead, since most LAN technology supports broadcasting, a better
  431.       method is for the newly-booted host to broadcast a request for the
  432.       necessary information.  For example, for the purpose of
  433.       determining its Internet address, a host may use the "Reverse
  434.       Address Resolution Protocol" (RARP) [4].
  435.  
  436.       However, since a newly-booted host usually needs to gather several
  437.       facts (e.g., its IP address, the hardware address of a gateway,
  438.       the IP address of a domain name server, the subnet address mask),
  439.       it would be better to acquire all this information in one request
  440.       if possible, rather than doing numerous broadcasts on the network.
  441.       The mechanisms designed to boot diskless workstations can also
  442.       load per-host specific configuration files that contain the
  443.       required information (e.g., see RFC-951 [8]).  It is possible, and
  444.       desirable, to obtain all the facts necessary to operate a host
  445.       from a boot server using only one broadcast message.
  446.  
  447.       In the case where it is necessary for a host to find the address
  448.       mask as a separate operation the following mechanism is provided:
  449.  
  450.          To provide the address mask information the ICMP protocol [5]
  451.          is extended by adding a new pair of ICMP message types,
  452.          "Address Mask Request" and "Address Mask Reply", analogous to
  453.          the "Information Request" and "Information Reply" ICMP
  454.          messages.  These are described in detail in Appendix I.
  455.  
  456.          The intended use of these new ICMP messages is that a host,
  457.          when booting, broadcast an "Address Mask Request" message.  A
  458.  
  459.  
  460. Mogul & Postel                                                  [Page 8]
  461.  
  462.  
  463.  
  464.  
  465. RFC 950                                                      August 1985
  466. Internet Standard Subnetting Procedure
  467.  
  468.  
  469.          gateway (or a host acting in lieu of a gateway) that receives
  470.          this message responds with an "Address Mask Reply".  If there
  471.          is no indication in the request which host sent it (i.e., the
  472.          IP Source Address is zero), the reply is broadcast as well.
  473.          The requesting host will hear the response, and from it
  474.          determine the address mask.
  475.  
  476.          Since there is only one possible value that can be sent in an
  477.          "Address Mask Reply" on any given LAN, there is no need for the
  478.          requesting host to match the responses it hears against the
  479.          request it sent; similarly, there is no problem if more than
  480.          one gateway responds.  We assume that hosts reboot
  481.          infrequently, so the broadcast load on a network from use of
  482.          this protocol should be small.
  483.  
  484.       If a host is connected to more than one LAN, it might have to find
  485.       the address mask for each.
  486.  
  487.       One potential problem is what a host should do if it can not find
  488.       out the address mask, even after a reasonable number of tries.
  489.       Three interpretations can be placed on the situation:
  490.  
  491.          1. The local net exists in (permanent) isolation from all other
  492.             nets.
  493.  
  494.          2. Subnets are not in use, and no host can supply the address
  495.             mask.
  496.  
  497.          3. All gateways on the local net are (temporarily) down.
  498.  
  499.       The first and second situations imply that the address mask is
  500.       identical with the Internet network number mask.  In the third
  501.       situation, there is no way to determine what the proper value is;
  502.       the safest choice is thus a mask identical with the Internet
  503.       network number mask.  Although this might later turn out to be
  504.       wrong, it will not prevent transmissions that would otherwise
  505.       succeed.  It is possible for a host to recover from a wrong
  506.       choice: when a gateway comes up, it should broadcast an "Address
  507.       Mask Reply"; when a host receives such a message that disagrees
  508.       with its guess, it should change its mask to conform to the
  509.       received value.  No host or gateway should send an "Address Mask
  510.       Reply" based on a "guessed" value.
  511.  
  512.       Finally, note that no host is required to use this ICMP protocol
  513.       to discover the address mask; it is perfectly reasonable for a
  514.       host with non-volatile storage to use stored information
  515.       (including a configuration file from a boot server).
  516.  
  517.  
  518. Mogul & Postel                                                  [Page 9]
  519.  
  520.  
  521.  
  522.  
  523. RFC 950                                                      August 1985
  524. Internet Standard Subnetting Procedure
  525.  
  526.  
  527. Appendix I.  Address Mask ICMP
  528.  
  529.    Address Mask Request or Address Mask Reply
  530.  
  531.        0                   1                   2                   3
  532.        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
  533.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  534.       |     Type      |      Code     |          Checksum             |
  535.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  536.       |           Identifier          |       Sequence Number         |
  537.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  538.       |                        Address Mask                           |
  539.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  540.  
  541.       IP Fields:
  542.  
  543.          Addresses
  544.  
  545.             The address of the source in an address mask request message
  546.             will be the destination of the address mask reply message.
  547.             To form an address mask reply message, the source address of
  548.             the request becomes the destination address of the reply,
  549.             the source address of the reply is set to the replier's
  550.             address, the type code changed to AM2, the address mask
  551.             value inserted into the Address Mask field, and the checksum
  552.             recomputed.  However, if the source address in the request
  553.             message is zero, then the destination address for the reply
  554.             message should denote a broadcast.
  555.  
  556.       ICMP Fields:
  557.  
  558.          Type
  559.  
  560.             AM1 for address mask request message
  561.  
  562.             AM2 for address mask reply message
  563.  
  564.          Code
  565.  
  566.             0 for address mask request message
  567.  
  568.             0 for address mask reply message
  569.  
  570.          Checksum
  571.  
  572.             The checksum is the 16-bit one's complement of the one's
  573.  
  574.  
  575.  
  576. Mogul & Postel                                                 [Page 10]
  577.  
  578.  
  579.  
  580.  
  581. RFC 950                                                      August 1985
  582. Internet Standard Subnetting Procedure
  583.  
  584.  
  585.             complement sum of the ICMP message starting with the ICMP
  586.             Type.  For computing the checksum, the checksum field should
  587.             be zero.  This checksum may be replaced in the future.
  588.  
  589.          Identifier
  590.  
  591.             An identifier to aid in matching requests and replies, may
  592.             be zero.
  593.  
  594.          Sequence Number
  595.  
  596.             A sequence number to aid in matching requests and replies,
  597.             may be zero.
  598.  
  599.          Address Mask
  600.  
  601.             A 32-bit mask.
  602.  
  603.       Description
  604.  
  605.          A gateway receiving an address mask request should return it
  606.          with the address mask field set to the 32-bit mask of the bits
  607.          identifying the subnet and network, for the subnet on which the
  608.          request was received.
  609.  
  610.          If the requesting host does not know its own IP address, it may
  611.          leave the source field zero; the reply should then be
  612.          broadcast.  However, this approach should be avoided if at all
  613.          possible, since it increases the superfluous broadcast load on
  614.          the network.  Even when the replies are broadcast, since there
  615.          is only one possible address mask for a subnet, there is no
  616.          need to match requests with replies.  The "Identifier" and
  617.          "Sequence Number" fields can be ignored.
  618.  
  619.             Type AM1 may be received from a gateway or a host.
  620.  
  621.             Type AM2 may be received from a gateway, or a host acting in
  622.             lieu of a gateway.
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634. Mogul & Postel                                                 [Page 11]
  635.  
  636.  
  637.  
  638.  
  639. RFC 950                                                      August 1985
  640. Internet Standard Subnetting Procedure
  641.  
  642.  
  643. Appendix II.  Examples
  644.  
  645.    These examples show how a host can find out the address mask using
  646.    the ICMP Address Mask Request and Address Mask Reply messages.  For
  647.    the following examples, assume that address 255.255.255.255 denotes
  648.    "broadcast to this physical medium" [6].
  649.  
  650.    1.  A Class A Network Case
  651.  
  652.       For this case, assume that the requesting host is on class A
  653.       network 36.0.0.0, has address 36.40.0.123, that there is a gateway
  654.       at 36.40.0.62, and that a 8-bit wide subnet field is in use, that
  655.       is, the address mask is 255.255.0.0.
  656.  
  657.       The most efficient method, and the one we recommend, is for a host
  658.       to first discover its own address (perhaps using "RARP" [4]), and
  659.       then to send the ICMP request to 255.255.255.255:
  660.  
  661.          Source address:          36.40.0.123
  662.          Destination address:     255.255.255.255
  663.          Protocol:                ICMP = 1
  664.          Type:                    Address Mask Request = AM1
  665.          Code:                    0
  666.          Mask:                    0
  667.  
  668.       The gateway can then respond directly to the requesting host.
  669.  
  670.          Source address:          36.40.0.62
  671.          Destination address:     36.40.0.123
  672.          Protocol:                ICMP = 1
  673.          Type:                    Address Mask Reply = AM2
  674.          Code:                    0
  675.          Mask:                    255.255.0.0
  676.  
  677.       Suppose that 36.40.0.123 is a diskless workstation, and does not
  678.       know even its own host number.  It could send the following
  679.       datagram:
  680.  
  681.          Source address:          0.0.0.0
  682.          Destination address:     255.255.255.255
  683.          Protocol:                ICMP = 1
  684.          Type:                    Address Mask Request = AM1
  685.          Code:                    0
  686.          Mask:                    0
  687.  
  688.       36.40.0.62 will hear the datagram, and should respond with this
  689.       datagram:
  690.  
  691.  
  692. Mogul & Postel                                                 [Page 12]
  693.  
  694.  
  695.  
  696.  
  697. RFC 950                                                      August 1985
  698. Internet Standard Subnetting Procedure
  699.  
  700.  
  701.          Source address:          36.40.0.62
  702.          Destination address:     255.255.255.255
  703.          Protocol:                ICMP = 1
  704.          Type:                    Address Mask Reply = AM2
  705.          Code:                    0
  706.          Mask:                    255.255.0.0
  707.  
  708.       Note that the gateway uses the narrowest possible broadcast to
  709.       reply.  Even so, the over use of broadcasts presents an
  710.       unnecessary load to all hosts on the subnet, and so the use of the
  711.       "anonymous" (0.0.0.0) source address must be kept to a minimum.
  712.  
  713.       If broadcasting is not allowed, we assume that hosts have wired-in
  714.       information about neighbor gateways; thus, 36.40.0.123 might send
  715.       this datagram:
  716.  
  717.          Source address:          36.40.0.123
  718.          Destination address:     36.40.0.62
  719.          Protocol:                ICMP = 1
  720.          Type:                    Address Mask Request = AM1
  721.          Code:                    0
  722.          Mask:                    0
  723.  
  724.       36.40.0.62 should respond exactly as in the previous case.
  725.  
  726.          Source address:          36.40.0.62
  727.          Destination address:     36.40.0.123
  728.          Protocol:                ICMP = 1
  729.          Type:                    Address Mask Reply = AM2
  730.          Code:                    0
  731.          Mask:                    255.255.0.0
  732.  
  733.    2.  A Class B Network Case
  734.  
  735.       For this case, assume that the requesting host is on class B
  736.       network 128.99.0.0, has address 128.99.4.123, that there is a
  737.       gateway at 128.99.4.62, and that a 6-bit wide subnet field is in
  738.       use, that is, the address mask is 255.255.252.0.
  739.  
  740.       The host sends the ICMP request to 255.255.255.255:
  741.  
  742.          Source address:          128.99.4.123
  743.          Destination address:     255.255.255.255
  744.          Protocol:                ICMP = 1
  745.          Type:                    Address Mask Request = AM1
  746.          Code:                    0
  747.          Mask:                    0
  748.  
  749.  
  750. Mogul & Postel                                                 [Page 13]
  751.  
  752.  
  753.  
  754.  
  755. RFC 950                                                      August 1985
  756. Internet Standard Subnetting Procedure
  757.  
  758.  
  759.       The gateway can then respond directly to the requesting host.
  760.  
  761.          Source address:          128.99.4.62
  762.          Destination address:     128.99.4.123
  763.          Protocol:                ICMP = 1
  764.          Type:                    Address Mask Reply = AM2
  765.          Code:                    0
  766.          Mask:                    255.255.252.0
  767.  
  768.       In the diskless workstation case the host sends:
  769.  
  770.          Source address:          0.0.0.0
  771.          Destination address:     255.255.255.255
  772.          Protocol:                ICMP = 1
  773.          Type:                    Address Mask Request = AM1
  774.          Code:                    0
  775.          Mask:                    0
  776.  
  777.       128.99.4.62 will hear the datagram, and should respond with this
  778.       datagram:
  779.  
  780.          Source address:          128.99.4.62
  781.          Destination address:     255.255.255.255
  782.          Protocol:                ICMP = 1
  783.          Type:                    Address Mask Reply = AM2
  784.          Code:                    0
  785.          Mask:                    255.255.252.0
  786.  
  787.       If broadcasting is not allowed 128.99.4.123 sends:
  788.  
  789.          Source address:          128.99.4.123
  790.          Destination address:     128.99.4.62
  791.          Protocol:                ICMP = 1
  792.          Type:                    Address Mask Request = AM1
  793.          Code:                    0
  794.          Mask:                    0
  795.  
  796.       128.99.4.62 should respond exactly as in the previous case.
  797.  
  798.          Source address:          128.99.4.62
  799.          Destination address:     128.99.4.123
  800.          Protocol:                ICMP = 1
  801.          Type:                    Address Mask Reply = AM2
  802.          Code:                    0
  803.          Mask:                    255.255.252.0
  804.  
  805.  
  806.  
  807.  
  808. Mogul & Postel                                                 [Page 14]
  809.  
  810.  
  811.  
  812.  
  813. RFC 950                                                      August 1985
  814. Internet Standard Subnetting Procedure
  815.  
  816.  
  817.    3.  A Class C Network Case (illustrating non-contiguous subnet bits)
  818.  
  819.       For this case, assume that the requesting host is on class C
  820.       network 192.1.127.0, has address 192.1.127.19, that there is a
  821.       gateway at 192.1.127.50, and that on network an 3-bit subnet field
  822.       is in use (01011000), that is, the address mask is 255.255.255.88.
  823.  
  824.       The host sends the ICMP request to 255.255.255.255:
  825.  
  826.          Source address:          192.1.127.19
  827.          Destination address:     255.255.255.255
  828.          Protocol:                ICMP = 1
  829.          Type:                    Address Mask Request = AM1
  830.          Code:                    0
  831.          Mask:                    0
  832.  
  833.       The gateway can then respond directly to the requesting host.
  834.  
  835.          Source address:          192.1.127.50
  836.          Destination address:     192.1.127.19
  837.          Protocol:                ICMP = 1
  838.          Type:                    Address Mask Reply = AM2
  839.          Code:                    0
  840.          Mask:                    255.255.255.88.
  841.  
  842.       In the diskless workstation case the host sends:
  843.  
  844.          Source address:          0.0.0.0
  845.          Destination address:     255.255.255.255
  846.          Protocol:                ICMP = 1
  847.          Type:                    Address Mask Request = AM1
  848.          Code:                    0
  849.          Mask:                    0
  850.  
  851.       192.1.127.50 will hear the datagram, and should respond with this
  852.       datagram:
  853.  
  854.          Source address:          192.1.127.50
  855.          Destination address:     255.255.255.255
  856.          Protocol:                ICMP = 1
  857.          Type:                    Address Mask Reply = AM2
  858.          Code:                    0
  859.          Mask:                    255.255.255.88.
  860.  
  861.       If broadcasting is not allowed 192.1.127.19 sends:
  862.  
  863.  
  864.  
  865.  
  866. Mogul & Postel                                                 [Page 15]
  867.  
  868.  
  869.  
  870.  
  871. RFC 950                                                      August 1985
  872. Internet Standard Subnetting Procedure
  873.  
  874.  
  875.          Source address:          192.1.127.19
  876.          Destination address:     192.1.127.50
  877.          Protocol:                ICMP = 1
  878.          Type:                    Address Mask Request = AM1
  879.          Code:                    0
  880.          Mask:                    0
  881.  
  882.       192.1.127.50 should respond exactly as in the previous case.
  883.  
  884.          Source address:          192.1.127.50
  885.          Destination address:     192.1.127.19
  886.          Protocol:                ICMP = 1
  887.          Type:                    Address Mask Reply = AM2
  888.          Code:                    0
  889.          Mask:                    255.255.255.88
  890.  
  891. Appendix III.  Glossary
  892.  
  893.    Bridge
  894.  
  895.       A node connected to two or more administratively indistinguishable
  896.       but physically distinct subnets, that automatically forwards
  897.       datagrams when necessary, but whose existence is not known to
  898.       other hosts.  Also called a "software repeater".
  899.  
  900.    Gateway
  901.  
  902.       A node connected to two or more administratively distinct networks
  903.       and/or subnets, to which hosts send datagrams to be forwarded.
  904.  
  905.    Host Field
  906.  
  907.       The bit field in an Internet address used for denoting a specific
  908.       host.
  909.  
  910.    Internet
  911.  
  912.       The collection of connected networks using the IP protocol.
  913.  
  914.    Local Address
  915.  
  916.       The rest field of the Internet address (as defined in [3]).
  917.  
  918.    Network
  919.  
  920.       A single Internet network (which may or may not be divided into
  921.       subnets).
  922.  
  923.  
  924. Mogul & Postel                                                 [Page 16]
  925.  
  926.  
  927.  
  928.  
  929. RFC 950                                                      August 1985
  930. Internet Standard Subnetting Procedure
  931.  
  932.  
  933.    Network Number
  934.  
  935.       The network field of the Internet address.
  936.  
  937.    Subnet
  938.  
  939.       One or more physical networks forming a subset of an Internet
  940.       network.  A subnet is explicitly identified in the Internet
  941.       address.
  942.  
  943.    Subnet Field
  944.  
  945.       The bit field in an Internet address denoting the subnet number.
  946.       The bits making up this field are not necessarily contiguous in
  947.       the address.
  948.  
  949.    Subnet Number
  950.  
  951.       A number identifying a subnet within a network.
  952.  
  953. Appendix IV.  Assigned Numbers
  954.  
  955.    The following assignments are made for protocol parameters used in
  956.    the support of subnets.  The only assignments needed are for the
  957.    Internet Control Message Protocol (ICMP) [5].
  958.  
  959.    ICMP Message Types
  960.  
  961.       AM1 = 17
  962.  
  963.       AM2 = 18
  964.  
  965.  
  966.  
  967.  
  968.  
  969.  
  970.  
  971.  
  972.  
  973.  
  974.  
  975.  
  976.  
  977.  
  978.  
  979.  
  980.  
  981.  
  982. Mogul & Postel                                                 [Page 17]
  983.  
  984.  
  985.  
  986.  
  987. RFC 950                                                      August 1985
  988. Internet Standard Subnetting Procedure
  989.  
  990.  
  991. References
  992.  
  993.    [1]  Mogul, J., "Internet Subnets", RFC-917, Stanford University,
  994.         October 1984.
  995.  
  996.    [2]  Postel, J., "Multi-LAN Address Resolution", RFC-925,
  997.         USC/Information Sciences Institute, October 1984.
  998.  
  999.    [3]  Postel, J., "Internet Protocol", RFC-791, USC/Information
  1000.         Sciences Institute, September 1981.
  1001.  
  1002.    [4]  Finlayson, R., T. Mann, J. Mogul, M. Theimer, "A Reverse Address
  1003.         Resolution Protocol", RFC-903, Stanford University, June 1984.
  1004.  
  1005.    [5]  Postel, J., "Internet Control Message Protocol", RFC-792,
  1006.         USC/Information Sciences Institute, September 1981.
  1007.  
  1008.    [6]  Mogul, J., "Broadcasting Internet Datagrams", RFC-919, Stanford
  1009.         University, October 1984.
  1010.  
  1011.    [7]  GADS, "Towards an Internet Standard Scheme for Subnetting",
  1012.         RFC-940, Network Information Center, SRI International,
  1013.         April 1985.
  1014.  
  1015.    [8]  Croft, B., and J. Gilmore, "BOOTP -- UDP Bootstrap Protocol",
  1016.         RFC-951, Stanford University, August 1985.
  1017.  
  1018.    [9]  Reynolds, J., and J. Postel, "Assigned Numbers", RFC-943,
  1019.         USC/Information Sciences Institute, April 1985.
  1020.  
  1021.    
  1022.  
  1023.  
  1024.  
  1025.  
  1026.  
  1027.  
  1028.  
  1029.  
  1030.  
  1031.  
  1032.  
  1033.  
  1034.  
  1035.  
  1036.  
  1037.  
  1038.  
  1039.  
  1040. Mogul & Postel                                                 [Page 18]
  1041.  
  1042.  
  1043.  
  1044.  
  1045.