NB: to anyone still paying attention,, I'm catching up in reverse order.

.paIn message <20050426022149.1EAD83BFE48@berkshire.machshav.com>,
"Steven M. Bellovin" writes:
>In message <0913989A-6ADE-4FF2-BE9E-73A5FDD43616@shagadelic.org>,
Jason Thorpe writes:
>>On Apr 25, 2005, at 12:36 PM, Bill Studenmund wrote:

>>> And what if we want multiple "first-class" addresses?
>>
>>And to address this point... nothing in an ifaddr explicitly marks  
>>the address as an "alias".  It is an alias only by virtue of not  
>>being the first on the list.  If you delete the first address on the  
>>list, then I am pretty sure that the next one is suddenly no longer  
>>just an "alias".

if dim memory serves, BSD really did have a notion of "alias"
addresses.  I'd have to UTSL, but my (dim, possibly broken) memory
says 4.4-lite or thereabouts, and even NetBSD until circa 1.3(?)

I dont beleive that notion of `alias' affected source-address
selection in the way we all seem to agree would be a Good Thing, if
not hardwired in the kernel. Vut it is a (weak) precendent for the
notion of ``second-class'' local addresses.

>>I.e. it is only by convention that these things are called  
>>"aliases".  It's all due to undocumented magic that the semantics are  
>>the way they are.

If you mean my use of alias, I really meant SIOCSIFALIAS or whatever
it was calld. Unless, as above, I am suffering a Senior Moment here.

>>To me, an address that is truly an "alias" would never be used as a  
>>source address unless it is on the passive side of a TCP handshake.

Me, I'd support using an "alises" as the lcoal adress for
otherwise-unbound sockets, if and only if the alias is a same-subnet
match for the desired remote address.  Tho' I suspect that'd violate
the behaviour in Stuar et al.'s IPv4 zeroconf I-D.  But it does meet
Manuel's problem, and Tom's: which seems to be at least half the
motivation I've seen here.

Comments??


>>But there are legitimate reasons for having multiple "non-alias" IPv4  
>>addresses on an interface.  If we want to support both, then  
>>something needs to mark those alias addresses as such (I would call  
>>them "passive" addresses, myself).  The "passive" semantics I  
>>envision would map equally well to both IPv4 and IPv6, or any other  
>>address family, for that matter.
>>
>
>I haven't had the cycles to participate in this debate, and I'm not 
>sure that this suggestion is fully baked.  That said, I'll toss it out 
>anyway.
>
>The current semantics, as I understand them, is that the source address 
>assigned is taken from the routing table entry used for the (initial, 
>for TCP) outgoing packet.  In particular, the first address on the 
>interface selected is used.  Suppose we try to extend that, by 
>associating explicit source addresses with routing entries.  When a
>destination address matches some particular route table entry, the 
>source address associated with that address would be used as the source 
>address for the packet.  (Like Jonathan, I'm very concerned about 
>attaching semantics in the kernel to particular classes of addresses.

FWIW, I think Bill is too; but its easy to miss with him smacking me
for my dogmatic intrasigence over Thou-Shalt-Not-Violate-HR-RFCs.


>For that matter, I was one of the very loud voices against IPv6 
>site-local addresses. 

Good for you. Seriously. No snarkiness from me.


>Link-local is an acceptable special case for 
>IPv6; it might be for IPv4 as well, but I suspect it's not necessary to 
>create any special rules for it.)

My reading of the latest I-D is that zeroconf/link-local addresses do
in fact require special processing. I haven't looked closely enough
(or with a non-spinning head) to tell if David's proposal meets the
I-D. My spinning-head take is that we'd probably not meet it.

David, I'd appreciate a point-by-point discussion of your proposal
vs. sec 2.6.1-2.6.2 of the draft, and the sections it references.