[arin-ppml] The non-deployment of IPv6

Ted Mittelstaedt tedm at ipinc.net
Tue Dec 8 13:42:27 EST 2009

Owen DeLong wrote:
> On Dec 7, 2009, at 2:49 PM, Ted Mittelstaedt wrote:
>> Owen DeLong wrote:
>>> On Dec 7, 2009, at 1:57 PM, David Farmer wrote:
>>>> Ted Mittelstaedt wrote:
>>>> ...
>>>>> Today, though, Vista bombed hard, and it's too early to see what Win 7
>>>>> will do - but I frankly don't see a huge reason to switch to it, and
>>>>> I have both Win XP and Win 7 at home and in the office.  And 
>>>>> seriously,
>>>>> folks, does everyone here understand that Microsoft will be 
>>>>> releasing security updates and patches to XP Professional until 
>>>>> 4/8/2014?  That
>>>>> is almost 5 years from now.  You can be sure that XP will be a 
>>>>> significant number of installed seats on the Internet until then, and
>>>>> as long as it is, IPv6 isn't going to be widely deployed.
>>>>> As for IPv4+, or whatever alternative you dream up, unless you have MS
>>>>> buy-in, then you can just forget it.  And MS is backing IPv6
>>>>> Ted
>>>> AMEN!!!, +1, You got it man!
>>> 1. The lack of IPv6-only name resolution is not a significant barrier to
>>>    IPv6 deployment. It would be a significant barrier to IPv4 removal.
>>> 2. If M$ is going to be releasing patches to XP until 2014, then, why 
>>> would
>>>    you assume those patches will never include a patch that enables
>>>    DNS resolution from an IPv6 nameserver?
>>> In reality, this is only really an issue if you are attempting to 
>>> deploy an XP
>>> system in an IPv6-only environment. As long as you deploy it in an 
>>> IPv4 only
>>> or a dual-stack environment and provide it at least one IPv4-based 
>>> resolver,
>>> things will work with IPv6.
>> I think this is wishful thinking.  It was certainly very possible to 
>> dual-stack IPX and IP and for a few years people did - but most admins
>> hated it - and pressured Novell to adopt IP and abandon IPX.  Novell
>> of course did not want to do that as it would unlock customers from
>> NetWare - with the result that admins basically gave up on NetWare
>> and went to Windows NT Server.  (of course there were other reasons too)
>> Dual-stack is a problem in the corporate world because you have 
>> increased training costs.  Admins switched internal networks to
>> IP last time because the Internet pushed them to do it.  Likely
>> they will want to wait until significant IPv6 is deployed on the
>> Internet before switching internal networks to IPv6 this time, and
>> nothing on the Internet is doing the pushing to IPv6, which is why
>> I think it will be a longer time coming.
> I don't really see this as a problem.  Getting desktops over to dual stack
> really is last priority in my book.  The important thing is getting servers
> and content providers dual-stacked, because, the first systems that will
> get forced to IPv6-only will be those that come on-line after IPv4 runout.
> Likely the bulk of those will be end-users of some form or other.

Owen, there's a disconnect here - the people coming online post-IPv4
runout are not necessarily the people with brand new shiny Windows 7 and
Windows Vista desktops that CAN speak IPv6.  More likely they are the XP
users in the third world.

I agree that content providers NEED to be dual-stacked first, but what I
am saying is that this time around, NOTHING is really acting as a driver
for IPv6 deployment, (except IPv4 runout) and there are a LOT of things
that are obstacles to IPv6.  One of the big ones is XP.

It is not that MS released IPv6 for XP missing DNS lookups.  It is that
MS released IPv6 -after the fact- because that REMOVED the onus on all
of the 3rd party software developers to make sure their network 
applications worked in IPv6 environments.  So, if your a commercial 
software developer and you certified that your stuff ran on
XP, because IPv6 is an add-on for XP, you don't have to fix anything 
that breaks when your customers load the MS IPv6 add-on.  Instead
you can simply tell your customers that they have to buy the new
version of your software that you released last year that is certified
on Vista and Win 7 if they want to run IPv6.

We have a number of customers, mixed XP/Vista/W7 environments, where
they have legacy apps that break under Vista/W7.  Their solution is to
just use XP on user desktops that run those apps.  Someday, maybe a few
years from now after the recession is over, they might think about
updating to newer versions of those apps.  But, they likely won't until
2014 because those apps are extremely expensive, and there's a lot of 
labor in updating since the app vendors "thoughtfully" changed database
layouts within the app, as well as screen interfaces, etc.  Naturally,
the app vendors want these customers to spend money updating, and so 
whenever there is a problem in the app, these customers are told upgrade 
and that problem will be fixed, even though the problem
wouldn't really be fixed by upgrading, so essentially there's no support
from the app vendor anymore (despite service contracts, etc.) and 
because of that these customers aren't going to deviate from their
standard XP loads by loading the IPv6 add-on.

And, until they are all Vista they won't even think of turning on IPv6
on any of their servers, and until they do that, they aren't going to 
run IPv6 internally, or connect to the IPv6 Internet, etc.

This is what I mean when I say that XP serves as a drag on IPv6

Now I realize that these example customers aren't limiting content
providers on the Internet from running dual-stack.  But until the
users are IPv6, many content providers won't feel the incentive
to dual-stack, which I guess is just another way of saying that the 
biggest drag on IPv6 deployment is that IPv4 still works fine.

The real truth of the matter is that we are lucky that Microsoft,
Google, and the other large players who affect the Internet are all 
united behind IPv6, and all have enough time and labor invested in it 
that they are doing their part to bring it around.  But, it's just going 
to take a lot more time to get to the tipping point I think than people 


More information about the ARIN-PPML mailing list