summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc917.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc917.txt')
-rw-r--r--doc/rfc/rfc917.txt1254
1 files changed, 1254 insertions, 0 deletions
diff --git a/doc/rfc/rfc917.txt b/doc/rfc/rfc917.txt
new file mode 100644
index 0000000..00749ee
--- /dev/null
+++ b/doc/rfc/rfc917.txt
@@ -0,0 +1,1254 @@
+
+
+Network Working Group Jeffrey Mogul
+Request for Comments: 917 Computer Science Department
+ Stanford University
+ October 1984
+
+ INTERNET SUBNETS
+
+
+Status Of This Memo
+
+ This RFC suggests a proposed protocol for the ARPA-Internet
+ community, and requests discussion and suggestions for improvements.
+ Distribution of this memo is unlimited.
+
+Overview
+
+ We discuss 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.
+
+ We propose procedures for the use of subnets, and discuss approaches
+ to solving the problems that arise, particularly that of routing.
+
+Acknowledgment
+
+ This proposal is the result of discussion with several other people.
+ J. Noel Chiappa, Chris Kent, and Tim Mann, in particular, provided
+ important suggestions.
+
+1. Introduction
+
+ The original view of the Internet universe was a two-level hierarchy:
+ the top level the catenet as a whole, and the level below it a
+ collection of "Internet Networks", each with its own Network Number.
+ (We do not mean that the Internet has a hierarchical topology, but
+ that the interpretation of addresses is hierarchical.)
+
+ 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 might (or might not) be divided into a collection of
+ subnets.
+
+ The original, two-level, view carries a strong presumption that, to a
+ host on an Internet network, that network may be viewed as a single
+ edge; to put it another way, the network may be treated as a "black
+ box" to which a set of hosts is connected. This is true of the
+
+
+
+
+Mogul [Page 1]
+
+
+
+RFC 917 October 1984
+Internet Subnets
+
+
+ ARPANET, because the IMPs mask the use of specific links in that
+ network. It is also true of most local area network (LAN)
+ technologies, such as Ethernet or ring networks.
+
+ However, this presumption fails in many practical cases, because in
+ moderately large organizations (e.g., Universities or companies with
+ more than one building) it is often necessary to use more than one
+ LAN cable to cover a "local area". For example, at this writing
+ there are eighteen such cables in use at Stanford University, with
+ more planned.
+
+ 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 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:
+
+ 1. Acquire a distinct Internet network number for each cable.
+
+ 2. Use a single network number for the entire organization, but
+ assign host numbers without regard to which LAN a host is on.
+ (We will call this choice "transparent subnets".)
+
+ 3. Use a single network number, and partition the host address
+ space by assigning subnet numbers to the LANs. ("Explicit
+ subnets".)
+
+
+Mogul [Page 2]
+
+
+
+RFC 917 October 1984
+Internet Subnets
+
+
+ Each of these approaches has disadvantages. The first, although not
+ requiring any new or modified protocols, does result 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 nice 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. 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 addresses the key problem: existing standards
+ assume that all hosts on an Internet local network are on a single
+ cable. The solution 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, we believe that these changes are relatively minor, and once
+ made, yield a simple and efficient solution to the problem. Also,
+ the approach we take in this document is to avoid 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 will be explained later. 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. Because of
+ this, there seems little reason to use the second approach listed
+ above.
+
+ The rest of this document describes approaches to subnets of Internet
+ Networks.
+
+
+
+
+
+
+Mogul [Page 3]
+
+
+
+RFC 917 October 1984
+Internet Subnets
+
+
+ 1.1. Terminology
+
+ To avoid either ambiguity or prolixity, we will define a few
+ terms, which will be used in the following sections:
+
+ Catenet
+
+ The collection of connected Internet Networks
+
+ Network
+
+ A single Internet network (that may or may not be divided into
+ subnets.)
+
+ Subnet
+
+ A subnet of an Internet network.
+
+ Network Number
+
+ As in [8].
+
+ Local Address
+
+ The bits in an Internet address not used for the network
+ number; also known as "rest field".
+
+ Subnet Number
+
+ A number identifying a subnet within a network.
+
+ Subnet Field
+
+ The bit field in an Internet address used for the subnet
+ number.
+
+ Host Field
+
+ The bit field in an Internet address used for denoting a
+ specific host.
+
+ Gateway
+
+ A node connected to two or more administratively distinct
+ networks and/or subnets, to which hosts send datagrams to be
+ forwarded.
+
+
+
+Mogul [Page 4]
+
+
+
+RFC 917 October 1984
+Internet Subnets
+
+
+ Bridge
+
+ A node connected to two or more administratively
+ indistinguishable but physically distinct subnets, that
+ automatically forwards datagrams when necessary, but whose
+ existence is not know to other hosts. Also called a "software
+ repeater".
+
+2. Standards for Subnet Addressing
+
+ Following the division presented in [2], we observe that subnets are
+ fundamentally an issue of addressing. In this section, we first
+ describe a proposal for interpretation of Internet Addressing to
+ support subnets. We then discuss the interaction between this
+ address format and broadcasting; finally, we present a protocol for
+ discovering what address interpretation is in use on a given network.
+
+ 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 is used for the subnet number. Subnets are in use if the
+ high-order bit of this field is one; otherwise, the entire
+ local address part is used for host number.
+
+ Since there seems to be no advantage in doing otherwise, all these
+ schemes place the subnet field as the most significant field in
+
+
+Mogul [Page 5]
+
+
+
+RFC 917 October 1984
+Internet Subnets
+
+
+ the local address part. Also, since the local address part of a
+ Class C address is so small, there is little reason to support
+ subnets of other than Class A and Class B networks.
+
+ What criteria can we use to choose one of these four schemes?
+ First, do we want to use a self-encoding scheme; that is, should
+ it be possible to tell from examining an Internet address if it
+ refers to a subnetted network, without reference to any other
+ information?
+
+ One advantage to self-encoding is that it allows one to determine
+ if a non-local network has been divided into subnets. It is not
+ clear that this would be of any use. The principle advantage,
+ however, is that 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 non-subnetted networks which have existing
+ host numbers that use arbitrary bits in the local address part
+ <1>. In other words, it is useful to be able control whether a
+ network is subnetted independently from the assignment of host
+ addresses. Another disadvantage of any self-encoding scheme is
+ that it reduces the local address space by at least a factor of
+ two.
+
+ If a self-encoding scheme is not used, it is clear that a
+ variable-width subnet field is appropriate. 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 (the subnet field
+ width) instead of a boolean is negligible. The advantage of using
+ a variable-width subnet field is that it allows each organization
+ to choose the best way to allocate relatively scarce bits of local
+ address to subnet and host numbers.
+
+ Our proposal, therefore, is that the Internet address be
+ interpreted as:
+
+ <network-number><subnet-number><host-number>
+
+ where the <network-number> field is as in [8], the <host-number>
+ field is at least one 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 [8] is
+ used.)
+
+
+
+
+Mogul [Page 6]
+
+
+
+RFC 917 October 1984
+Internet Subnets
+
+
+ For example, on a Class A network with an eight bit wide subnet
+ field, an address is 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0| NETWORK | SUBNET | Host number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ We expect that, for reasons of simplicity and efficient
+ implementation, that most organizations will choose a subnet field
+ width that is a multiple of eight bits. However, an
+ implementation must be prepared to handle other possible widths.
+
+ We reject the use of "recursive subnets", the division of the host
+ field into "sub-subnet" and host parts, because:
+
+ - There is no obvious need for a four-level hierarchy.
+
+ - The number of bits available in an IP address is not large
+ enough to make this useful in general.
+
+ - The extra mechanism required is complex.
+
+ 2.2. Changes to Host Software to Support Subnets
+
+ In most implementations of IP, there is code in the module that
+ handles outgoing packet that does something like:
+
+ IF ip_net_number(packet.ip_dest) = ip_net_number(my_ip_addr)
+ THEN
+ send_packet_locally(packet, packet.ip_dest)
+ ELSE
+ send_packet_locally(packet,
+ gateway_to(ip_net_number(packet.ip_dest)))
+
+ (If the code supports multiple connected networks, it will be more
+ complicated, but this is irrelevant to the current discussion.)
+
+ To support subnets, it is necessary to store one more 32-bit
+ quantity, called my_ip_mask. This is a bit-mask with bits set in
+ the fields corresponding to the IP network number, and additional
+ bits set corresponding to the subnet number field. For example,
+ on a Class A network using an eight-bit wide subnet field, the
+ mask would be 255.255.0.0.
+
+ The code then becomes:
+
+
+Mogul [Page 7]
+
+
+
+RFC 917 October 1984
+Internet Subnets
+
+
+ IF bitwise_and(packet.ip_dest, my_ip_mask)
+ = bitwise_and(my_ip_addr, my_ip_mask)
+ THEN
+ send_packet_locally(packet, packet.ip_dest)
+ ELSE
+ send_packet_locally(packet,
+ gateway_to(bitwise_and(packet.ip_dest, my_ip_mask)))
+
+ Of course, part of the expression in the conditionally can be
+ pre-computed.
+
+ It may or may not be necessary to modify the "gateway_to"
+ function, so that it performs comparisons in the same way.
+
+ To support multiply-connected hosts, the code can be changed to
+ keep the "my_ip_addr" and "my_ip_mask" quantities on a
+ per-interface basis; the expression in the conditional must then
+ be evaluated for each interface.
+
+ 2.3. Subnets and Broadcasting
+
+ In the absence of subnets, there are only two kinds of broadcast
+ possible within the Internet Protocol <2>: broadcast to all hosts
+ on a specific network, or broadcast to all hosts on "this
+ network"; the latter is useful when a host does not know what
+ network it is on.
+
+ When subnets are used, the situation becomes slightly more
+ complicated. First, the possibility now exists of broadcasting to
+ a specific subnet. Second, broadcasting to all the hosts on a
+ subnetted network requires additional mechanism; in [6] the use of
+ "Reverse Path Forwarding" [3] is proposed. Finally, the
+ interpretation of a broadcast to "this network" is that it should
+ not be forwarded outside of the original subnet.
+
+ Implementations must therefore recognize three kinds of broadcast
+ addresses, in addition to their own host addresses:
+
+ This physical network
+
+ A destination address of all ones (255.255.255.255) causes the
+ a datagram to be sent as a broadcast on the local physical
+ network; it must not be forwarded by any gateway.
+
+
+
+
+
+
+Mogul [Page 8]
+
+
+
+RFC 917 October 1984
+Internet Subnets
+
+
+ Specific network
+
+ The destination address contains a valid network number; the
+ local address part is all ones (e.g., 36.255.255.255).
+
+ Specific subnet
+
+ The destination address contains a valid network number and a
+ valid subnet number; the host field is all ones (e.g.,
+ 36.40.255.255).
+
+ For further discussion of Internet broadcasting, see [6].
+
+ One factor that may aid in deciding whether to use subnets is that
+ it is possible to broadcast to all hosts of a subnetted network
+ with a single operation at the originating host. It is not
+ possible to broadcast, in one step, to the same set of hosts if
+ they are on distinct networks.
+
+ 2.4. Determining the Width of the Subnet Field
+
+ How can a host (or gateway) determine what subnet field width is
+ in use on a network to which it is connected? The problem is
+ analogous to several other "bootstrapping" problems for Internet
+ hosts: how a host determines its own address, and how it locates a
+ gateway on its local network. In all three cases, there are two
+ basic solutions: "hardwired" information, and broadcast-based
+ protocols.
+
+ "Hardwired" information is that available to a host in isolation
+ from a network. It may be compiled-in, or (preferably) stored in
+ a disk file. However, for the increasingly common case of a
+ diskless workstation that is bootloaded over a LAN, neither
+ hard-wired solution is satisfactory. Instead, since most LAN
+ technology supports broadcasting, a better method is for the
+ newly-booted host to broadcast a request for the necessary
+ information. For example, for the purpose of determining its
+ Internet address, a host may use the "Reverse Address Resolution
+ Protocol" [4].
+
+ We propose to extend the ICMP protocol [9] by adding a new pair of
+ ICMP message types, "Address Format Request" and "Address Format
+ Reply", analogous to the "Information Request" and "Information
+ Reply" ICMP messages. These are described in detail in
+ Appendix I.
+
+ The intended use of these new ICMPs is that a host, when booting,
+
+
+Mogul [Page 9]
+
+
+
+RFC 917 October 1984
+Internet Subnets
+
+
+ broadcast an "Address Format Request" message <3>. A gateway (or
+ a host acting in lieu of a gateway) that receives this message
+ responds with an "Address Format 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 width of
+ the subnet field.
+
+ Since there is only one possible value that can be sent in an
+ "Address Format Reply" on any given LAN, there is no need for the
+ requesting host to match the responses it hears against the
+ request it sent; similarly, there is no problem if more than one
+ gateway responds. We assume that hosts reboot infrequently, so
+ the broadcast load on a network from use of this protocol should
+ be small.
+
+ If a host is connected to more than one LAN, it must use this
+ protocol on each, unless it can determine (from a response on one
+ of the LANs) that several of the LANs are part of the same
+ network, and thus must have the same subnet field width.
+
+ One potential problem is what a host should do if it receives no
+ response to its "Address Format Request", even after a reasonable
+ number of tries. Three interpretations can be placed on the
+ situation:
+
+ 1. The local net exists in (permanent) isolation from all other
+ nets.
+
+ 2. Subnets are not in use, and no host supports this ICMP
+ request.
+
+ 3. All gateways on the local net are (temporarily) down.
+
+ The first and second situations imply that the subnet field width
+ is zero. In the third situation, there is no way to determine
+ what the proper value is; the safest choice is thus zero.
+ 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 Format Reply"; when a
+ host receives such a message that disagrees with its guess, it
+ should adjust its data structures to conform to the received
+ value. No host or gateway should send an "Address Format Reply"
+ based on a "guessed" value.
+
+
+
+
+Mogul [Page 10]
+
+
+
+RFC 917 October 1984
+Internet Subnets
+
+
+ Finally, note that no host is required to use this ICMP protocol
+ to discover the subnet field width; it is perfectly reasonable for
+ a host with non-volatile storage to use stored information.
+
+3. Subnet Routing Methods
+
+ One problem that faces all Internet hosts is how to determine a route
+ to another host. In the presence of subnets, this problem is only
+ slightly modified.
+
+ The use of subnets means that there are two levels to the routing
+ process, instead of one. If the destination host is on the same
+ network as the source host, the routing decision involves only the
+ subnet gateways between the hosts. If the destination is on a
+ different network, then the routing decision requires the choice both
+ of a gateway out of the source host's network, and of a route within
+ the network to that gateway.
+
+ Fortunately, many hosts can ignore this distinction (and, in fact,
+ ignore all routing choices) by using a "default" gateway as the
+ initial route to all destinations, and relying on ICMP Host Redirect
+ messages to define more appropriate routes. However, this is not an
+ efficient method for a gateway or for a multi-homed host, since a
+ redirect may not make up for a poor initial choice of route. Such
+ hosts should use a routing information exchange protocol, but that is
+ beyond the scope of this document; in any case, the problem arises
+ even when subnets are not used.
+
+ The problem for a singly-connected host is thus to find at least one
+ neighbor gateway. Again, there are basic two solutions to this: use
+ hard-wired information, or use broadcasts. We believe that the
+ neighbor-gateway acquisition problem is the same with or without
+ subnets, and thus the choice of solution is not affected by the use
+ of subnets.
+
+ However, one problem remains: a source host must determine if
+ datagram to a given destination address must be sent via a gateway,
+ or sent directly to the destination host. In other words, is the
+ destination host on the same physical network as the source? This
+ particular phase of the routing process is the only one that requires
+ an implementation to be explicitly aware of subnets; in fact, if
+ broadcasts are not used, it is the only place where an Internet
+ implementation must be modified to support subnets.
+
+ Because of this, it is possible to use some existing implementations
+ without modification in the presence of subnets <4>. For this to
+ work, such implementations must:
+
+
+Mogul [Page 11]
+
+
+
+RFC 917 October 1984
+Internet Subnets
+
+
+ - Be used only on singly-homed hosts, and not as a gateway.
+
+ - Be used on a broadcast LAN.
+
+ - Use an Address Resolution Protocol (ARP), such [7].
+
+ - Not be required to maintain connections in the case of gateway
+ crashes.
+
+ In this case, one can modify the ARP server module in a subnet
+ gateway so that when it receives an ARP request, it checks the target
+ Internet address to see if it is along the best route to the target.
+ If it is, it sends to the requesting host an ARP response indicating
+ its own hardware address. The requesting host thus believes that it
+ knows the hardware address of the destination host, and sends packets
+ to that address. In fact, the packets are received by the gateway,
+ and forwarded to the destination host by the usual means.
+
+ This method requires some blurring of the layers in the gateways,
+ since the ARP server and the Internet routing table would normally
+ not have any contact. In this respect, it is somewhat
+ unsatisfactory. Still, it is fairly easy to implement, and does not
+ have significant performance costs. One problem is that if the
+ original gateway crashes, there is no way for the source host to
+ choose an alternate route even if one exists; thus, a connection that
+ might otherwise have been maintained will be broken.
+
+ One should not confuse this method of "ARP-based subnetting" with the
+ superficially similar use of ARP-based bridges. ARP-based subnetting
+ is based on the ability of a gateway to examine an IP address and
+ deduce a route to the destination, based on explicit subnet topology.
+ In other words, a small part of the routing decision has been moved
+ from the source host into the gateway. An ARP-based bridge, in
+ contrast, must somehow locate each host without any assistance from a
+ mapping between host address and topology. Systems built out of
+ ARP-based bridges should not be referred to as "subnetted".
+
+ N.B.: the use of ARP-based subnetting is complicated by the use of
+ broadcasts. An ARP server [7] should never respond to a request
+ whose target is a broadcast address. Such a request can only come
+ from a host that does not recognize the broadcast address as such,
+ and so honoring it would almost certainly lead to a forwarding loop.
+ If there are N such hosts on the physical network that do not
+ recognize this address as a broadcast, then a packet sent with a
+ Time-To-Live of T could potentially give rise to T**N spurious
+ re-broadcasts.
+
+
+
+Mogul [Page 12]
+
+
+
+RFC 917 October 1984
+Internet Subnets
+
+
+4. Case Studies
+
+ In this section, we briefly sketch how subnets have been used by
+ several organizations.
+
+ 4.1. Stanford University
+
+ At Stanford, subnets were introduced initially for historical
+ reasons. Stanford had been using the Pup protocols [1] on a
+ collection of several Experimental Ethernets [5] since 1979,
+ several years before Internet protocols came into use. There were
+ a number of Pup gateways in service, and all hosts and gateways
+ acquired and exchanged routing table information using a simple
+ broadcast protocol.
+
+ When the Internet Protocol was introduced, the decision was made
+ to use an eight-bit wide subnet number; Internet subnet numbers
+ were chosen to match the Pup network number of a given Ethernet,
+ and the Pup host numbers (also eight bits) were used as the host
+ field of the Internet address.
+
+ The Pup-only gateways were then modified to forward Internet
+ datagrams according to their Pup routing tables; they otherwise
+ had no understanding of Internet packets and in fact did not
+ adjust the Time-to-live field in the Internet header. This seems
+ to be acceptable, since bugs that caused forwarding loops have not
+ appeared. The Internet hosts that are multi-homed and thus can
+ serve as gateways do adjust the Time-to-live field; since all of
+ the currently also serve as Pup gateways, no additional routing
+ information exchange protocol was needed.
+
+ Internet host implementations were modified to understand subnets
+ (in several different ways, but with identical effects). Since
+ all already had Pup implementations, the Internet routing tables
+ were maintained by the same process that maintained the Pup
+ routing tables, simply translating the Pup network numbers into
+ Internet subnet numbers.
+
+ When 10Mbit Ethernets were added, the gateways were modified to
+ use the ARP-based scheme described in an earlier section; this
+ allowed unmodified hosts to be used on the 10Mbit Ethernets.
+
+ IP subnets have been in use since early 1982; currently, there are
+ about 330 hosts, 18 subnets, and a similar number of subnet
+ gateways in service. Once the Pup-only gateways are converted to
+ be true Internet gateways, an Internet-based routing exchange
+ protocol will be introduced, and Pup will be phased out.
+
+
+Mogul [Page 13]
+
+
+
+RFC 917 October 1984
+Internet Subnets
+
+
+ 4.2. MIT
+
+ MIT was the first IP site to accumulate a large collection of
+ local network links. Since this happened before network numbers
+ were divided into classes, to have assigned each link at MIT its
+ own IP network number would have used up a good portion of the
+ available address space. MIT decided to use one IP network
+ number, and to manage the 24-bit "rest" field itself, by dividing
+ it into three 8-bit fields; "subnet", "reserved, must be zero",
+ and "host". Since the CHAOS protocol already in use at MIT used
+ an 8-bit subnet number field, it was possible to assign each link
+ the same subnet number in both protocols. The IP host field was
+ set to 8 bits since most available local net hardware at that
+ point used 8 bit addresses, as did the CHAOS protocol; it was felt
+ that reserving some bits for the future was wise.
+
+ The initial plan was to use a dynamic routing protocol between the
+ IP subnet gateways; several such protocols have been mooted but
+ nobody has bothered to implement one; static routing tables are
+ still used. It is likely that this change will finally be made
+ soon.
+
+ To solve the problem that imported IP software always needed
+ modification to work in the subnetted environment, MIT searched
+ for a model of operation that led to the least change in host IP
+ software. This led to a model where IP gateways send ICMP Host
+ Redirects rather than Network Redirects. All internal MIT IP
+ gateways now do so. With hosts that can maintain IP routing
+ tables for non-local communication on a per host basis, this hides
+ most of the subnet structure. The "minimum adjustment" for host
+ software to work correctly in both subnetted and non-subnetted
+ environments is the bit-mask algorithm mentioned earlier.
+
+ MIT has no immediate plans to move toward a single "approved"
+ protocol; this is due partly to the degree of local autonomy and
+ the amount of installed software, and partly to the lack of a
+ single prominent industry standard. Rather, the approach taken
+ has been to provide a single set of physical links and packet
+ switches, and to layer several "virtual" protocol nets atop the
+ single set of links. MIT has had some bad experiences with trying
+ to exchange routing information between protocols and wrap one
+ protocol in another; the general approach is to keep the protocols
+ strictly separated except for sharing the basic hardware. Using
+ ARP to hide the subnet structure is not much in favor; it is felt
+ that this overloads the address resolution operation. In a
+ complicated system (i.e. one with loops, and variant link speeds),
+
+
+
+Mogul [Page 14]
+
+
+
+RFC 917 October 1984
+Internet Subnets
+
+
+ a more sophisticated information interchange will be needed
+ between gateways; making this an explicit mechanism (but one
+ insulated from the hosts) was felt to be best.
+
+ 4.3. Carnegie-Mellon University
+
+ CMU uses a Class B network currently divided into 11 physical
+ subnets (two 3Mbit Experimental Ethernets, seven 10Mbit Ethernets,
+ and two ProNet rings.) Although host numbers are assigned so that
+ all addresses with a given third octet will be on the same subnet
+ (but not necessarily vice versa), this is essentially an
+ administrative convenience. No software currently knows the
+ specifics of this allocation mechanism or depends on it to route
+ between cables.
+
+ Instead, an ARP-based bridge scheme is used. When a host
+ broadcasts an ARP request, all bridges which receive it cache the
+ original protocol address mapping and then forward the request
+ (after the appropriate adjustments) as an ARP broadcast request
+ onto each of their other connected cables. When a bridge receives
+ a non-broadcast ARP reply with a target protocol address not its
+ own, it consults its ARP cache to determine the cable onto which
+ the reply should be forwarded. The bridges thus attempt to
+ transparently extend the ARP protocol into a heterogenous
+ multi-cable environment. They are therefore required to turn ARP
+ broadcasts on a single cable into ARP broadcasts on all other
+ connected cables even when they "know better". This algorithm
+ works only in the absence of cycles in the network connectivity
+ graph (which is currently the case). Work is underway to replace
+ this simple-minded algorithm with a protocol implemented among the
+ bridges, in support of redundant paths and to reduce the
+ collective broadcast load. The intent is to retain the ARP base
+ and host transparency, if possible.
+
+ Implementations supporting the 3Mbit Ethernet and 10Mb proNET ring
+ at CMU use RFC-826 ARP (instead of some wired-in mapping such as
+ simply using the 8-bit hardware address as the the fourth octet of
+ the IP address).
+
+ Since there are currently no redundant paths between cables, the
+ issue of maintaining connections across bridge crashes is moot.
+ With about 150 IP-capable hosts on the net, the bridge caches are
+ still of reasonable size, and little bandwidth is devoted to ARP
+ broadcast forwarding.
+
+ CMU's network is likely to grow from its relatively small,
+ singly-connected configuration centered within their CS/RI
+
+
+Mogul [Page 15]
+
+
+
+RFC 917 October 1984
+Internet Subnets
+
+
+ facility to a campus-wide intra-departmental configuration with
+ 5000-10000 hosts and redundant connections between cables. It is
+ possible that the ARP-based bridge scheme will not scale to this
+ size, and a system of explicit subnets may be required. The
+ medium-term goal, however, is an environment into which unmodified
+ extant (especially 10Mb ethernet based) IP implementations can be
+ imported; the intent is to stay with a host-transparent (thus
+ ARP-based) routing mechanism as long as possible. CMU is
+ concerned that even if subnets become part of the IP standard they
+ will not be widely implemented; this is the major obstacle to
+ their use at CMU.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mogul [Page 16]
+
+
+
+RFC 917 October 1984
+Internet Subnets
+
+
+I. Address Format ICMP
+
+ Address Format Request or Address Format Reply
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Code | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identifier | Sequence Number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ IP Fields:
+
+ Addresses
+
+ The address of the source in an address format request
+ message will be the destination of the address format reply
+ message. To form an address format 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 A2, the
+ subnet field width inserted into the Code field, and the
+ checksum recomputed. However, if the source address in the
+ request message is zero, then the destination address for
+ the reply message should denote a broadcast.
+
+ ICMP Fields:
+
+ Type
+
+ A1 for address format request message
+
+ A2 for address format reply message
+
+ Code
+
+ 0 for address format request message
+
+ Width of subnet field, in bits, for address format reply
+ message
+
+ Checksum
+
+ The checksum is the 16-bit one's complement of the one's
+
+
+
+
+Mogul [Page 17]
+
+
+
+RFC 917 October 1984
+Internet Subnets
+
+
+ complement sum of the ICMP message starting with the ICMP
+ Type. For computing the checksum, the checksum field should
+ be zero. This checksum may be replaced in the future.
+
+ Identifier
+
+ An identifier to aid in matching request and replies, may be
+ zero.
+
+ Sequence Number
+
+ A sequence number to aid in matching request and replies,
+ may be zero.
+
+ Description
+
+ A gateway receiving an address format request should return it
+ with the Code field set to the number of bits of Subnet number
+ in IP addresses for the network to which the datagram was
+ addressed. If the request was broadcast, the destination
+ network is "this network". The Subnet field width may be from
+ 0 to (31 - N), where N is the width in bits of the IP net
+ number field (i.e., 8, 16, or 24).
+
+ If the requesting host does not know its own IP address, it may
+ leave the source field zero; the reply should then be
+ broadcast. Since there is only one possible address format for
+ a network, there is no need to match requests with replies.
+ However, this approach should be avoided if at all possible,
+ since it increases the superfluous broadcast load on the
+ network.
+
+ Type A1 may be received from a gateway or a host.
+
+ Type A2 may be received from a gateway, or a host acting in
+ lieu of a gateway.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mogul [Page 18]
+
+
+
+RFC 917 October 1984
+Internet Subnets
+
+
+II. Examples
+
+ For these examples, we assume that the requesting host has address
+ 36.40.0.123, that there is a gateway at 36.40.0.62, and that on
+ network 36.0.0.0, an 8-bit wide subnet field is in use.
+
+ First, suppose that broadcasting is allowed, and that 36.40.0.123
+ knows its own address. It sends the following datagram:
+
+ Source address: 36.40.0.123
+ Destination address: 36.255.255.255
+ Protocol: ICMP = 1
+ Type: Address Format Request = A1
+ Code: 0
+
+ 36.40.0.62 will hear the datagram, and should respond with this
+ datagram:
+
+ Source address: 36.40.0.62
+ Destination address: 36.40.0.123
+ Protocol: ICMP = 1
+ Type: Address Format Reply = A2
+ Code: 8
+
+ For the following examples, assume that address 255.255.255.255
+ denotes "broadcast to this physical network", as described in [6].
+
+ The previous example is inefficient, because it potentially
+ broadcasts the request on many subnets. The most efficient method,
+ and the one we recommend, is for a host to first discover its own
+ address (perhaps using the "Reverse ARP" protocol described in [4]),
+ and then to send the ICMP request to 255.255.255.255:
+
+ Source address: 36.40.0.123
+ Destination address: 255.255.255.255
+ Protocol: ICMP = 1
+ Type: Address Format Request = A1
+ Code: 0
+
+ The gateway can then respond directly to the requesting host.
+
+ 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:
+
+
+
+
+
+
+Mogul [Page 19]
+
+
+
+RFC 917 October 1984
+Internet Subnets
+
+
+ Source address: 0.0.0.0
+ Destination address: 255.255.255.255
+ Protocol: ICMP = 1
+ Type: Address Format Request = A1
+ Code: 0
+
+ 36.40.0.62 will hear the datagram, and should respond with this
+ datagram:
+
+ Source address: 36.40.0.62
+ Destination address: 36.40.255.255
+ Protocol: ICMP = 1
+ Type: Address Format Reply = A2
+ Code: 8
+
+ Note that the gateway uses the narrowest possible broadcast to reply
+ (i.e., sending the reply to 36.255.255.255 would mean that it is
+ transmitted on many subnets, not just the one on which it is needed.)
+ Even so, the overuse of broadcasts presents an unnecessary load to
+ all hosts on the subnet, and so we recommend that use of the
+ "anonymous" (0.0.0.0) source address be kept to a minimum.
+
+ 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:
+
+ Source address: 36.40.0.123
+ Destination address: 36.40.0.62
+ Protocol: ICMP = 1
+ Type: Address Format Request = A1
+ Code: 0
+
+ 36.40.0.62 should respond exactly as in the previous case.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mogul [Page 20]
+
+
+
+RFC 917 October 1984
+Internet Subnets
+
+
+Notes
+
+ <1> For example, some host have addresses assigned by concatenating
+ their Class A network number with the low-order 24 bits of a
+ 48-bit Ethernet hardware address.
+
+ <2> Our discussion of Internet broadcasting is based on [6].
+
+ <3> If broadcasting is not supported, them presumably a host "knows"
+ the address of a neighbor gateway, and should send the ICMP to
+ that gateway.
+
+ <4> This is what was referred to earlier as the coexistence of
+ transparent and explicit subnets on a single network.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mogul [Page 21]
+
+
+
+RFC 917 October 1984
+Internet Subnets
+
+
+References
+
+ 1. D.R. Boggs, J.F. Shoch, E.A. Taft, and R.M. Metcalfe. "Pup: An
+ Internetwork Architecture." IEEE Transactions on Communications
+ COM-28, 4, pp612-624, April 1980.
+
+ 2. David D. Clark. Names, Addresses, Ports, and Routes. RFC-814,
+ MIT-LCS, July 1982.
+
+ 3. Yogan K. Dalal and Robert M. Metcalfe. "Reverse Path Forwarding
+ of Broadcast Packets." Comm. ACM 21, 12, pp1040-1048, December
+ 1978.
+
+ 4. Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer. A
+ Reverse Address Resolution Protocol. RFC-903, Stanford
+ University, June 1984.
+
+ 5. R.M. Metcalfe and D.R. Boggs. "Ethernet: Distributed Packet
+ Switching for Local Computer Networks." Comm. ACM 19, 7,
+ pp395-404, July 1976. Also CSL-75-7, Xerox Palo Alto Research
+ Center, reprinted in CSL-80-2.
+
+ 6. Jeffrey Mogul. Broadcasting Internet Datagrams. RFC-919, Stanford
+ University, October 1984.
+
+ 7. David Plummer. An Ethernet Address Resolution Protocol. RFC-826,
+ Symbolics, September 1982.
+
+ 8. Jon Postel. Internet Protocol. RFC-791, USC-ISI, September 1981.
+
+ 9. Jon Postel. Internet Control Message Protocol. RFC-792, USC-ISI,
+ September 1981.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mogul [Page 22]
+