Yes, I am aware that some applications are IPv6 only. But I don't think that they have enough momentum to carry the IPv4 world forward into IPv6. The applications that are following that route are self-selecting for requiring little or no IPv4 connectivity. There are two models of technology adoption that might be applicable here. The paradigm that I think most IETF transition planning was based on was vinyl being replaced by CD. The advantages of CD were obvious to anyone who wasn't an audiophile bore who had spent $5000 on a turntable and some clever marketing. So the transition occurred even though it required people to repurchase their vinyl records on CD. But IPv6 does not deliver a clear technical advantage to the purchaser over IPv4. So the model that is more appropriate is Betamax vs. VHS and the question is whether the technical factors that the designers think people should care about (picture quality, ability to freeze frame) win over the ones that they actually care about (ability to record feature length movie on one tape, open standards, availability of content). If we were in a vinyl/CD type race then the previous IETF strategy of attempting to maximize the differences between the technologies would make sense. In that circumstance you would want to kill off NAT64 and so on. But in a Betamax/VHS type contest, attempting to differentiate the new through obfuscation merely raises barriers to transition. In that circumstance you want to minimize the differences between the two technologies so that they can be used interchangeably. [Oh and I am aware of the ridiculous claims by Lieberwitz and Margolis concerning the history of Betamax/VHS. As with their work on QWERTY, it was performed for a DC thunk tank being paid to deliver an argument that network effects do not exist. As such it is paid advocacy, not scholarship and their claims do not merit consideration.] On Tue, Jun 15, 2010 at 4:31 AM, Thierry Ernst <thierry.ernst@xxxxxxxx> wrote: > > Dear all, > > I follow this amusing debate - I'm not reacting to this post specifically. > > I would like to point out that there are people out there specifying > communication architectures for new uses of the Internet, e.g. Cooperative > Systems for communications involving vehicles. The system running between > all entities composing their network will be living in an IPv6-only world. > They will only deploy transition mechanisms to keep communication going on > with other parts of the Internet not running IPv6, if that proportion is > still significant by the time these new systems get deployed (hopefully, > they won't have to do so, and for sure they won't deploy dual stack). > > It seems to me that these new uses are always ignored when one is debatting > transition from IPv4 to IPv6. In some many cases, it is simply transition > from something not IP to IPv6. So, there will be IPv6-only systems deployed > out there (the sad news is that there are also sectors transitioning from > non IP (e.g. X25) to IPv4 - just because they are not aware about IPv6 or > are still thinking IPv6 is for the next decade). > > Regards, > Thierry. > > > On 15/06/10 02:10, Mark Andrews wrote: >> >> In message<AANLkTimoqnpmKcbitki07KAG9xTROYIv84RqSmo0dq84@xxxxxxxxxxxxxx>, >> Phil >> lip Hallam-Baker writes: >> >>> >>> On Thu, Jun 10, 2010 at 11:04 PM, Mark Andrews<marka@xxxxxxx> wrote: >>> >>> >>>> >>>> I'm thinking 10, 15+ years out when there are lots of IPv6 only >>>> served zones. Much the same way we no longer worry about MTA's >>>> that don't know about MX records and no longer add A records >>>> to accomodate them. >>>> >>> >>> Why would there be any IPv6 only served zones? >>> >> >> Because it going to get harder and harder to get stable IPv4 >> addresses. ISP's are looking at moving their entire client base >> from having unshared public addresses to shared public addresses. >> >> >>> >>> What John and I have been trying to get across here is that there is >>> no incentive to create an IPv6 only zone now and never will be in the >>> future. You present an induction without a base case. >>> >> >> Except IPv6 only zones already exist so there must be some incentive to >> have them. >> >> >>> >>> Back in the days when Internet on phones meant WAP, there was a >>> possibility of them being supported on IPv6. But now the iPhone has >>> changed the model and the Web on a phone will look just like the rest >>> of the net and so they have to run IPv4. >>> >>> That is the big flaw in the IPv6 ready program. It assumes that the >>> incentive for transition is that IPv6 is a good in itself. It is not, >>> in fact IPv6 will be slower (more header baggage) than IPv4 and if you >>> are IPv6 only you will have to go through gateways. >>> >> >> And IPv4 will have multiple header re-writting. DPI to "fix up" the fact >> that headers have been re-written multiple times along with checksum >> re-calculations etc. >> >> I actually expect IPv6 to be faster in the end if only marginally. Most >> measurements to day say that IPv4 and IPv6 are roughly the same. >> >> >>> >>> We do seem to be making some progress. I have been banging on about >>> this problem for six years. When I started NAT was universally >>> considered to be the problem. People are now seeing the NAT-PT >>> approach as being a possible framework for a solution rather than >>> something to be deprecated as 'historic' because they (wrongly) >>> imagine true Internet is NAT-free. >>> >> >> The more I look at NAT-PT (NAT64/DNS64) the less I like it. Way >> too many kludges especially when there is an alternative, DS-lite, >> which doesn't have nearly as many problems that need to be kludged >> around. >> >> Mark >> > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > > -- Website: http://hallambaker.com/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf