In message <E1DP9pc-0005Z6-00@smeg.dsg.stanford.edu>,
Jonathan Stone writes:

>In-reply-to: Your message of "Fri, 22 Apr 2005 18:29:04 PDT."
>             <20050423012904.GL12650@netbsd.org> 
>--------
>In message <20050423012904.GL12650@netbsd.org>Bill Studenmund writes
>
>
>[...]

>>The key difference as I see it is that the main, root issue is that folks=
>>=20
>>don't like what IPv4 does, not that IPv6 does something different. Yes,=20
>>that's a nit, but I think it's an important nit. If I felt this were a=20
>>"IPv6 should be like IPv4" arguement, I'd be agreeing with you. Strongly.=
>>=20
>>:-)
>
>That is all I see here.  IF IPv4 doens't meet their pet needs: sorry,
>but tough. More on that later.  

The idea itself is *dumb*, but (despite asking repeatedly and
sincerely) most of the proponents of this idea have not conveyed a
clear, coherent, picture of what they are really trying to do.
Reading between the lines, my guess goes something like this:

  * They have a host which is multi-homed. Possibly multi-homed
    via multiple NICs; possibly via multiple IP addresses on a single
    physical NIC. Various folks have proposed different scenarios.

  * That multi-homed host is acting as both an end-host and a router.

That much is common to all proponents, AFAICT.

In Tom's case, he seems to want his multi-homed router to act, *most*
of the time, as a normal end-host.  He doesn't want to have to explicilty
tell each and every app to use his `internal net' IP address as
its local address; he would prefer to ``just DTRT'' for the common case
(whatever that is). In other words, one of the addresses
Tom's machine is a second-class address.
 
The prior art has at least two *extremely* well-known techniques for
treating local IP addresses as ``second class'' in this fashion:

  #1.  Local IP addresses are ordered; first by interface (i.e.,
       bus scan order); then, for multiple addresses on a
       single interface, by the order in which addresses are added.

  #2. Alias addresses: separate ioctl()s and ifconfig commands
      exist for creating ``first-class' addresses and for aliases.

OTOH, note that we killed these off ages ago.  I would add another
possible candidate:

  #3. FreeBSD-style ``jails''. Though for that to work, Tom
      might have to do all his `normal' end-host work in a jail; I dunno.
      I also don't want to get caught into defending the FreeBSD
      implementation, but it is an interesting idea.

I need to think about it more, but if I had to choose, I'd probably
opt for reviving #2 here. As I recall it (and I think FreeBSD-4.x
still works the same way?), that did exaclty what David seems to be
asking for: use the first-class local address for nonlocal traffic,
and use the second-class "alias" address only for traffic to the same
subnet as the `alias'.  (Though I find David's exposition so muddled,
its hard to tell. Maybe that's because I'm IPv4 centric and David is
IPv6-centric? i dunno.)

The ``jail'' idea is interesting, but a huge implementation overhead.
eThe pervasiveness in the extant FreeBSD implementation doesn't exactly
convey confidence in the approach, either.

Whichever way you prefer, there are two quite distinct concepts here:

   * IPv4 non-globally-routable addresses

   * ``second-class address'' semantics.

Conflating independent concepts is always a design flaw. In this case,
it's a serious design flaw.  One concrete example: David's approach
(if I have read it aright) solves Tom's problem if and only if the use
of IP addresses matches *his* usage. As best I can tell, David's
approach just plain wouldn't work if, for example, both of Tom's
addresses were nonroutable (192.168.  vs 10.x.y.z): say if the 10.x
addresses were a larger campus network, and the 192.168 addresses were
Tom' `private' net.  (I see setups like that, every day.)

Is that a clearer exposition on my part?



>>First, I don't believe that NetBSD supports Strong ES right now. 
>
>No, but I have code that does. 

Some more datapoints: it turns out FreeBSD has supported Strong
ES-style filtering of received addresses for years, now.  Also, I hear
Linux has supported what is sometimes called "policy-based routing"
for several years, where "policy-based routing" is *exactly* doing
next-hop lookup using both source and dst IP addresses, as RFC-1122
notes is necessary for Strong-ES.

And (in case you missed it) Linux SO_BINDTODEV allows apps to select
``strong ES'' model on a socket-by-socket basis.