In message <20050423012904.GL12650@netbsd.org>, Bill Studenmund writes:

>Given that, when they looked at how to fix it, they found that IPv6 has a 
>behavior that meets their needs. In this case, it seems reasonable to 
>suggest adding support to IPv4 of a feature that happens to be in IPv6.

Bill,

That's the whole problem: it is *not* reasonable for RFC1918 addresses.
The semantics of RFC-1918 addresses simply doesn't match IPv6 scoping
rules: there *is* no defined scope.  Thus we end up with situations
where an organization deploys, say, 10/8 as the organization's own
private network; and sub-groups or individuals within that
organization use 192.168/16 as *their* own ``private'' network.

Or consider an organization which has grown by acquistion, which has a
mixture of private and (legacy?) globally-routable IPv4 addresses.
To that organization, *all* those addresses are considered ``private''.
Speciifc hosts may be multihomed onto multiple different RFC1918
addresses, or multiple acquired `public' addresess or multihomed
onto both.

(Both such setups are, indeed, common cases.)

The conclusion is obvious: a heurstic derived from IPv6 scoping rules
simply *doesn't work* for RFC1918 addresses: they're just different
beasts, deployed in different ways. Reasoning by analogy from the one
to another just does not work. There *is* no well-defined scope for
RFC1918 addresses, other than that they are ``private''.


David's idea is .... well, I won't say anything.


>First, I don't believe that NetBSD supports Strong ES right now. 

But of course we do. See sys/netinet/ip_input.c for the words ``Strong
ES'' and ``hybrid'' and ``checkinterface''.  Yes, it says we support
an odd hybrid.  But with unbound sockets, and the RFC-1122 behaviour
of picking the address of the outbound interface, that goes a long way
towards supporting strong ES.  As Thor observes, some of us do rely on
that.


>Second, I'm not 100% sure how this will break Strong ES. I expect if we
>add Strong ES support, 

Adding David's patch, with David's proposed modification to ``scope''
RFC1918 addresses for multi-homed hosts, _will_ break decades-old
assumptions (definitions?)  about how IPv4 works.  It _will_ break
extant configurations which rely on our existing partial strong-ES
semantics. It _will_ break existing code that implicitly relies on
those semantics, and has done for years.

Thus, forcing IPv6 ``scope'' onto RFC1918 addresses is *not*
reasonable.  (OTOH, doing so for zeroconf addreses may well be
reasonable; but then I've never objected to that!)


For those who do see utility in distinguishing ``first-class'' local
IP[*] addresess from ``second-class'' addresses, I submit that
expliclity marking individual addresses as ``second-class'' is so
clearly a better approach than a heurisitc based on address prefix
that its not even worth talking about. (Or maybe defaulting zeroconf
addresses to be ``second-class?'')

[*] v4, that is.

Bill, I genuinely don't understand why so many here have difficulty
grasping simple facts, or difficulty accepting the consequences, or
whatever- it-is that's not getting across here.