In message <20050425193611.GB20220@netbsd.org>,
Bill Studenmund writes:


>The point I was trying to make was that the RFC doesn't say which address
>should be chosen. I gather from the fact that you refer to a historical
>behavior that my point was correct.
>
>The reason I mention this is that I believe that if we don't fully
>implement Strong ES, then we are, strictly speaking, a Weak ES system.

Not really.  We have a strange hybrid semantics. (I wasn't 100% sure
that NetBSD still had this when I posted about 3 days ago; I since
checked, and we do).

I admit to some confusion over exactly what David proposed.  Manuel's
picture clearly shows multiple interfaces with separate addresses on
each NIC.  That fooled me into thinking David was proposing changes to
that ``classic'' multihoming as well as the one-nic, multiple-address
scenario.  Given David is still trying to address Manuel's problem, I
suspect he talking about that case.

David, are you, or not?


>Weak ES doesn't make promises about which IP address will be used (I think
>that's a huge part of the point..), 

Concur. But in the days I recall, it *was* well-defined: pick the
first-listed address on the outbound interface. In the old days, that
tended not to change enough to worry about.  I find that it does.


>so we can change the IP selecting
>process and still be RFC-compliant. Correct?

Depends how you change it. Applying David's scoping suggestion, as
written, to the strong-ES-hybrid that Thor, and I, and others rely on,
*does* violate my reading of the clear intent of RFC-1122.  I beleive
it violates Thor's reading too (though THor cites the preamble of the
relevant section).  At least when we're talking about the single-addr-
per-interface configuration, as in Manuel's picture.




>I agree that we should consider things carefully when changing an old
>behavior, especially as some folks use the current behavior to implement a
>"close-enough-to-Strong ES" model. But changing a "we've always done it
>this way" behavior is different from changing an RFC-dictated behavior.

Err, no, I think i have to disagree there. Let me define the term
``classic multihoming'' to mean multiple interfaces with no more than
one IP address per interface.

What I'm saying is this: for ``classic multihmoing'' as defined above,
applying IPV6-style-scoping to IPv4 does actually break the RFC-1122
definition of ``strong ES''; and moreover the breakage affects the
partial version of ``strong ES' that *BSD stacks have.

Regarding non-classic multihoming, with multiple addresses per
interface: the more I think about that configuration, the more it
looks like a variant of weak-ES. To put it another way: for inbound
traffic, the addreses on a multi-homed interface are all an
equivalence class: there's no strong way to separate traffic to one
address from traffic to another. (I suppose we could check source IP
addresses, but bad-guys on the multihomed cable can always spoof them,
so why bother?).

OTOH when it comes to selecting a local address: weak-ES says any
address will do, strong-ES says (per the premble text about multiple
separate stacks co-residing in a single machine): if there's a
matching local subnet, pick that;, otherwise undefined: all the local
addresses on the outbound interface are an equivalence class, much as
in the classic weak-ES case.

Within an equivalence class, I'd buy the addition of explicilty-set,
super-usable-configurable priorities for selcting addreseses.





 
>> Tho' I dont know if it works anymore on NetBD, with hashed lookup of
>> local-IP-addrs it certainly does on other BSD derivatves. If it truly
>> isn't predictable on NetBSD, then that strikes me as a darn good
>> reason to distinguish first-class local addresses from
>> explicitly-marked secondary or "alias" addresses.
>
>And what if we want multiple "first-class" addresses?

Hm. Off the top of my head: you take an exact subnet match, if you
have one; otherwise rank them by priority, within a given
equivalence-class?  I need to think about (classic multihome vs
multie-addr-per-if) and ( weak vs-strong) a little more, though.

Also, I would propose a completely different alternative for the
server-side, for apps that wish to choose on a socket-by-socket basis.