Android (lack of) support for DHCPv6

Wed Jun 10 13:54:03 UTC 2015

The whole conversation is around 464XLAT on IPv6-only networks right?
We're going to be dual-stack for a while IMHO, and by the time we can get
away with IPv6 only for WiFi, 464 should no longer be relevant because
we'll have widespread IPv6 adoption by then.

Carriers can do IPv6 only because they tightly control the clients, for
WiFi clients are and will always be all over the place, so dual stack will
be pretty much a given for a long time.

On Wed, Jun 10, 2015 at 9:50 AM, George, Wes <wesley.george at twcable.com>
wrote:

>
> On 6/10/15, 2:32 AM, "Lorenzo Colitti" <lorenzo at colitti.com> wrote:
>
> >I'd be happy to work with people on an Internet draft or other
> >standard to define a minimum value for N, but I fear that it may not
> >possible to gain consensus on that.
>
> WG] No, I think that the document you need to write is the one that
> explains why a mobile device needs multiple addresses, and make some
> suggestions about the best way to support that. Your earlier response
> detailing those vs how they do it in IPv4 today was the first a lot of us
> have heard of that, because we're not in mobile device development and
> don't necessarily understand the secret sauce involved. This is especially
> true for your mention of things like WiFi calling, and all of the other
> things that aren't tethering or 464xlat, since neither of those are as
> universally agreed-upon as "must have" on things like enterprise networks.
> I'm sure there are also use cases we haven't thought of yet, so I'm not
> trying to turn this into a debate about which use cases are valid, just
> observing that you might get more traction with the others.
>
>
> >Asking for more addresses when the user tries to enable features such as
> >tethering, waiting for the network to reply, and disabling the features if
> >the network does not provide the necessary addresses does not seem like it
> >would provide a good user experience.
>
> WG] Nor does not having IPv6 at all, and being stuck behind multiple
> layers of NAT, but for some reason you seem ok with that, which confuses
> me greatly. The amount of collective time wasted arguing this is likely
> more than enough to come up with cool ways to optimize the ask/wait/enable
> function so that it doesn't translate to a bad user experience, and few
> things on a mobile device are instantaneous anyway, so let's stop acting
> like it's an unsolvable problem.
>
> 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.
>

-- 
Ray Patrick Soucy
Network Engineer
University of Maine System

T: 207-561-3526
F: 207-561-3531

MaineREN, Maine's Research and Education Network
www.maineren.net