Re: Android (lack of) support for DHCPv6

["George, Wes" <wesley.george () twcable com>]

From: Lorenzo Colitti <lorenzo () colitti com<mailto:lorenzo () colitti com>>
Date: Wednesday, June 10, 2015 at 11:21 AM
To: "George, Wes" <wesley.george () twcable com<mailto:wesley.george () twcable com>>
Cc: NANOG <nanog () nanog org<mailto:nanog () nanog org>>
Subject: Re: Android (lack of) support for DHCPv6

"I don't think it's a good plan to implement stateful DHCPv6 now and postpone the solution of the problem until IPv4 
goes away many years from now. By then, a lot of water will have flowed under the bridge by then, and a lot of 
one-address-only networks will have been deployed and have moulded industry thinking.

So, much as it pains me to stand in the way of IPv6 adoption - and you should how much I've tried to do on that front - 
I think that that wide deployment of one-address-per-device IPv6 might actually do more harm than good, and I expect 
that many operators who are going to require stateful DHCPv6 addressing are going to use it for one-address-per-device 
IPv6.

I really think it's better if we get this right now, not kick the can down the road. That means we as an industry need 
to find a solution for IPv6 deployment in university/enterprise networks that does not devolve into 
one-address-per-device IPv6, *before* one-address-per-device IPv6 becomes universally implemented and usable."

WG] I wasn't suggesting kicking the can. I agree that we need a solution, and getting started on it now so that the 
guidance and potential solutions are available as soon as possible is the right plan, because it reduces our potential 
reliance on IPv4 as a fallback for those things that need multiple addresses today. However, I think you're going to 
have a lot of trouble building consensus for your view that the right response is to try to completely block 
one-address-per-device IPv6 deployment by any means possible, and I think you're going to have even less success 
actually doing it, given that most other devices have already built support for it.
Turning off IPv4 on a dual-stack network is a major change, as complex (or more) than deploying IPv6 to start with, 
especially if you haven't been focused on getting everything using IPv6 so that it's not dependent on IPv4, not to 
mention those unpredictable users. So I don't think it's unreasonable to expect that some changes to the existing IPv6 
deployment will be necessary to support such a thing, and therefore I disagree with your assertion that allowing 
one-address-per-device in the short term will lead to unsolvable problems later, due to inertia or otherwise. It's also 
not guaranteed that everyone doing stateful DHCPv6 will limit devices to one address, so we need to be a bit careful 
with the prognostications of universal doom.

Rhetorical question: given the growing evidence that IPv6 is often lower latency than IPv4, and Google's heavy focus on 
improving performance for user experience (page load times, SPDY, etc) especially in the mobile space, how long do you 
think you'll really be able to justify not supporting IPv6 on a subset of deployments to avoid the risk of future 
tragedy before you're overruled by the potential to shave off a few more ms of latency?

Thanks,
Wes

Anything below this line has been added by my company’s mail server, I
have no control over it.
----------

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, 
confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the 
individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby 
notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments 
to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the 
sender immediately and permanently delete the original and any copy of this E-mail and any printout.