Android (lack of) support for DHCPv6

George, Wes wesley.george at twcable.com
Wed Jun 10 17:54:30 UTC 2015


From: Lorenzo Colitti <lorenzo at colitti.com<mailto:lorenzo at colitti.com>>
Date: Wednesday, June 10, 2015 at 11:21 AM
To: "George, Wes" <wesley.george at twcable.com<mailto:wesley.george at twcable.com>>
Cc: NANOG <nanog at nanog.org<mailto:nanog at 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.


More information about the NANOG mailing list