Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rochester!cornell!gvax!jqj
From: jqj@gvax.cs.cornell.edu (J Q Johnson)
Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip
Subject: Re: Multiple netmasks
Message-ID: <948@gvax.cs.cornell.edu>
Date: Wed, 29-Jul-87 14:12:31 EDT
Article-I.D.: gvax.948
Posted: Wed Jul 29 14:12:31 1987
Date-Received: Fri, 31-Jul-87 05:03:33 EDT
References: <12107@hi.UUCP>
Reply-To: jqj@gvax.cs.cornell.edu (J Q Johnson)
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 41
Xref: mnetor comp.dcom.lans:698 comp.protocols.tcp-ip:748

In article <12107@hi.UUCP> kurt@hi.UUCP (Kurt Zeilenga) proposes that
subnet routing be modified.  His proposal, slightly cleaned up, is
that:  When sending or forwarding to an IP address on a "local" subnetted
network (i.e. one for which the system has a directly connected interface),
the subnet mask should NOT be used directly to determine routing.  Instead,
it should be used to mask off a field of the destination IP address, then
that field should be used in a table lookup to determine the netmask to
use in examining the routing tables.

Thus, if net 128.84.0.0 is subnetted into 1 subnet with 16K hosts, 8
subnets with 4K hosts each, plus 1023 subnets with 255 hosts each,
the administrators of 128.84.0.0 could legislate that addresses
with the 2 highest bits of the third octet set to 0 would be
interpreted as 16 bits of net, 8 bits of subnet, and 8 bits of host,
while having both of those bits set would be interpreted as 2 bits of
subnet and 14 bits of host, and the rest would be interpreted as 4 bits
of subnet and 12 bits of host.  The table he proposes might have:

# subnet index mask is 0x0000c000
# network	index value	subnet mask
128.84.0.0	0x0000c000	0xffffc000
128.84.0.0	0x00008000	0xfffff000
128.84.0.0	0x00004000	0xfffff000
128.84.0.0	0x00000000	0xffffff00

It seems to me that this scheme would work, although at this point it
is unlikely ever to be adopted by the community as a standard.  The major
problems with it are (1) it is quite complex to administer [I spent 15
minutes constructing the above example, and am not confident I got it
right], and (2) it requires that every host that does routing know how
the network is broken into subnets (such hosts currently need to know
this information, but it consists of only a single number, the subnetmask).

Problem (2) is the serious one:  almost all host implementations would have
to be changed.  Given the problems we've had in getting vendors to support
the current subnetting scheme, it seems very unlikely that they would change
to support such a new scheme.

This raises the question of whether there is any less radical way to support
variable sized subnets, perhaps a solution that involves changing the code
only in gateways.  Anyone have any ideas?