Re: Why?

> > > yeah, it *is* easier to deploy first and then later make incremental
> > > modifications for scalability - if you like NAT.
> > You do have to build upgrade paths into the architecture if you want 
> > it
> > to last ... Making an architecture last is all about .. creating
> > interfaces for the rest of the system that can be stable across 
> > drastic
> > changes in technology.
> But that's exactly what support of multiple addresses is - the key 
> architectural feature needed to make large-scale multi-homing work 
> (within the existing routing/entity-naming architecture, i.e. the one 
> that IPv6 shares with IPv4). I.e. it's the thing we need to have in 
> the architecture to allow the upgrade path you mention.
no, it's not - at least, not in anything resembling its current form.  
that stable interface that allows the apps to transparently survive 
changes in technology (much less ordinary changes in addressing or 
connectivity) is missing.
> In thinking about this whole point of acceptance of the use of 
> multiple addresses, I came upon an interesting way to look at it all. 
> It starts with the supposition that it seems likely that one way 
> people will do multi-homing is to use a NAT box, and thereby restrict 
> the knowledge of the multiple different addresses (i.e. 
> location-dependent "routing-names") to the border of their system.
> However, another way to look at this is to say that what they really 
> want is to configure their machines with only one identifier, one 
> which is (mostly) location-indepedent, and therefore serves mostly to 
> identify them. They are quite happy to then have those machines depend 
> on another device, at the edge of their network, to provide the 
> location-dependent routing-names for their
> machines.
I think that's a useful avenue of inquiry.  part of the problem is that 
the choice between addresses really does affect quality of service, and 
the requirements for QoS vary from one app to another.  so you need to 
push those preferences from the apps through the hosts to the edge of 
the network.  another part of the problem is the emerging tendency for 
mobile hosts to have multiple network interfaces and participate in 
multiple networks.  such devices resist the "one identifier" model.
> At an architectural level, this is obviously basically the same as 
> saying that one configures machines with identities, and the machines 
> pick up their routing-names from devices within their network, which 
> provide this data. (This was pretty much exactly Mo O'Dell's 
> enhancement on Dave Clark's basic 8+8 idea.)
> So why people were and are so resistant to doing the latter is a more 
> than a little puzzling to me, because they are clearly happy to do 
> effectively exactly the same thing when a NAT box is involved.
I'm not sure they're the same people in both cases.  but here's a 
litmus test - if there's not a token for any host A that host B can 
hand to host C at some arbitrary location in the network and have C use 
that token to quickly and reliably establish a connection to A (modulo 
access control) then the architecture is dysfunctional.  or to put it 
another way - if DNS or a similar name-to-locator (or 
name-to-identifier+locator) translation mechanism requires special 
knowledge to make it work, that isn't available to "ordinary" apps, the 
architecture is dysfunctional.
Keith


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf