I agree with Dave Crocker that the post from John Klensin is the first one in thousand of emails that put the discussion in a new (and very interesting) perspective.
In the goold old IPv4 word, locators & identificators are the same thing. This is, as many people pointed out, the root cause for a lot of the hard problems we see today, such as multi-homing & mobility.
We have made the problem even harder in IPv6 by adding more sementic to specific addresses: we now have addresses that are non permanent with privacy extensions (RFC3041), transition addresses (6to4, isatap, IPv4 compatible,...), scoped addresses (Link locals and hoppefuly defunct site locals), home address vs care-of address, crypto-generated addresses, and the list grows every day.
Add to this that it is now more and more common for nodes to have multiple
interfaces to different types of networks with different physical caracteristics
(wired/wireless, high bandwidth, expensive access..)...
...and we made it even more complex now in the early days of coexistence of IPv4 and IPv6, when an IPv6 address may have been registered in the DNS but there is no actual IPv6 path to go there, or if there is one, it is sometime so boggus that it leads to very bad performances. (note: nothing to do with v6, just the sate of current deployment)
There is a proposal to create an API to enable the application creating the socket to specify some of the properties that it desires/requires. This is a step in the right direction, but I'm not convinced this can go far enough. So I fully support this idea of lifting the ban on TCPng (or any transport layer for that matter) to de-couple the abstraction needed by applications to the one required by the network. This is in fact introducing some of the semantic of a session layer between the application and the network. Can this be done at the transport layer in the form of TCPng or does this require and actual additional session layer? I'm not sure at this point in time.
- Alain.