From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc917.txt | 1254 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1254 insertions(+) create mode 100644 doc/rfc/rfc917.txt (limited to 'doc/rfc/rfc917.txt') 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: + + + + where the field is as in [8], the + field is at least one bit wide, and the width of the + field is constant for a given network. No further + structure is required for the or + fields. If the width of the 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] + -- cgit v1.2.3