Path: utzoo!utgpu!attcan!uunet!husc6!cmcl2!rutgers!ucsd!ucbvax!DECWRL.DEC.COM!mogul
From: mogul@DECWRL.DEC.COM (Jeffrey Mogul)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: subnet IP mask stored in route or interface struct?
Message-ID: <8808040052.AA20059@acetes.dec.com>
Date: 4 Aug 88 00:52:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 36

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.