In message <20050423163953.GA16453@panix.com>,
Thor Lancelot Simon writes:

>On Sat, Apr 23, 2005 at 01:21:46AM -0700, Jonathan Stone wrote:

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

What? That makes no sense.

First, if we want to address problems with multi-homed hosts, then
surely we need to address it for *all* multi-homed hosts: 

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

Manuel's picture has separate network interfaces.  If David's approach
is only for (b), just how does it fix Manuel's problem? 
Am I missing something?


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

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.

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



>I don't think David is suggesting that either heuristic he is proposing
>should be the default -- is he?  David?

Look at what David said, look at the patch:

 DY> Actually,
 DY> I think that the the IPv4 address selection should resemble IPv6 address
 DY> selection, where the "scope" of the destination address is considered
 DY> (global, link- or site-local), and a source address with the same scope
 DY> is preferred.


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.


>I can certainly see where they'd be useful.

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.

Yes, David's idea is objectionable vis-a-vis RFC1122. Yes, it's based
on a logical fallacy.  But the bottom line is: it's not even a
particularly *good* approach for the problems for which David touts it.

Lets kill the bad idea now, before it has time to spread.