[comp.protocols.tcp-ip] subnet IP mask stored in route or interface struct?

dennis@rlgvax.UUCP (Dennis.Bednar) (08/03/88)

Does 4.3BSD store the IP subnet mask in the route structure
(struct rtentry) or the interface structure (struct ifnet)?
The reason I ask, is that RFC 950 suggests that it be stored
on a per interface basis.  However, I have found a particular
case (described below), in which it is better to store the mask
on a per route basis.  Perhaps the example I have contrived
violates an unmentioned assumption that subnets in the same
network should be adjacent.

In the figure below, the ---- lines represent a single physical
ethernet cable. Gw1, and gw2 stand for gateway 1 and gateway 2.
Both gw1 and gw2 below have multi-homed IP addresses (that is two
separate home addresses, one for each network connection).
In the figure below, subnet1 and subnet2 (in the same network)
are separated apart by a different network, consisting of just
a single subnet. Subnet 1 and 2 below are class C network addresses
containing 3 bytes of <network-number>, and 4 bits for the <subnet-number>.
The network in the middle is a class B network composed of 2 bytes
of <network-number>, and 4 bits for the <subnet-number>.

			    gw1		    gw2
	--------------------	------------	------------------
Name	subnet1			network		subnet2
Number	192.7.8.0x10		128.5.0x10	192.7.8.0x20
IPmask	255.255.255.0xf0	255.255.0xf0.0	255.255.255.0xf0

The problem with using the IP mask for an interface is that
gw2 above will have trouble forwarding packets destined for hosts
in subnet1.  Suppose there is packet destined for host
192.7.8.0x11.  I will show the problem after giving some
background information.

------ Begin of some background information:

There is presumed to be 3 tables of routing table structures
containing
	<destination,	gateway,	flags, interface-ptr>.
These 3 tables are the host routing table, the subnet routing
table, and the network routing table.  Destination is the
IP address of a host (if in host routing table), of a subnet
(if in subnet routing table), or of a network (if in netowrk
routing table). The flag indicates if the route is direct (ie
through a local gateway or the home machine) or indirect thru
a remote gateway (ie the flag is used instead of the
recommended algorithm described in RFC950 to decide if the
packet should be sent directly or thru a gateway).  The interface
pointed to by interface-ptr is presumed to contain (at a minimum):
	< my_ip_addr,	my_ip_mask>

The 3 tables are searched in this order: host, subnet, network, using
the dg.ip_dest as a key into the route.destination field.  For a
host table search, all 4-bytes are compared.  The subnet table search
is described separately below.  The network table search compares
ip_network_of(dg.ip_dest) with route.destination. The search stops
when a route has been found. The subnet table search is this:

	for each subnet routing table entry
		if (route.dest == (dg.ip_dest & route.interface.my_ip_mask))
			{
			found = routing table entry;
			break;	/* stop table search */
			}

Once the route has been found, the route.flag tells whether to send
directly or through a gateway, as opposed to the recommended algorithm
described in RFC950.

---- end of background information

Now here is the problem: the subnet table search on gw2 above will
fail to locate the route entry in its subnet table, because the ip_mask
will strip off too many bits (2.5 bytes) causing the compare of
route.destination in the subnet table to fail:
	if (192.7.8.0x10 == (192.7.8.0x11 & 255.255.0xf0.0))
	if (192.7.8.0x10 == (192.7.0.0))

I would like to point out that by storing an IP mask on a per route
basis, this problem would go away, since the IP mask would be correct
for the destination subnet, which is remote to this particular network.

I would appreciate any comments on this matter.
-- 
FullName:	Dennis Bednar
UUCP:		{uunet|sundc}!rlgvax!dennis
USMail:		CCI; 11490 Commerce Park Dr.; Reston VA 22091
Telephone:	+1 703 648 3300

mogul@DECWRL.DEC.COM (Jeffrey Mogul) (08/04/88)

Dennis Bednar (decwrl!sun!pitstop!sundc!rlgvax!dennis) asks:
    Does 4.3BSD store the IP subnet mask in the route structure
    (struct rtentry) or the interface structure (struct ifnet)?
    The reason I ask, is that RFC 950 suggests that it be stored
    on a per interface basis.  However, I have found a particular
    case (described below), in which it is better to store the mask
    on a per route basis.  Perhaps the example I have contrived
    violates an unmentioned assumption that subnets in the same
    network should be adjacent.

Yes, but this is not so much an "unmentioned assumption" as it is
a rule that is not stated in the most obvious place.  As an author
of RFC950, I suppose I must take the blame for not repeating in
RFC950 this statement from the first page of RFC940:

   The use of subnets is an optional local decision.  The fact that a
   network has subnets is invisible outside that network, and the change
   is local and can be instituted at a site without any global Internet
   perturbations.  A complex of links is assigned a single IP network
   number, and outside that complex it appears as a single network with
   that number.  Only inside does local structure appear.

[Note that the first paragraph of RFC950 says, in effect, "read RFC940."]

Following this rule, the "particular case" is in violation:

	    --------------------gw1----------------gw2------------------
    Name	subnet1			network		subnet2
    Number	192.7.8.0x10		128.5.0x10	192.7.8.0x20

because the distinction between subnet1 and subnet2 would have to be
visible outside network 192.7.8.0 in order for things to work.

Solutions: Use different Class C numbers for the two isolated pieces,
or tie them together with a gateway connected to both subnets.  The latter
solution is less likely to fill up other people's routing tables.

jas@proteon.COM (John A. Shriver) (08/04/88)

Your configuration is illegal per RFC 1009.  To quote:

         The interconnected LANs of an organization will be given the
         same network number but different subnet numbers.  The
         distinction between the subnets of such a subnetted network
         must not be visible outside that network.  Thus, wide-area
         routing in the rest of the Internet will be based only upon the
         <Network-number> part of the IP destination address; gateways
         outside the network will lump <Subnet-number> and <Host-number>
         together to form an uninterpreted "rest" part of the 32-bit IP
         address.

The whole point of subnets is to provide a LAYERED, HEIRARCHICAL
approach to routing.  Anyone outside the subnetted network must be
able to route solely on the basis of network number.  Hosts on your
network 128.5 cannot do this.  Your configuration does not work
because it is illegal.

It is surely possible to envision all sorts of ways of "solving" this
supposed problem.  But then you will fail to solve the problem that
subnetting was intended to solve.  That problem was that routing at
the upper (network) layer was overloading from too many networks.
Subnets, by hiding a layer of the network topology, solved this.  The
restrctions of subnets are readily dealt with by proper (sub)network
design.

[The same approach was applied to DECnet in Phase IV, with areas.
What you are asking for is the equivalent of allowing node 7.33 in
DECnet to plopped down in the middle of area 5 and have it work.]