Re: bin/10911 (ifconfig requires address to set netmask, broadcast)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR bin/10911; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/10911 (ifconfig requires address to set netmask, broadcast)
Date: Thu, 18 Aug 2022 20:17:35 +0700

     Date:        Wed, 17 Aug 2022 23:48:10 +0000 (UTC)
     From:        nat%NetBSD.org@localhost
     Message-ID:  <20220817234810.DC3E91A923A%mollari.NetBSD.org@localhost>
 
   | Synopsis: ifconfig requires address to set netmask, broadcast
 
 I actually doubt that there is any bug here at all.
 
 The PR text says:
 
 	This bug appears to have been present back in 4.4lite, and
 	probably some time previous. It apalls me that no one seems
 	to have noticed, though.
 
 As best I recall it (which doesn't necessarily mean a lot) ifconfig
 (from when it appeared in versions of BSD between 4.1 and 4.2) has
 always worked like this, at least since the concept of a netmask was
 invented) - and that's because in general, any other way makes no sense
 at all.   That is, it isn't a bug.
 
 Consider an interface (dummy0) with two addresses
 
 	10.2.3.4
 	192.168.1.7
 
 If I were now to do
 
 	ifconfig dummy0 netmask 255.255.0.0
 
 what is supposed to happen?   What subnet numbers can the system
 conclude are attached to that interface?
 
 A netmask only means anything when it is applied to a specific
 IP address (or at least, subnet number - since its purpose is to
 mask away the host bits, what they are doesn't matter as much).
 
 The above interface is likely to have 2 different netmasks, probably
 255.255.255.0 for 192.168.1.7, and almost anything for the network
 10 address (255.0.0.0, 255.192.0.0, 255.255.0.0, 255.255.248.0,
 even possibly 255.255.255.255 indicating an isolated host, or more
 likely 255.255.255.254 (or 252) for a minimalist 2 host subnet).
 
 The original design simply assumed that the two would be set together,
 always, as the system needs to know both this system's address, and the
 netmask to be applied to it to discover the subnet's subnet number from
 that address.   However, in the early days there were no netmasks, the
 address "class" (a concept now best forgotten) allowed the subnet number
 to be discovered directly from the IP address (for the two addresses
 above, the classful netmasks would be 255.0.0.0 and 255.255.255.0).
 Thus, it was possible to specify an IP address without a netmask, and
 when that happened, the system would use the address class to deduce the
 mask to be applied (either literally, or just conceptually in implementations
 from when all IP addressing used classes).
 
 While here, note that netmasks long preceded CIDR - they were invented to
 allow a single classful IP network number to be shared amongst multiple LANS
 within an organisation, so don't confuse the introduction of CIDR, and the
 eventual removal of classed addresses at all, as being related to this.
 That's all a much more recent development.
 
 Broadcast is similar - when BSD first invented the concept (standard IP
 at the time had no notion of broadcast, not multicast either) the address
 used as the broadcast address was always the subnet number.   That is
 (IPADDR & NETMASK) was the broadcast address.    Other systems that also
 implemented broadcast instead used (IPADDR | ~NETMASK).    Originally these
 were not configurable options - but with different implementations using
 different things, config was needed, so the broadcast addr config was added.
 
 But if you look at the two definitions that had been used, one thing stands
 out - they both use both the IPADDR and the NETMASK.    Now obiously one can
 (as was originally done) simply compute the broadcast addr from those, if you
 know which formula to apply, that's not the point - the point is that the
 broadcast addr applies to a specific subnet on the link, and means nothing
 without that association.   The subnet number comes from the IPADDR and
 NETMASK (though just the IPADDR is enough to identify it).   Hence setting
 the broadcast addr also means nothing without knowing which IP address is
 associated (so the stack can calculate which subnet number it applies to).
 
 Once upon a time it was considered acceptable to route a broadcast packet
 to an unconnected link (normal IP routing based upon the address) and
 have the router on that link broadcast it there - but this was considered
 rather anti-social, and mostly blocked, and in any case, there was never
 a mechanism defined for anyone not on the link to discover what address to
 use to broadcast on some unconnected link.
 
 When 255.255.255.255 was defined as an alternate broadcast addr, that changed
 things a little, as that one has no associated subnet number, and simply
 means "broadcast on this link" which has subtly different sematics that a
 subnet broadcast - that one it might be reasonable to allow to be configured
 without an associated IP address.   Personally I'm not sure the special case
 is worth the effort, especially as that kind of broadcase tends to be used
 only early in the system life, before IP addresses are configured, and so
 by special case software that can send IP packets without an associated addr.
 
 In this, there is the obvious special case - an interface that has only
 one IP address.   In such a case, one might assume that simply setting a
 netmask or broadcast address would apply to that address.   I don't think
 making the kernel treat that as a special case is reasonable - but ifconfig,
 when given just a netmask (or broadcast) param, could go check to see if the
 interface has only one address, and if so, assume that one.
 
 Personally I don't think that's a good idea - it establishes the wrong
 expectations about the way that things work in the mind of the user.
 Users who are configuring IP manually (which all of this presumes, using
 DHCP will never attempt to set a netmask or broadcast addr without an
 associated IP addr) should learn that the netmask applies to a specific
 IP address, and the way to get that point across is to never allow the
 netmask to be specified alone.
 
 So, I'd simply close this PR as "not a bug" - the most I believe might be
 done is to have ifconfig object when given a netmask (or broadcast addr)
 without an IP addr to associate it with, rather than just ignoring it.
 
 kre