home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc0950.txt < prev    next >
Text File  |  1996-05-07  |  39KB  |  546 lines

  1.  
  2.  
  3. Network Working Group                                J. Mogul (Stanford) Request for Comments: 950                                J. Postel (ISI)                                                              August 1985 
  4.  
  5.                  Internet Standard Subnetting Procedure 
  6.  
  7.  Status Of This Memo 
  8.  
  9.    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. 
  10.  
  11. Overview 
  12.  
  13.    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]. 
  14.  
  15. Acknowledgment 
  16.  
  17.    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). 
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.  
  28.  
  29.  
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37. Mogul & Postel                                                  [Page 1] 
  38.  
  39.  
  40.  RFC 950                                                      August 1985 Internet Standard Subnetting Procedure 
  41.  
  42.  1.  Motivation 
  43.  
  44.    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. 
  45.  
  46.    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. 
  47.  
  48.    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. 
  49.  
  50.    There are several reasons why an organization might use more than one    cable to cover a campus: 
  51.  
  52.       - 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. 
  53.  
  54.       - 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. 
  55.  
  56.       - 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. 
  57.  
  58.       - 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. 
  59.  
  60.    An organization that has been forced to use more than one LAN has    three choices for assigning Internet addresses: 
  61.  
  62.  Mogul & Postel                                                  [Page 2] 
  63.  
  64.  
  65.  RFC 950                                                      August 1985 Internet Standard Subnetting Procedure 
  66.  
  67.        1. Acquire a distinct Internet network number for each cable;          subnets are not used at all. 
  68.  
  69.       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"). 
  70.  
  71.       3. Use a single network number, and partition the host address          space by assigning subnet numbers to the LANs ("explicit          subnets"). 
  72.  
  73.    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. 
  74.  
  75.    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. 
  76.  
  77.    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. 
  78.  
  79.    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. 
  80.  
  81.  Mogul & Postel                                                  [Page 3] 
  82.  
  83.  
  84.  RFC 950                                                      August 1985 Internet Standard Subnetting Procedure 
  85.  
  86.  2.  Standards for Subnet Addressing 
  87.  
  88.    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). 
  89.  
  90.    2.1. Interpretation of Internet Addresses 
  91.  
  92.       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: 
  93.  
  94.          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. 
  95.  
  96.          2. Fixed-width field:  A specific number of bits (e.g., eight)             is used for the subnet number, if subnets are in use. 
  97.  
  98.          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. 
  99.  
  100.          4. Self-encoding fixed-width field:  A specific number of bits             is used for the subnet number. 
  101.  
  102.          5. Masked bits:  Use a bit mask ("address mask") to identify             which bits of the local address field indicate the subnet             number. 
  103.  
  104.       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? 
  105.  
  106.          An interesting feature of self-encoding is that it allows the 
  107.  
  108.  
  109.  
  110.  Mogul & Postel                                                  [Page 4] 
  111.  
  112.  
  113.  RFC 950                                                      August 1985 Internet Standard Subnetting Procedure 
  114.  
  115.           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. 
  116.  
  117.             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. 
  118.  
  119.          To establish a subnetting standard the parameters and          interpretation of the self-encoding scheme must be fixed and          consistent throughout the Internet. 
  120.  
  121.          It could be assumed that all networks are subnetted.  This          would allow addresses to be interpreted without reference to          any other information. 
  122.  
  123.             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. 
  124.  
  125.          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. 
  126.  
  127.       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. 
  128.  
  129.  Mogul & Postel                                                  [Page 5] 
  130.  
  131.  
  132.  RFC 950                                                      August 1985 Internet Standard Subnetting Procedure 
  133.  
  134.        For example, the Internet address might be interpreted as: 
  135.  
  136.          <network-number><subnet-number><host-number> 
  137.  
  138.       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). 
  139.  
  140.       For example, on a Class B network with a 6-bit wide subnet field,       an address would be broken down like this: 
  141.  
  142.                            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    |       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  143.  
  144.       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. 
  145.  
  146.       Special Addresses: 
  147.  
  148.          From the Assigned Numbers memo [9]: 
  149.  
  150.             "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." 
  151.  
  152.          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. 
  153.  
  154.             In the example above, the 6-bit wide subnet field may have             any value except 0 and 63. 
  155.  
  156.  Mogul & Postel                                                  [Page 6] 
  157.  
  158.  
  159.  RFC 950                                                      August 1985 Internet Standard Subnetting Procedure 
  160.  
  161.           Please note that there is no effect or new restriction on the          addresses of hosts on non-subnetted networks. 
  162.  
  163.    2.2. Changes to Host Software to Support Subnets 
  164.  
  165.       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. 
  166.  
  167.       Generally the code is something like this: 
  168.  
  169.          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))) 
  170.  
  171.       (If the code supports multiply-connected networks, it will be more       complicated, but this is irrelevant to the current discussion.) 
  172.  
  173.       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. 
  174.  
  175.       The code then becomes: 
  176.  
  177.          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))) 
  178.  
  179.       Of course, part of the expression in the conditional can be       pre-computed. 
  180.  
  181.       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. 
  182.  
  183.       To support multiply-connected hosts, the code can be changed to 
  184.  
  185.  
  186.  
  187.  Mogul & Postel                                                  [Page 7] 
  188.  
  189.  
  190.  RFC 950                                                      August 1985 Internet Standard Subnetting Procedure 
  191.  
  192.        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. 
  193.  
  194.    2.3. Finding the Address Mask 
  195.  
  196.       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. 
  197.  
  198.       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. 
  199.  
  200.       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]. 
  201.  
  202.       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. 
  203.  
  204.       In the case where it is necessary for a host to find the address       mask as a separate operation the following mechanism is provided: 
  205.  
  206.          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. 
  207.  
  208.          The intended use of these new ICMP messages is that a host,          when booting, broadcast an "Address Mask Request" message.  A 
  209.  
  210.  Mogul & Postel                                                  [Page 8] 
  211.  
  212.  
  213.  RFC 950                                                      August 1985 Internet Standard Subnetting Procedure 
  214.  
  215.           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. 
  216.  
  217.          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. 
  218.  
  219.       If a host is connected to more than one LAN, it might have to find       the address mask for each. 
  220.  
  221.       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: 
  222.  
  223.          1. The local net exists in (permanent) isolation from all other             nets. 
  224.  
  225.          2. Subnets are not in use, and no host can supply the address             mask. 
  226.  
  227.          3. All gateways on the local net are (temporarily) down. 
  228.  
  229.       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. 
  230.  
  231.       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). 
  232.  
  233.  Mogul & Postel                                                  [Page 9] 
  234.  
  235.  
  236.  RFC 950                                                      August 1985 Internet Standard Subnetting Procedure 
  237.  
  238.  Appendix I.  Address Mask ICMP 
  239.  
  240.    Address Mask Request or Address Mask Reply 
  241.  
  242.        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                           |       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  243.  
  244.       IP Fields: 
  245.  
  246.          Addresses 
  247.  
  248.             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. 
  249.  
  250.       ICMP Fields: 
  251.  
  252.          Type 
  253.  
  254.             AM1 for address mask request message 
  255.  
  256.             AM2 for address mask reply message 
  257.  
  258.          Code 
  259.  
  260.             0 for address mask request message 
  261.  
  262.             0 for address mask reply message 
  263.  
  264.          Checksum 
  265.  
  266.             The checksum is the 16-bit one's complement of the one's 
  267.  
  268.  
  269.  
  270. Mogul & Postel                                                 [Page 10] 
  271.  
  272.  
  273.  RFC 950                                                      August 1985 Internet Standard Subnetting Procedure 
  274.  
  275.              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. 
  276.  
  277.          Identifier 
  278.  
  279.             An identifier to aid in matching requests and replies, may             be zero. 
  280.  
  281.          Sequence Number 
  282.  
  283.             A sequence number to aid in matching requests and replies,             may be zero. 
  284.  
  285.          Address Mask 
  286.  
  287.             A 32-bit mask. 
  288.  
  289.       Description 
  290.  
  291.          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. 
  292.  
  293.          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. 
  294.  
  295.             Type AM1 may be received from a gateway or a host. 
  296.  
  297.             Type AM2 may be received from a gateway, or a host acting in             lieu of a gateway. 
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309. Mogul & Postel                                                 [Page 11] 
  310.  
  311.  
  312.  RFC 950                                                      August 1985 Internet Standard Subnetting Procedure 
  313.  
  314.  Appendix II.  Examples 
  315.  
  316.    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]. 
  317.  
  318.    1.  A Class A Network Case 
  319.  
  320.       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. 
  321.  
  322.       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: 
  323.  
  324.          Source address:          36.40.0.123          Destination address:     255.255.255.255          Protocol:                ICMP = 1          Type:                    Address Mask Request = AM1          Code:                    0          Mask:                    0 
  325.  
  326.       The gateway can then respond directly to the requesting host. 
  327.  
  328.          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 
  329.  
  330.       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: 
  331.  
  332.          Source address:          0.0.0.0          Destination address:     255.255.255.255          Protocol:                ICMP = 1          Type:                    Address Mask Request = AM1          Code:                    0          Mask:                    0 
  333.  
  334.       36.40.0.62 will hear the datagram, and should respond with this       datagram: 
  335.  
  336.  Mogul & Postel                                                 [Page 12] 
  337.  
  338.  
  339.  RFC 950                                                      August 1985 Internet Standard Subnetting Procedure 
  340.  
  341.           Source address:          36.40.0.62          Destination address:     255.255.255.255          Protocol:                ICMP = 1          Type:                    Address Mask Reply = AM2          Code:                    0          Mask:                    255.255.0.0 
  342.  
  343.       Note that the gateway uses the narrowest possible broadcast to       reply.  Even so, the over use of broadcasts presents an       unnecessary load to all hosts on the subnet, and so the use of the       "anonymous" (0.0.0.0) source address must be kept to a minimum. 
  344.  
  345.       If broadcasting is not allowed, we assume that hosts have wired-in       information about neighbor gateways; thus, 36.40.0.123 might send       this datagram: 
  346.  
  347.          Source address:          36.40.0.123          Destination address:     36.40.0.62          Protocol:                ICMP = 1          Type:                    Address Mask Request = AM1          Code:                    0          Mask:                    0 
  348.  
  349.       36.40.0.62 should respond exactly as in the previous case. 
  350.  
  351.          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 
  352.  
  353.    2.  A Class B Network Case 
  354.  
  355.       For this case, assume that the requesting host is on class B       network 128.99.0.0, has address 128.99.4.123, that there is a       gateway at 128.99.4.62, and that a 6-bit wide subnet field is in       use, that is, the address mask is 255.255.252.0. 
  356.  
  357.       The host sends the ICMP request to 255.255.255.255: 
  358.  
  359.          Source address:          128.99.4.123          Destination address:     255.255.255.255          Protocol:                ICMP = 1          Type:                    Address Mask Request = AM1          Code:                    0          Mask:                    0 
  360.  
  361.  Mogul & Postel                                                 [Page 13] 
  362.  
  363.  
  364.  RFC 950                                                      August 1985 Internet Standard Subnetting Procedure 
  365.  
  366.        The gateway can then respond directly to the requesting host. 
  367.  
  368.          Source address:          128.99.4.62          Destination address:     128.99.4.123          Protocol:                ICMP = 1          Type:                    Address Mask Reply = AM2          Code:                    0          Mask:                    255.255.252.0 
  369.  
  370.       In the diskless workstation case the host sends: 
  371.  
  372.          Source address:          0.0.0.0          Destination address:     255.255.255.255          Protocol:                ICMP = 1          Type:                    Address Mask Request = AM1          Code:                    0          Mask:                    0 
  373.  
  374.       128.99.4.62 will hear the datagram, and should respond with this       datagram: 
  375.  
  376.          Source address:          128.99.4.62          Destination address:     255.255.255.255          Protocol:                ICMP = 1          Type:                    Address Mask Reply = AM2          Code:                    0          Mask:                    255.255.252.0 
  377.  
  378.       If broadcasting is not allowed 128.99.4.123 sends: 
  379.  
  380.          Source address:          128.99.4.123          Destination address:     128.99.4.62          Protocol:                ICMP = 1          Type:                    Address Mask Request = AM1          Code:                    0          Mask:                    0 
  381.  
  382.       128.99.4.62 should respond exactly as in the previous case. 
  383.  
  384.          Source address:          128.99.4.62          Destination address:     128.99.4.123          Protocol:                ICMP = 1          Type:                    Address Mask Reply = AM2          Code:                    0          Mask:                    255.255.252.0 
  385.  
  386.  
  387.  
  388.  Mogul & Postel                                                 [Page 14] 
  389.  
  390.  
  391.  RFC 950                                                      August 1985 Internet Standard Subnetting Procedure 
  392.  
  393.     3.  A Class C Network Case (illustrating non-contiguous subnet bits) 
  394.  
  395.       For this case, assume that the requesting host is on class C       network 192.1.127.0, has address 192.1.127.19, that there is a       gateway at 192.1.127.50, and that on network an 3-bit subnet field       is in use (01011000), that is, the address mask is 255.255.255.88. 
  396.  
  397.       The host sends the ICMP request to 255.255.255.255: 
  398.  
  399.          Source address:          192.1.127.19          Destination address:     255.255.255.255          Protocol:                ICMP = 1          Type:                    Address Mask Request = AM1          Code:                    0          Mask:                    0 
  400.  
  401.       The gateway can then respond directly to the requesting host. 
  402.  
  403.          Source address:          192.1.127.50          Destination address:     192.1.127.19          Protocol:                ICMP = 1          Type:                    Address Mask Reply = AM2          Code:                    0          Mask:                    255.255.255.88. 
  404.  
  405.       In the diskless workstation case the host sends: 
  406.  
  407.          Source address:          0.0.0.0          Destination address:     255.255.255.255          Protocol:                ICMP = 1          Type:                    Address Mask Request = AM1          Code:                    0          Mask:                    0 
  408.  
  409.       192.1.127.50 will hear the datagram, and should respond with this       datagram: 
  410.  
  411.          Source address:          192.1.127.50          Destination address:     255.255.255.255          Protocol:                ICMP = 1          Type:                    Address Mask Reply = AM2          Code:                    0          Mask:                    255.255.255.88. 
  412.  
  413.       If broadcasting is not allowed 192.1.127.19 sends: 
  414.  
  415.  
  416.  
  417.  Mogul & Postel                                                 [Page 15] 
  418.  
  419.  
  420.  RFC 950                                                      August 1985 Internet Standard Subnetting Procedure 
  421.  
  422.           Source address:          192.1.127.19          Destination address:     192.1.127.50          Protocol:                ICMP = 1          Type:                    Address Mask Request = AM1          Code:                    0          Mask:                    0 
  423.  
  424.       192.1.127.50 should respond exactly as in the previous case. 
  425.  
  426.          Source address:          192.1.127.50          Destination address:     192.1.127.19          Protocol:                ICMP = 1          Type:                    Address Mask Reply = AM2          Code:                    0          Mask:                    255.255.255.88 
  427.  
  428. Appendix III.  Glossary 
  429.  
  430.    Bridge 
  431.  
  432.       A node connected to two or more administratively indistinguishable       but physically distinct subnets, that automatically forwards       datagrams when necessary, but whose existence is not known to       other hosts.  Also called a "software repeater". 
  433.  
  434.    Gateway 
  435.  
  436.       A node connected to two or more administratively distinct networks       and/or subnets, to which hosts send datagrams to be forwarded. 
  437.  
  438.    Host Field 
  439.  
  440.       The bit field in an Internet address used for denoting a specific       host. 
  441.  
  442.    Internet 
  443.  
  444.       The collection of connected networks using the IP protocol. 
  445.  
  446.    Local Address 
  447.  
  448.       The rest field of the Internet address (as defined in [3]). 
  449.  
  450.    Network 
  451.  
  452.       A single Internet network (which may or may not be divided into       subnets). 
  453.  
  454.  Mogul & Postel                                                 [Page 16] 
  455.  
  456.  
  457.  RFC 950                                                      August 1985 Internet Standard Subnetting Procedure 
  458.  
  459.     Network Number 
  460.  
  461.       The network field of the Internet address. 
  462.  
  463.    Subnet 
  464.  
  465.       One or more physical networks forming a subset of an Internet       network.  A subnet is explicitly identified in the Internet       address. 
  466.  
  467.    Subnet Field 
  468.  
  469.       The bit field in an Internet address denoting the subnet number.       The bits making up this field are not necessarily contiguous in       the address. 
  470.  
  471.    Subnet Number 
  472.  
  473.       A number identifying a subnet within a network. 
  474.  
  475. Appendix IV.  Assigned Numbers 
  476.  
  477.    The following assignments are made for protocol parameters used in    the support of subnets.  The only assignments needed are for the    Internet Control Message Protocol (ICMP) [5]. 
  478.  
  479.    ICMP Message Types 
  480.  
  481.       AM1 = 17 
  482.  
  483.       AM2 = 18 
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  Mogul & Postel                                                 [Page 17] 
  502.  
  503.  
  504.  RFC 950                                                      August 1985 Internet Standard Subnetting Procedure 
  505.  
  506.  References 
  507.  
  508.    [1]  Mogul, J., "Internet Subnets", RFC-917, Stanford University,         October 1984. 
  509.  
  510.    [2]  Postel, J., "Multi-LAN Address Resolution", RFC-925,         USC/Information Sciences Institute, October 1984. 
  511.  
  512.    [3]  Postel, J., "Internet Protocol", RFC-791, USC/Information         Sciences Institute, September 1981. 
  513.  
  514.    [4]  Finlayson, R., T. Mann, J. Mogul, M. Theimer, "A Reverse Address         Resolution Protocol", RFC-903, Stanford University, June 1984. 
  515.  
  516.    [5]  Postel, J., "Internet Control Message Protocol", RFC-792,         USC/Information Sciences Institute, September 1981. 
  517.  
  518.    [6]  Mogul, J., "Broadcasting Internet Datagrams", RFC-919, Stanford         University, October 1984. 
  519.  
  520.    [7]  GADS, "Towards an Internet Standard Scheme for Subnetting",         RFC-940, Network Information Center, SRI International,         April 1985. 
  521.  
  522.    [8]  Croft, B., and J. Gilmore, "BOOTP -- UDP Bootstrap Protocol",         RFC-951, Stanford University, August 1985. 
  523.  
  524.    [9]  Reynolds, J., and J. Postel, "Assigned Numbers", RFC-943,         USC/Information Sciences Institute, April 1985. 
  525.  
  526.     
  527.  
  528.  
  529.  
  530.  
  531.  
  532.   
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544. Mogul & Postel                                                 [Page 18] 
  545.  
  546.