--Ublo+h3cBgJ33ahC
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 26, 2005 at 12:47:27PM -0700, Jonathan Stone wrote:
>=20
> In message <20050425225851.GD20220@netbsd.org>,
> Bill Studenmund writes:
>=20
> >Ok, here are some implementation thoughts. First, this question should
> >ONLY be coming up when we don't already have a source address. For TCP,
> >once we have connected, we should always be using our IP for the socket.
>=20
> I would say that very differently: for active-open with unbound TCP
> sockets, we only get to choose a local IP address once; thereafteer
> the local IP addressed is fixed by the 4-tuple.
>=20
> For passive opens (that aren't rejected), the local IP address is
> specified by the active opener.
>=20
> I can't tell if that matches what you say; are you maybe thinking
> solely of the "client" side, again?

That matches what I am thinking. And I'm not thinking just of the
"client". I am thinking of "server"s, but they only have an ambiguity if
they are using an unbound UDP socket. TCP is fixed by the 4-tuple, and I=20
assume there's a similar anchoring in SCTP.

> >So I doubt that this code, if done even moderatly right, would impact the
> >environments you describe above; we aren't sending TCP connect packets at
> >line rate (well, not in the normal case :-) .
>=20
> Again, I am thinking multihomed servers. I think you agreed, a few
> messages back, that servers could conceivably get more complicated.

Yes, I did agree that. After thinking about it, I really don't see a way
in the general case for a UDP-based protocol to work on a multihomed
server if the sending socket is unbound (and the application doesn't=20
supply the source address). The problem is that only the application knows=
=20
(well, can know; it could be a stupid app) what address the client tried=20
to contact.

> >So how about an idea someone else suggested earlier in the thread, that =
we
> >add a field to the routes that indicates a source address to use if no
> >other source is specified?
>=20
> But we need a route that says: send out interface X; but when
> selecting an local address for a not-otherwise-bound socket, use a
> local address, Y, that's on some other interface.

Yes. The best I can come up with is having both an -ifa and an -ifp option=
=20
on a route. I however an not fully sure how to keep admins sane in face of=
=20
such a beast. It certainly should come with lots of notes in the man=20
pages. :-)

> Hmm. I can construct a scenario that runs into the same problem I
> asked about a day or so back (have you thought about that yet)?

I thought about the NFS issue you discussed, but I am not getting any=20
large bundle of insight. I see issues, but you seem to think that by=20
thinking about it, I will have some reaction I'm not.

> >> Huh? one of my points all along, is that David's initial proposal
> >> *DOES* make things worse --- much worse --- in the kind of networks I
> >> deal with on a day-to-day basis. I beleieve I have given both you and
> >> Manuel and David examples of just what breaks. Should I repeat them?
> >
> >I'm sorry. I thought David had the patch doing this change sooner in the
> >processing than it is. To the extent that we may choose an address not on
> >an interface after having chosen that interface, I agree the patch is ba=
d.

Turns out I was wrong. David's initial patch only chose different
addresses on the same interface, and it would only have changed the
address if the first-pick and the destination were not in the same
link-local equivalence class (one link-local and the other not). So it
would not have broken Strong ES (to the extent you can have Strong ES on a
NIC with two primary addresses).

> For RFC-1918: If the admin configures strong-ES, or something akin to
> it, then the admin clearly doesn't want to route packets out one
> interface, with an address that's local but on a different interface.
> Thus, it seems to me that for "classic" multihoming, you can't have
> both.  Hence, I conclude (as I said from the beginning) that
> hardcoding IPv6-insipred ``scoping'' into the kernel is veboten.
> Not just bad or very bad, but verboten.

Would you please give up on that? You are currently the ONLY person in
this thread talking about hard-coding scopes (other than link-local, which
I think everyone agree if we do, we should do right) in the kernel.=20
Everyone else dropped that ten or more messages ago.

David offered an idea. A thought. Not a full proposal. You're the person
who took it as a "must-be-this-way" proposal. Continuing to blast him over
details of something he didn't fully detail (nor do I think he claimed to
detail) is the kind of behavior we expect of Theo. Please stop it.

> I am very, very leery of routing-table mechanisms. I worry they will
> lead to ARP failure on multihomed hosts.  Note that for complete

How?

We aren't pretending internal address A really is on net B, so it _should_
fail ARP. For an admin to ever choose to use source IP A out network B,
there must be some routing path from hosts on net B back to address A. Or
else the admin made a mistake or is quite confused. This strikes me as one
of those, "give the admin the rope," issues.

> strong-ES, we really *nee*=09
> 	route lookup
> 	deafult route
> 	arp lookup (since its intertwined with routes
>=20
> to be done on (remote IP addr, local IP addr, [ToS]), exactly as
> described in RFC-1122.  Using route table entries may force us into
> doing that sooner than we'd otherwise have to.

How would using routes to help choose local IP addr when there's an=20
ambiguity (active-open TCP connect or unbound UDB) lead to us needing to=20
make those Strong-ES changes sooner? If you're doing Strong-ES, you aren't=
=20
going to have any route that says, "use address A out an interface it's=20
not on" as that breaks Strong-ES.

Take care,

Bill

--Ublo+h3cBgJ33ahC
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFCbrY1Wz+3JHUci9cRAoDrAKCFxnv3CMjYaqZagsyj3tWNzH7zZACeMXQK
KfW1edo92lCLWrsqK4K9lww=
=Y5m0
-----END PGP SIGNATURE-----

--Ublo+h3cBgJ33ahC--