--7gGkHNMELEOhSGF6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 25, 2005 at 01:09:15PM -0700, Jonathan Stone wrote:
> In message <20050425193611.GB20220@netbsd.org>,
> Bill Studenmund writes:
>=20
> >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.

Turns out I'm wrong. Strong ES has "MUST"s replacing the "MAY"s in RFC1122=
=20
3.3.4.2 (a) and (b). Weak ES has "MUST NOT" replacing those "MAY"s. Thus=20
you can be Weak, Strong, and None of the above.

> 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).

Agreed. Though said hybrid isn't described by an RFC. ;-)

> 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.

[snip]

> >Weak ES doesn't make promises about which IP address will be used (I thi=
nk
> >that's a huge part of the point..),=20
>=20
> 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.

Well, in the old days, did you really have more than one IP per interface?=
=20
:-)

> >so we can change the IP selecting
> >process and still be RFC-compliant. Correct?
>=20
> 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.

Do you not see the irony of complaining about a change breaking RFC=20
compliance when we don't comply with said RFC now? :-)

> >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.
>=20
> 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.
>=20
> 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.

As I understand David's original (now out-of-date?) patch more, I think I
agree that it would break Strong-ES. I think the change is happening at
the wrong level. Once you have a route, you have an interface. Once you
have an interface, by Strong-ES, you have to use an (the?) address on that
interface.

I think that the intent should be applied earlier in the process, before
we pick the route. If we are in a case where we have NOT defined the
source address (tcp connect via unbound socket, udp w/o set source
address), I think the idea of prefering some addresses over others
(configurable by the administrator) is VERY reasonable. And, at this level
of things, I don't think it'll break Strong ES. I think of it as picking
which of the internal hosts (in Strong ES) actually transmits.

> 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?).

True.

> 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.
>=20
> Within an equivalence class, I'd buy the addition of explicilty-set,
> super-usable-configurable priorities for selcting addreseses.

I think that'd be good, but I think we'd do well to solve the problem=20
further up stream.

> >> 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?
>=20
> 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.
>=20
> Also, I would propose a completely different alternative for the
> server-side, for apps that wish to choose on a socket-by-socket basis.

That'd be fine. I think if an app has indicated what it wants the source=20
to be, then this discussion shouldn't change that.

So it sounds like we're now agreeing more than disagreeing.

Take care,

Bill

--7gGkHNMELEOhSGF6
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFCbWtdWz+3JHUci9cRArvcAJ95rfFNNcyx2WcvCAHdOm13ILzjQQCfQ3F7
zW0fR+LsQJVtVS9VgBLVOpU=
=jiIH
-----END PGP SIGNATURE-----

--7gGkHNMELEOhSGF6--