Android (lack of) support for DHCPv6

[marka at isc.org (Mark Andrews)]

In message <CALFTrnNyvWssFhEJYW8mRjmkYx6i=4nZO+6r7ns5+OU5UYG8eA at mail.gmail.com>
, Ray Soucy writes:
> 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.

Or just support DS-Lite along with DHCPv6.

DS-Lite does not require its own IPv6 address.
464XLAT and DS-Lite both limit IPv4 packet sizes to less than native.
DS-Lite works with DNSSEC.  DNS64 doesn't.
DS-Lite doesn't require mucking with packet contents.
DS-Lite doesn't result in sites being unreachable just because the IPv6
instance is down which is a side effect of DNS64.
 
> 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 especiall=
> y
> > 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/enabl=
> e
> > 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=E2=80=99s mail serv=
> er, 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 th=
> at
> > 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 o=
> f
> > this E-mail and any printout.
> >
> 
> 
> 
> --=20
> 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org