Another Internet subnet addressing scheme
RFC 936

Document Type RFC - Unknown (February 1985; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 936 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                  Michael J. Karels
Request for Comments: 936                                    UC Berkeley
                                                           February 1985

               Another Internet Subnet Addressing Scheme

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.


   There have been several proposals for schemes to allow the use of a
   single Internet network number to refer to a collection of physical
   networks under common administration which are reachable from the
   rest of the Internet by a common route.  Such schemes allow a
   simplified view of an otherwise complicated topology from hosts and
   gateways outside of this collection.  They allow the complexity of
   the number and  type of these networks, and routing to them, to be
   localized.  Additions and changes in configuration thus cause no
   detectable change, and no interruption of service, due to slow
   propagation of routing and other information outside of the local
   environment.  These schemes also simplify the administration of the
   network, as changes do not require allocation of new network numbers
   for each new cable installed.  The motivation for explicit or
   implicit subnets, several of the alternatives, and descriptions of
   existing implementations of this type have been described in detail
   [1,2].  This proposal discusses an alternative scheme, one that has
   been in use at the University of California, Berkeley since
   April 1984.

Subnet Addressing at Berkeley

   As in the proposal by Jeff Mogul in RFC-917, the Berkeley subnet
   addressing utilizes encoding of the host part of the Internet
   address.  Hosts and gateways on the local network are able to
   determine the subnet number from each local address, and then route
   local packets based on the subnet number.  Logically, the collection
   of subnets appears to external sites to be a single, homogenous
   network.  Internally, however, each subnet is distinguished from the
   others and from other networks, and internal routing decisions are
   based on the subnet rather than the network number.

   The encoding of subnet addresses is similar to that proposed in
   RFC-917.  In decomposing an Internet address into the network and
   host parts, the algorithm is modified if the network is "local", that
   is, if the network is a directly-connected network under local
   administrative control.  (Networks are marked as local or non-local

Karels                                                          [Page 1]

RFC 936                                                    February 1985
Another Internet Subnet Addressing Scheme

   at the time each network interface's address is set at boot time.)
   For local addresses, the host part is examined for a subnet number.
   Local addresses may be on the main network, or they may be on a
   subnet.  The high-order bit of the host number is used to distinguish
   between subnets and the main net.  If the high-order bit of the host
   field is set, then the remainder of the high-order byte of the host
   part is taken to be the subnet number.  If the high-order bit is
   clear, then the address is interpreted in the normal fashion.  For
   Class A networks, using 8-bit subnet fields, this allows a network
   with up to 127 subnets, each of 65535 hosts maximum, and a main net
   with 2^23 hosts.  Class B nets may include 127 subnets, each of up to
   255 hosts, and 32767 hosts on the main net.  Class C networks are not
   currently included in this scheme. They might be reasonably be added,
   using four bits of the host part for a subnet desgination and four
   bits for the host, allowing 8 subnets of 15 hosts and 126 hosts on
   the main net.

   The current implementation does not use subnet numbers separately
   from the network field, but instead treats the subnet field as an
   extension of the network field.  Functions that previously returned
   the network number from an address now return a network or
   network-subnetwork number.  Conveniently, Class A subnets are
   distinguishable from Class B networks, although each is a 16-bit
   quantity, and Class B subnets are disjoint with Class C network
   numbers.  The net result is that subnets appear to be separate,
   independent networks with their own routing entries within the
   network, but outside of the network, they are invisible.  There is no
   current facility at Berkeley for broadcasting on the logical network;
   broadcasting may be done on each subnet that uses harware capable of


   There have been several earlier proposals for methods of allowing
   several physical networks to share an Internet network designation,
   and to provide routing within this logical network.  RFC-917 proposes
Show full document text