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.