IMO, one of the biggest challenges surrounding IPv6
adoption/deployment is that all applications are potentially
impacted, and each and everyone one of them needs to be
explicitely enabled to work with IPv6.
Or NAT-PT needs to improved so that middleboxes can be inserted
into a network to provide instant v4-v6 compatibility.
That is a huge
challenge, starting with the observation that there are a
bazillion deployed applications that will NEVER be upgraded.
Yes, I agree that there is a nice market for such middleboxes.
Boy, wouldn't it be nice of all we had to do was IPv6-enable
the underlying network and stack (along with key OS support
routines and
middleware) and have existing apps work over IPv6, oblivious
to IPv4 vs. IPv6 underneath.
Middleboxes can come close to providing that.
Wouldn't it have been nice if the de facto APIs in use today
were more along the lines of ConnectTo(DNS name, service/port).
I don't know if "nice" is the right word. It would be interesting
and I expect that there would be less challenges because we would
have had a greater focus on making DNS (or something similar) more
reliable. It's not too late to work on this and I think that it
is healthy for multiple technologies to compete on the network.
At this point it is not clear that IPv6 will last for more than
50 years or so. If we do work on standardizing a name-to-name
API today, then there is the possibility that this will eventually
prevail over the IPv6 address API.
Way back when there was an OS called Plan 9 which took the idea of
a single namespace more seriously than other OSes had. On Plan 9
everything was a file including network devices which on UNIX are
accessed with sockets and addresses. This concept ended up coming
back to UNIX in the form of the portalfs (not to mention procfs).
I think it is well worthwhile to work on this network endpoint
naming API even if it does not provide any immediate benefits
to the IPv6 transition.
--Michael Dillon
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf