--Qrgsu6vtpU/OV/zm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Apr 23, 2005 at 10:26:41AM -0700, Jonathan Stone wrote:
>=20
> In message <20050423163953.GA16453@panix.com>,
> Thor Lancelot Simon writes:
>=20
> >On Sat, Apr 23, 2005 at 01:21:46AM -0700, Jonathan Stone wrote:
>=20
> >> As Thor noted in message, <20050413213934.GA14667@panix.com>, this
> >> idea does violence to RFC-1122 ``Strong ES'' model, which many of us
> >> rely on to a greater or lesser degree.
> >
> >I am reading 1122 again and I am not so sure.  The RFC says "the physical
> >interface that corresponds to the IP source address..." and so forth; but
> >David is talking only about hosts that have multiple IP addresses on the
> >_same_ interface.=20
>=20
> What? That makes no sense.
>=20
> First, if we want to address problems with multi-homed hosts, then
> surely we need to address it for *all* multi-homed hosts:=20
>=20
>   (a) hosts with multiple interfaces with a single address per if;
>   (b) hosts with multiple addresses on a single if; and
>   (c) and hosts with multiple ifs with multiple addrs per if.
>=20
> Manuel's picture has separate network interfaces.  If David's approach
> is only for (b), just how does it fix Manuel's problem?=20
> Am I missing something?

I'm not sure if ANYTHING will fix Manuel's problem. ;-)

The difference I see with the cases is that if you have multiple=20
interfaces, you can bring the routing table in to help you do some things.=
=20
It won't cure all problems, but it can help a client pick which address to=
=20
use to talk to a given server.

> > What David is proposing does, though, run contrary to
> >the introductory text about the _intent_ of the strong host model, that
> >"it tends to model a multihomed host as a set of logical hosts within the
> >same physical host" and to some extent to the principle of least surpris=
e.
>=20
> Yes.  Exactly.  But David thinks his intution outranks RFC1122: he
> said explicitly, he thinks IPv4 local-address selection should work
> like IPv6 local-address selection, and follow `scoping' rules.
>=20
> But RFC1918 addresses simply don't follow those scope rules, as in the
> example I offered both to Bill and to Manuel: multiple distinct
> RFC1918 networks, one "pulbic" (via NAPT), one "private".

Wouldn't it have been simpler and more productive to just say, "Hey, we=20
need more flex here. This other configuration is valid, and your idea=20
should support it too. So you should make this policy configurable." ???

> >I don't think David is suggesting that either heuristic he is proposing
> >should be the default -- is he?  David?
>=20
> Look at what David said, look at the patch:
>=20
>  DY> Actually,
>  DY> I think that the the IPv4 address selection should resemble IPv6 add=
ress
>  DY> selection, where the "scope" of the destination address is considered
>  DY> (global, link- or site-local), and a source address with the same sc=
ope
>  DY> is preferred.
>=20
>=20
> David says explictly, he think's thats how it should work.
> David's patch has neither opt-in or opt-out mechanism.  That's not
> just default behaviour, it's the *only* behavior.

Then why not say, "this needs to be configurable and should default to=20
off," rather than send out many blasting EMails? It would have been=20
exceptionally reasonable, and I bet David'd have added it. And if he=20
didn't, it would be easy to justify adding it later.

> >I can certainly see where they'd be useful.
>=20
> I suggested a different approach to Bill and to Manuel: explicitly
> marking ``second-class'' addresses as second-class, and not using
> 2nd-class addresses as outbound addresses for traffic to different
> nets. That is clearly a better approach than any heuristic.

It wouldn't work for the idea I had in mind.

I think I can express what I wanted to do like this: I'd like to be able=20
to have two "first-class" IP addresses on an interface. I'd also like a=20
way to set system policy to determine which of the two addresses is used=20
when initiating outgoing TCP connections. In terms of the separate host=20
systems within a Strong ES, I want to be able to configure which of two=20
internal virtual systems seems to be the one communicating to an external=
=20
server.

Take care,

Bill

--Qrgsu6vtpU/OV/zm
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFCa0MVWz+3JHUci9cRAksUAKCG3hkjlCAU/y+OKq3qXGjyXkSdkwCfd9iJ
7+luNh7/qoocseUulfGKWwc=
=ZadS
-----END PGP SIGNATURE-----

--Qrgsu6vtpU/OV/zm--