Re: Android and DHCPv6 again

[Lorenzo Colitti]

On Fri, Oct 16, 2015 at 12:46 AM, Baldur Norddahl  wrote:

> Yes but Android refuses to do IPv6 if there is any DHCPv6 on the network.
> It is a bug.
>

That would indeed be a bug, but I'm not aware of such a bug. As long as the
network provides SLAAC as well as DHCPv6, IPv6 should work. If anyone can
reproduce this on a Nexus device, please file a bug.

Android 5.x does have a bug where if you send the device a default route
via RA and don't provide addressing via SLAAC (i.e., if you do
DHCPv6-only), and also have IPv6 on the cellular network, the device gets
confused. That should be fixed in 6.0.

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

On Wed, Jun 10, 2015 at 4:13 PM, Karl Auer ka...@biplane.com.au wrote:

 You need as many as you need. Request them. Worry about it if you don't
 get them. This is exactly what happens when N=1, BTW. A DHCPv6 server is
 almost certainly not going to have an upper limit that significantly
 crimps your style...


Ok, let's see how that goes, even among the few people on this thread.

Question for everyone on this thread that has said that DHCPv6 NA is a
requirement: suppose that Android supported stateful DHCPv6 addressing,
requested a number of addresses, and did not use any of them if the number
of addresses received was less than N.

What does N need to be?

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

On Wed, Jun 10, 2015 at 5:31 PM, Sander Steffann san...@steffann.nl wrote:

 I can also see more deployment issues (much more state in the routers for
 all those PDs, needing huge amounts of /64s (or larger) to be able to deal
 with a few hundred/thousand clients) but it would be very nice if this was
 possible :)


Well, in IPv4 you can do 16M devices in 10/8. You can divide IPv6 space in
exactly the same way and give every client a /64. A /24 becomes a /56, and
your 10/8 becomes a /40. A /40 is really not hard to get.

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

On Wed, Jun 10, 2015 at 8:35 PM, Ray Soucy r...@maine.edu wrote:

 In practice, your device will just not be supported.

 As you pointed out, there isn't anything that forces adoption of IPv6
 right now.


It's certainly a possibility for both sides in this debate to say my way
or the highway, and wait and see what happens when operators start
removing support for IPv4.


 I'm perfectly find NATing Android, and don't see us giving up the
 operational benefits to DHCPv6 anytime soon.


Oh, I definitely see that DHCPv6 is easier for network operators.

But even if you're dead set on using DHCPv6, what I don't see is why don't
you support DHCPv6 PD instead of IA_NA? It's the same amount of state. Same
accountability. Same transaction model. But unlike NA, the device gets as
many addresses as it needs. Nothing breaks, and you get future flexibility.
Mobile devices don't have to implement NAT, and application developers
don't have to work around it. You size your IPv6 pools based on the size of
your IPv4 pools, and don't run out of addresses. Technically, that sort of
arrangement is superior to IA_NA in basically every way. So... why use
IA_NA?

Even if the answers are that's what we do in IPv4, and we want to do it
the same way, or we're worried that this is strange and will tickle
vendor bugs, it's not supported by the IPAM we use today, or this is
what we've decided, our network our rules, I would hope that we as an
industry can think a little longer term than that.

Also, in terms of hotspot functionality being the major driver


Don't think about yesterday, think about tomorrow. Tethering and 464xlat
are just two examples of what can be done when you have the ability to use
more than one IPv6 address and cannot be done without that. We know these
will break today; tomorrow, we can use multiple addresses to do things we
haven't thought of yet.

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

On Wed, Jun 10, 2015 at 8:30 PM, Karl Auer ka...@biplane.com.au wrote:

 Seems to me that N will vary depending on what you are trying to do.


Remember, what I'm trying to do is avoid user-visible regressions while
getting rid of NAT. Today in IPv4, tethering just works, period. No ifs, no
buts, no requests to the network. The user turns it on, and it works.
IPv4-only apps always work.

A model where the device has to request resources from the network before
enabling tethering, or before supporting IPv4-only apps, provides a much
worse user experience. The user might have to wait a long time, or the
operation might even fail.

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

On Wed, Jun 10, 2015 at 9:31 PM, Tore Anderson t...@fud.no wrote:

 In particular comment 105 is illuminating. Android is apparently fully
 on-board with mobile carriers' desire to break tethering, even going so
 far as to implement a feature whose *sole purpose* is to break
 thethering.

 Yet, at the same time, you refuse to implement DHCPv6 on WiFi because it
 *might*, as a *side effect*, break tethering. This does not strike me
 as very consistent.


Tethering is just one example that we know about today. Another example is
464xlat. And that's not counting future applications that can take
advantage of multiple IP addresses that we haven't thought of yet, and that
we will have if we get stuck with
there-are-more-IPv6-addresses-in-this-subnet-than-grains-of-sand-but-you-only-get-one-because-that's-how-we-did-it-in-IPv4
networks.

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

On Wed, Jun 10, 2015 at 10:06 PM, Ray Soucy r...@maine.edu wrote:

 Actually we do support DHCPv6-PD, but Android doesn't even support DHCPv6
 let alone PD, so that's the discussion here, isn't it?


It is possible to implement DHCPv6 without implementing stateful address
assignment.

If there were consensus that delegating a prefix of sufficient size via
DHCPv6 PD of a sufficient size is an acceptable substitute for stateful
IPv6 addressing in the environments that currently insist on stateful
DHCPv6 addressing, then it would make sense to implement it. In that
scenario, Android would still not implement DHCPv6 NA, but it would
implement DHCPv6 PD.

What needs to be gauged about that course of action is how much consensus
would be achieved, whether network operators would actually use it (IPv6
has a long and distinguished history of people claiming I can't support
IPv6 until I get feature X, feature X appearing, and people changing their
claim to I can't support IPv6 until I get feature Y), and how much of
this discussion would be put to bed.

That course of action would seem most feasible if it were accompanied by an
IETF document that explained the deployment model and clarified what
sufficient size is.


 Universities see a constant stream of DMCA violation notices that need to
 be dealt with and not being able to associate a specific IPv6 address to a
 specific user is a big enough liability that the only option is to not use
 IPv6.


It's not the *only* option. There are large networks - O(100k) IPv6 nodes -
that do ND monitoring for accountability, and it does work for them. Many
devices support this via syslog, even. As you can imagine, my Android
device gets IPv6 at work, even though it doesn't support DHCPv6. Other
universities, too. It's obviously  not your chosen or preferred mechanism,
but it does work.

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

On Wed, Jun 10, 2015 at 12:37 PM, Karl Auer ka...@biplane.com.au wrote:

 RFC 3315 says you just chuck in multiple IA_NA (or IA_TA) options. The
 server will respond with multiple addresses.

 And if a device makes a second (, third, fourth, ..) request with a
 different DUID, it'll get a second (,third, fourth,...) address oo, I
 guess.


It's certainly possible to make Android request N IPv6 addresses via
DHCPv6, and not accept the offer if it is offered fewer than N addresses.
But that only really makes sense if there's a generally-agreed upon minimum
value of N. 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.

It's also possible for Android to support DHCPv6 PD. Again I'd be happy to
work with people on a document that says that mobile devices should do
DHCPv6 PD and not DHCP NA, and then implement DHCPv6 PD. But I fear similar
arguments will be had there.

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.

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

On Wed, Jun 10, 2015 at 2:36 PM, Hugo Slabbert h...@slabnet.com wrote:

 Pardon my ignorance as I don't currently have field experience with
 464xlat, but my understanding of the technique is that it is (for the most
 part) dependent on the network cooperating (by providing a DNS64 and NAT64)
 for it to work properly.


My point was not on a SLAAC network, it's possible to implement 464xlat.
It was, on a one-address-per-device network, it's impossible to support
464xlat.

Here, 464xlat is just an example of a new technology that needs a separate
IP address in order to function. There are other current examples, and
unless we get stuck in a one-address-per-device word, there will be future
examples too.

Multiple posters on the bug/request are coming from enterprise/campus
 networks that have existing AUPs and enforcement techniques prohibiting
 certain network functions (e.g.  content filtering, restricted outbound
 access, etc.), and would be making an *active choice* as to whether they do
 or do not want to support functions such as tethering, 464xlat, etc.


Sure, but today, it is not common practice for networks to prohibit a
device from tethering or from using IPv4-only applications on user-managed
devices. From a user's point of view, going to a world where such things
are prohibited is a regression.

And there it is:  SLAAC is better and it isn't that hard; use it
 instead.  It is up to the network operator to make the design choices that
 best fit their network, including if their design goals are to *restrict*
 certain network functions.  You are saying that you know better.


I don't think that's a useful argument to make, since you are also saying
that you know better.

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

On Wed, Jun 10, 2015 at 3:38 PM, Tony Hain alh-i...@tndh.net wrote:I
claim that there is a platform bug, because there is never a reason to

 ignore the WiFi RA. Use the other flag to set a preference if that is
 needed, but ignoring the RA just breaks things in unexpected ways. LC has
 did a hand-wave that the ignore RA flag is needed for battery life, but
 beyond that we appear to be stuck in a world where Clueless OEMs believe in
 breaking one network when another might exist.


This is not how current Android works. Each network can run IPv4, IPv6 or
both independently of any other network. If you can reproduce this on a
device running current Android (preferably a Nexus device), please file a
bug.

There is indeed an issue with OEMs dropping RAs when the screen is off.
Because it is the OEM that provides the wifi firmware and not Android, it's
not really fair to say it's an Android bug. FWIW, recent Nexus devices do
not have that bug.

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

On Wed, Jun 10, 2015 at 3:49 PM, Jon Bane j...@nnbfn.net wrote:

 Seriously, this is how you are going to respond?  You are claiming you
 know what is best for everyone and I am telling you that I know is best for
 MY network. Who are you to even begin to understand my requirement or
 presume to know them better?


Forgive me, I thought you were saying that you know what operating systems
need to do. If that's not what you were saying, then please ignore that
part of my reply.

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

On Thu, Jun 11, 2015 at 12:35 AM, Tore Anderson t...@fud.no wrote:

  And that's not counting future applications that can take
  advantage of multiple IP addresses that we haven't thought of yet, and
 that
  we will have if we get stuck with
 
 there-are-more-IPv6-addresses-in-this-subnet-than-grains-of-sand-but-you-only-get-one-because-that's-how-we-did-it-in-IPv4
  networks.

 Of course. Hard to argue against imaginary things. :-)


I think imaginary is the wrong word here. There's a difference between
imaginary things and leaving room for for future innovation. Phone network
model vs. Internet model is the usual example that comes to mind.


 On the other hand, there exist applications *today* that do require
 DHCPv6. One such example would be MAP, which IMHO is superior to
 464XLAT both for the network operator (statlessness ftw) as well as for
 the end user (unsolicited inbound packets work, no NAT traversal
 required). MAP is provisioned with DHCPv6 (I-D.ietf-softwire-map-dhcp),
 so without DHCPv6 support in Android, MAP support in Android is a
 non-starter.


Support for the DHCPv6 protocol, or support for assigning addresses from
IA_NA?

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

On Thu, Jun 11, 2015 at 12:36 AM, Jeff McAdams je...@iglou.com wrote:

 Then you need to be far more careful about what you say. When you said
 Android would still not support... you, very clearly, made a statement of
 product direction for a Google product.


Did you intentionally leave the in that scenario, words that came right
before the ones you quoted?

How does a sentence that says in that scenario, android would X
constitute a statement of direction?

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

On Wed, Jun 10, 2015 at 10:25 PM, George, Wes wesley.geo...@twcable.com
wrote:

 The reality is that this whole argument is needlessly conflating multiple
 things in a way that isn't helpful, so I'm going to try to break this into
 pieces in order to make forward progress and try to get us away from what
 is devolving into a debate that is equal parts religion and kool-aid
 drinking contest among IPv6 übernerds.


Thank you for trying to reword what I tried to express. Your assessment
pretty much matches mine, except for the conclusion (see below).


 So what this means is that there is a draft to be written about the need
 for multiple address support on IPv6 networks for mobile devices,
 enumerating the ways that they use those multiple addresses, and how it
 differs from today's IPv4-only or dual-stack implementations, along with a
 big discussion on the breakage that can happen on IPv6-only networks if a
 device can't get the addresses it needs. It is a fool's errand to assume
 that we can dictate one and only one solution to #5 (regardless of one's
 perceived influence and market power), so the best we can do is to
 document the preferred one(s) and hope that we've made a good enough case
 or made them easy enough to use that the majority of network operators do
 support them.
 Sunset4 is the right place for that draft, so let's discuss it at the next
 IETF.


Yep (but perhaps in v6ops instead of sunset4, see below).


 However, the spectre of #4 does NOT mean that DHCPv6 is unusable because
 it would break things today on a dual-stack network, so you need to stop
 trying to imply that, and stop trying to optimize for use cases that you
 yourself admit basically don't exist today by blocking support for
 something that we could use today to have more devices using IPv6, were it
 available.


I disagree with this part of the conclusion. 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.

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

Ray,

please do not construe my words on this thread as being Google's position
on anything. These messages were sent from my personal email address, and I
do not speak for my employer.

Regards,
Lorenzo

On Thu, Jun 11, 2015 at 12:15 AM, Ray Soucy r...@maine.edu wrote:

 Respectfully disagree on all points.

 The statement that Android would still not implement DHCPv6 NA, but it
 would implement DHCPv6 PD. is troubling because you're not even willing to
 entertain the idea for reasons that are rooted in idealism rather
 than pragmatism.

 Very disappointing to see that this is the position of Google.


 On Wed, Jun 10, 2015 at 10:58 AM, Lorenzo Colitti lore...@colitti.com
 wrote:

 On Wed, Jun 10, 2015 at 10:06 PM, Ray Soucy r...@maine.edu wrote:

 Actually we do support DHCPv6-PD, but Android doesn't even support
 DHCPv6 let alone PD, so that's the discussion here, isn't it?


 It is possible to implement DHCPv6 without implementing stateful address
 assignment.

 If there were consensus that delegating a prefix of sufficient size via
 DHCPv6 PD of a sufficient size is an acceptable substitute for stateful
 IPv6 addressing in the environments that currently insist on stateful
 DHCPv6 addressing, then it would make sense to implement it. In that
 scenario, Android would still not implement DHCPv6 NA, but it would
 implement DHCPv6 PD.

 What needs to be gauged about that course of action is how much consensus
 would be achieved, whether network operators would actually use it (IPv6
 has a long and distinguished history of people claiming I can't support
 IPv6 until I get feature X, feature X appearing, and people changing their
 claim to I can't support IPv6 until I get feature Y), and how much of
 this discussion would be put to bed.

 That course of action would seem most feasible if it were accompanied by
 an IETF document that explained the deployment model and clarified what
 sufficient size is.


 Universities see a constant stream of DMCA violation notices that need
 to be dealt with and not being able to associate a specific IPv6 address to
 a specific user is a big enough liability that the only option is to not
 use IPv6.


 It's not the *only* option. There are large networks - O(100k) IPv6 nodes
 - that do ND monitoring for accountability, and it does work for them. Many
 devices support this via syslog, even. As you can imagine, my Android
 device gets IPv6 at work, even though it doesn't support DHCPv6. Other
 universities, too. It's obviously  not your chosen or preferred mechanism,
 but it does work.




 --
 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

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

On Tue, Jun 9, 2015 at 12:14 PM, Paul B. Henson hen...@acm.org wrote:

 https://code.google.com/p/android/issues/detail?id=32621

 It looks like one developer simply refuses to implement it because if he
 did there might be a scenario where somebody might not be able to tether
 8-/?


That sounds pretty stupid even for me, so probably something got lost in
translation.

I think what I said is that supporting DHCPv6-only networks will eventually
force OS manufacturers to implement IPv6 NAT. This is because there are
many features inside a mobile OS that require multiple IP addresses. One
example is 464xlat. Another example is tethering (and no, much as network
admins would like that, users and product management will *not* accept that
tethering is disabled because the network does not provide enough IP
addresses - they will just want the feature to work, even if it breaks
apps some of the time). Another example is any function that mostly lives
on a mobile device's baseband processor and needs to access networks that
are connected through the application processor (e.g., wifi calling, ePDG
access, etc.)

In IPv4 we use NAT for all that, and that's unavoidable due to lack of IPv4
space. That reason does not apply in IPv6 though. With SLAAC or DHCPv6 PD,
these functions can use their own IPv6 addresses. With stateful DHCPv6
addressing, we're back to using NAT again. That means application
flakiness, battery impact due to NAT keepalives, and so on.

It also means that things that don't work behind NAT (e.g., 464xlat, which
requires its own IPv6 address) cannot be made to work at all.

His attitude is that you have to use SLAAC and RDNSS, which we're
 just not going to do.


You don't have to do SLAAC and RDNSS. For as long as the network provides
IPv4, there won't be a problem for anyone. And I assume you're not planning
on turning off IPv4 tomorrow, because a whole lot of things will stop
working if you do that

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

On Wed, Jun 10, 2015 at 12:26 PM, Jon Bane j...@nnbfn.net wrote:

 DHCPv6 - RFC3315 - Category: Standards Track
 464XLAT - RFC6877 - Category: Informational


Ooo, that's fun, can I play too?

BGP - RFC 4271 - DRAFT STANDARD
USM for SNMPv3 - RFC 3414 - INTERNET STANDARD

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

On Wed, Jun 10, 2015 at 3:20 AM, Ray Soucy r...@maine.edu wrote:

 Clients should support a verity of methods and let network operators choose
 the solution that fits the environment.  The whole premise for not
 supporting DHCPv6 seems to be that mobile networks don't need it, but that
 totally ignores 802.11 which is equally important.


No, the premise is that from a user's point of view, DHCPv6-only networks
cause regressions in functionality compared to IPv4-only or dual-stack
networks. For example: IPv4 apps cannot be supported at all due because
464xlat cannot be made to work, and functions such as tethering cannot be
implemented because there are no IP addresses to assign to downstream
devices.

Implementing IPv6 NAT can resolve some but not all of these regressions
(for example, IPv4 apps still cannot be supported). Thus, attempting to
operate on DHCPv6-only networks a) will create pressure to implement IPv6
NAT, which causes lots of issues like application complexity, battery life
issues due to keepalives, etc. b) impose user-visible regressions even if
we do implement IPv6 NAT.

From a user's point of view, that's just a bad deal, especially since
IPv4-only networks, dual-stack networks, and IPv6-only networks using SLAAC
do not have any of those issues. Stateless DHCP and stateful DHCPv6 PD have
none of those issues, either. If we really need stateful addressing, then
we should statefully assign prefixes, not single addresses.

I understand that stateful-one-address-per-device-DHCPv6-only is easier
for network operators, but SLAAC really isn't that much harder, and in the
long run, we'll get more robust apps, better battery life, more innovation,
and happier users.

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

On Wed, Jun 10, 2015 at 6:56 AM, Owen DeLong o...@delong.com wrote:

 At the end of the day, I see Androids refusal to implement DHCPv6 as about
 the same level of stupidity as Apple’s refusal to implement 464XLAT in iOS.


Based on the facts, you could could just as well say that Apple is trying
to advance the state of the art by refusing to provide suboptimal 464xlat
and insisting instead that developers support IPv6-only networks as
first-class citizens:

https://twitter.com/dteam69/status/608036976990797824

By the same token, you could argue that not supporting statful DHCPv6
address assignment advances the state of the art by trying to avoid
slipping back into a one-address-per-device-NAT-required world.

Re: Microsoft's participation in World IPv6 day

[Lorenzo Colitti]

On Sun, Jun 5, 2011 at 11:24 PM, Owen DeLong o...@delong.com wrote:

 Moving them to IPv6 and hoping that enough of the content providers
 move forward fast enough to minimize the extent of the LSN deployment
 required.


The problem here is not content, it's access. Look at World IPv6 day.
What percentage of web content is represented? Probably order of 10%.
How about access? Our public stats still say 0.3%

Re: Yahoo and IPv6

[Lorenzo Colitti]

On Tue, May 10, 2011 at 11:22 AM, Owen DeLong o...@delong.com wrote:

 In other words, Igor can't turn on  records generally until there are
 182,001 IPv6-only users that are broken from his lack of  records.


There will be no IPv6-only users. There will only be users with better IPv6
connectivity than IPv4 connectivity.


 This will be interesting. Personally, I think it will be more along the
 lines
 of when there are more IPv6 only eye-balls with broken IPv4 than there
 are IPv4 eye-balls with broken IPv6,  will become the obvious
 solution.


Agreed. The problem is how to get there. Given that 0.2% of Google users has
IPv6 today, my money is still on this taking a while.