> 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@ietf.org https://www.ietf.org/mailman/listinfo/ietf