IssueTracker

Thank you for reporting this issue.

Please provide below details for further investigation.

1. Android bug report
After reproducing the issue, press the volume up, volume down, and power button simultaneously. This will capture a bug report on your device in the “bug reports” directory. Attach the bug report  file to this issue.
 
Alternate method:
After reproducing the issue, navigate to developer settings, ensure ‘USB debugging’ is enabled, then enable ‘Bug report shortcut’. To take bug report, hold the power button and select the ‘Take bug report’ option.

Here's the bug report:

https://drive.google.com/file/d/0Bwtin12AI0QsOThyZk5xQTZMYkk/view?usp=drive_web (bugreport-marlin-OPP2.170420.019-2017-06-02-07-43-29.zip)

@Carl Csaposs, Please grant permission to the link shared.

Sorry, forgot about that.

Done.

Thank you for reporting this issue. We have shared this with our product and engineering team and will update this issue with more information as it becomes available.

Also a thread here with many others having this issue. https://productforums.google.com/forum/?utm_medium=email&utm_source=footer#!msg/phone-by-google/DyxZwJpsOwY/1Ifdn669AAAJ

I have a bug report as well. What email do I share it with?

Just wanted to add something.  After a system update (this occurred on Android O DP 3 and 4) the problem is not present until the device is restarted.

Happens on Nexus 5X as well

This feature appears to have been removed in a 7.1.2 update and is still gone in the 8.0.0 (Oreo) update I just installed on my Pixel.

A few more places where others are having issues.

https://forum.xda-developers.com/galaxy-s8+/help/smart-lock-add-nfc-tag-t3661494
https://android.stackexchange.com/questions/166912/smart-lock-unreliable-not-working-with-nfc-tag/182749

This feature is also completely missing on my Nexus 5X running 8.0.0.  When I was running 6.0.1 the feature was present and working.  Looks like Google needs to fix this bug + write some regression tests.

Since my issue involves a missing feature, I created a separate ticket here: https://issuetracker.google.com/issues/65425413

We've deferred this to a future release, but leaving this open for now.

Fyi, the docs still say this is a valid feature. https://support.google.com/nexus/answer/6093922?hl=en

Experiencing same issue.
Based on steps provided here (steps 17 and 18): https://videotron.tmtx.ca/en/topic/samsung_galaxys7/using_trusted_devices_to_unlock_your_phone.html#step=17
I suppose that the problem here in displaying bluetooth devices after clicking on "add trusted device" (missing menu with selecting type of device NFC or Bluetooth), because on my phone, if bluetooth is enabled, here displayed bluetooth devices, there is no any NFC even when bluetooth disabled.
Based on other steps provided in videos and manuals, when bluetooth disabled - it's displayed in the menu (that missing) as inactive (grayed out), but on my phone even this option is not displayed.

#17 see here: https://issuetracker.google.com/issues/65425413

Google trashed the feature and didn't let anyone know.

It took me a while to find a decent NFC ring and now you take it way?  Please fix this.

Way to take great features that worked that people used and rely on and remove. Glad to know my NFC ring I used every day to unlock my phone is now useless and it is way more safe than setting my watch as a trusted bluetooth device, which I can be 20 feet away from my phone and someone still unlock it.

SmartLock NFC feature has been deprecated for new users. If you are not existing NFC users, the option will be hidden.

I argue this is not intended behavior. I'm on a Nexus 6 that is not supposed to get feature updates but security updates. Removing a feature is no different than adding one and there has been no techical explanation as to why NFC smart Lock would be a security threat compared to on body detection or voice.

It was advertised that Google brand phones could use NFC for smart unlock. If you want to depreciate NFC, you should announce it and only remove on your next phone or major OS upgrade.

My nfc ring broke a few weeks ago and I finally got my replacement only to find I can't register it. Is google willing to reimburse me for the cost of the ring since they silently removed an advertised feature?

I got an NFC-chip implanted in my left hand and the primary function was to unlock my Android phone with it. With the built in NFC readet/writer and not locking it down like Apple made me stick to Android. If there is a way to show this hidden feature that would be great. As a developer I know features often get axed for lack of usage or simplifying UI. Any tip on app or patch would be appreciated.

Thanks a lot Roy. I could found out that stateful and stateless auto config is well supported in your new releases(ref. commit history). Sorry for the confusion though.

My development is in android 4.2. Android starts dhcpcd when a link UP.
I am facing bit of issues here after porting your 6.1 version.
Firstly I dont get RA packets received by dhcpcd(confirmed that dhcpcd sends RS by disabling ra_accept proc entry) although router sends RA with managed bit. I am using ipv6ra_own.

Next, If RA not received, doesnt dhcpcd start dhcp solicit?

What should be dhcpcd conf options for below behavior?  
-Initiates RS (may be overriding kernel) and wait for RA flag(O/M) info, and accordingly starts auto config or other config to dhcp server.
-If no RA, then start auto configuration of host address and other information.

By default dhcpcd will only start DHCPv6 negotation on receipt of a RA
message.
This is because DHCPv6 doesn't carry any prefix or routing options.

I don't have an Android development environment, but the dhcpcd code that
sends RS and listens to RA has no specific platform code and freely works
on both Linux, NetBSD and FreeBSD.
As such it's likely to be an issue with the Android kernel or system
headers.
Now, you mentioned you "ported" the 6.1 version. So does this mean you have
modifications to the dhcpcd code to get it to compile? Can I see the
vanilla compile output and any patches you have made?
Specifically, dhcpcd sets up a kernel filter to block all ICMP traffic on
the socket, but then allow the RA through. This is found here:
http://roy.marples.name/cgi-bin/gitweb.cgi?p=dhcpcd.git;a=blob;f=ipv6nd.c;h=b066112b371b3c19d66c196b906304cf34d160cc;hb=a0fd4f6ee8d50599ae194d5c979331ff551cc588#l166
So if there is any problem compiling that part I'm not suprised it doesn't
work.
You could try removing the filter and filtering in the ipv6nd_handlera
function directly, but this of course is more overhead for dhcpcd.

But really I would try and fixing the kernel or headers. A possible
solution can be found here:
https://android-review.googlesource.com/#/c/58438/

[Comment deleted]

Thanks Roy. This works with that header fix for android; opposite flags value in contrast with BSD.

Further while m trying to keep a standard configuration for the client, what do u think standard dhcpcd client configuration options for address configuration for statefull as well as stateless (considering with standard router and dhcp server configured)?
Attached is current conf m using.

Glad that works! Can you revert your change and test the latest dhcpcd git
HEAD, or the below patch
http://roy.marples.name/cgi-bin/gitweb.cgi?p=dhcpcd.git;a=blobdiff;f=ipv6nd.c;h=e15004e87eac6884adc7df1fd8e105365aeffc46;hp=b066112b371b3c19d66c196b906304cf34d160cc;hb=760f4b28de2e23198fb797b967c7d9dd740c2605;hpb=59e645fc2939eb41538083a54a59c94084182ceb
Hopefully it will work fine now.

As to the config file, what is wrong with the default one I ship? It should
work fine for all DHCPv4/DHCPv6 cases.
Why would you want to change it for Android?

Roy

Still missing in 4.4.2.

dhcpcd-6.2.0 has been released which should fix the IPv6 ICMP problem with
Android headers

Stateless DHCPv6 support would be better than just supporting RA RDNSS, as DNS is not the only application parameter useful to a host. Some other examples that people might want to set via Stateless DHCPv6 are NTP or SIP server addresses, timezone or geolocation information or many of the other options supported by DHCPv6:

http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml

IMHO, the DNS related options being added to RAs is both a mistake and short sighted.

http://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00#section-2

I don't see where anyone is saying to support just RA DNSSS. Android needs to support both. I couldn't care less about NTP / SIP servers.

Having a working network is a mistake and short sighted? Odd logic.

Hello everyone,

where can I find the pre-compiled binary of a dhcp server for IPv6 for Android ?

Any progress here?

No support for DHCPv6, but RDNSS is now supported, so you can use that.

RDNSS is addressed in another bug report: https://code.google.com/p/android/issues/detail?id=32629
This bug report is for DHCPv6, which is needed in certain enterprise environments.

Also, RDNSS only covers DNS server information. DHCPv6 also covers addressing. I've just discovered this is the default in the recently released OpenWRT Barrier Breaker.

Eh? Addressing has always been part of IPv6 autoconf. RDNSS just means
DHCPv6 is entirely optional for a pure IPv6 environment.

So now it's basically a choice between stateful and stateless, but stateful
is more readily extensible.

It's a bit off topic, but can anyone please check if connection to IPv6-only networks is functional now?

Big wireless carriers either have already or are moving to offload phone calls from their networks to Wi-Fi where its now not just end users needing support for a widely implemented IPv6 addressing & configuration standard: DHCPv6.

There already is a widely implemented IPv6 addressing & configuration standard.. it's called SLAAC + RFC6106.

comment 41: RDNSS (RFC6106) has been addressed in issue 36949093, now closed.

Microsoft, Apple, and all major desktop Linux vendors support RFC 3315 as has been requested in this issue. Microsoft does not support RFC 6106, but is perhaps more "widely implemented" than Android, especially in enterprise environments.

Without support for DHCPv6, Android is ignoring two rather important flags (M and O) in the router advertisement. Android can and should support both stateless and stateful address management and both methods of DNS resolver (and other parameter) conveyance. DHCPv6 is support is necessary.

@c#41

Independent of the facts what other typical client OS do - the situation on typical servers is ugly. (cisco doesn't support RFC6106, or in very rare cases until now). I also have two mobile routers (LTE-WIFI) which provide only dhcpv6.
In case of my DSL-Router I have the choice. But in most cases I will not have a choice. I have to accept the network situation as it is. Here it would me more than "useful" to have a flexible client.

By the way what are the plans for tethering/hotspot in "pure" android?
dhcpv6 for windows and RDNSS via SLAAC for the rest?

Or just only one of them again?

At the moment I can only "share" my already shared IPv4-Adress. (cgnat+nat)





 

Cisco does support this standard with latest M and T train IOS's for ISR routers (15.4(3)M and 15.5(1)T definitely and maybe earlier, including LTE 819 series routers), and E train code (15.2(2)E and maybe earlier) that runs on most access switches such as the 3560X/3750X.  I know this as I have it configured and functioning on both.  I don't think I'd consider that to be "rare" - just "new".

You can expect this to be more widely available in the future as end customers upgrade their devices to these later versions of code or above.  It's there on these current releases and all going forward for those who want to upgrade now.

I would of course prefer DHCPv6 to be properly supported by Android though.

cisco was only one example. "My" network-Admin at work is not able to switch on RDNSS via RA.
cisco itself has not updated their documentation.

The LTE-Hotspots I have, are not from cisco.

My message was: As a user I have no influence on the network I want to participate.

While the big players fight about the "right" standard, the customer runs in avoidable problems.
At the moment they are covered by dualstack, and IPv6-only is also to be rare - or just "new".

I recommend filing a new item for IPv6/IPv6-only support in tethering, since that is Android as server rather than as client. Related, but different.

Unfortunately, key developers on Android have a religious opposition to DCHPv6, so unless that changes, the reality is that if one wishes to operate an IPv6 only network && support Android, one will support RDNSS. Until there is full support for RDNSS, since nearly all networks are still dual stack DNS info can be provided via DHCPv4. I agree that it is important to support IPv6 only, but I'm forced to admit that in the wild, it's a largely theoretical problem, one that the average user is unlikely to encounter until RDNSS support (and Lollipop deployment) is more common.

Lease reservations are a must in some networks. Reservations can be done with DHCPv6. Can reservations be done with the alternative?

How is this obsolete?  Is there another issue for tracking DHCPv6 support?

Obsolete?! Obsoleted by what? This was NOT fixed in Lollipop. Please re-open this issue or explain.

It is strange this was marked obsolete.  e...@google.com has set a large amount of IPv6 related issues as obsolete.

Implementing stateless DHCPv6 does not provide much in the way of additional functionality above what Android 5.0 supports. The lack of stateless DHCPv6 is not a blocker for deploying IPv6-only networks, because Android 5.0 supports IPv6-only operation using RDNSS. Stateless DHCPv6 does support communicating other options than just DNS, but Android doesn't currently support such options in IPv4 either.

Implementing stateful DHCPv6 would break planned use cases such as IPv6 tethering (which would require implementing IPv6 NAT in order to work with DHCPv6) and 464xlat on wifi (which requires that the device be able to use more than one IPv6 address). It also has greater privacy implications than stateless autoconfiguration and DHCPv4. Stateful DHCPv6 will provide the ability to connect to IPv6-only networks that don't use RDNSS, but because stateful DHCPv6 will in general not provide the two IPv6 addresses that are required to run native and 464xlat, such a network will not support IPv4-only applications; this will impact users, because they won't be able to use applications such as Skype, Hangouts, and many others.

It's not clear whether implementing DHCPv6 provides the user with benefits that outweigh the above disadvantages. Marking as declined until there is a compelling use case.

@c#53 The issue with this logic is that it seems to ignore that people will/are deploying networks with DHCPv6, and without RDNSS.  Users with Android handsets are unable to join to these networks.  Android only implementing support for a subset of IPv6 deployment scenarios doesn't seem like it's helping anyone, and I'm really struggling to see how users joining a stateful DHCPv6 network being unable to tether with IPv4 support is worse than not being able to join the network at all.

I think you are focusing too much on the stateful/stateless aspect.  We need DHCPv6 addressing.  Period.  Comparing stateless v6 to IPv4 is a bit silly, btw.

How does implementing DHCPv6 support prevent multiple addresses?  I know on my personal network where I have AdvManaged and AdvAutonomous configured in RA, that every thing ends up with two or more addresses.  DHCPv6, SLAAC, and PE if enabled.  Why do you specifically think Android won't have the same behavior?

What greater privacy issues does DHCPv6 have over slaac? Someone is going to get a MAC address, no.  There is no MAC by default. DUID-LLT is a LL+Time hash. Also, there is the option for temporary addresses in DHCPv6.  Frankly, IP privacy is a joke anyway.  If I wanted to track someone, I would simply use their browser or their OS fingerprints.  IPs and MACs are trivial to change.  

Support for RDNSS and completely separate from support DHCPv6 options.  They can absolutely co-exist.  What problem have you seen to draw the conclusion that they don't?

IPv6 NAT?  How does DHCPv6 require NAT anymore than SLAAC would?  Go talk to Comcast if you need evidence that DHCPv6 on the upstream interface and "tethering" work just fine.

If you think there are insurmountable problems with DHCPv6 support, lay them out here for the community.  Your arguments thus far, seem spurious.

As for the use case.  I don't want to deal with PE addressed hosts on my managed network.  There is the use case.  Period.  Android in the enterprise is real and by not supporting DHCPv6, a known and accepted standard, you are making management of my network more difficult.  It isn't for you to decide which is better to meet the needs of your users.  It is for you to simply meet our needs.  Our needs are full support of all IPv6 addressing and options.

Lorenzo, your comment about breaking tethering puzzles me. As I understand it, Isn't that one of the key use cases of DHCPv6, specifically Prefix Delegation? RFC 6877 and RFC 7278 both seem to suggest that DHCPv6-PD is the proper way to obtain addressing for the CLAT/tethernet network, and that the current state of affairs is just temporary workarounds.

AFAIK 3GPP rel-10 and onward describes DHCPv6, cf. RFC 6459 section 5.2.

Tore

Really, Google has a problem with PRIVACY!? :)
Does Google mean "we do not like it when other people can track ALSO track folks, only we should do it".


More seriously:

If the *USER* decided that DHCPv6 causes privacy issues for them, then provide the option (just a checkmark) to enable/disable DHCPv6.

As for the 'tethering' argument, DHCPv6-PD is the perfect way to get more addresses. (that upstream routers will not support that is a different beast, and likely you will support that by bridging the interface instead).

As for multiple addresses: you can easily run multiple DHCPv4 and DHCPv6 clients on the same link and get multiple addresses (in IPv4 one creates a secondary interface with a new MAC, in IPv6 one can also just use a new DUID).


As what folks mean with "DHCPv6 addressing" is that they want the clients to get <prefix>::5 and <prefix>::6 as they do not want to see large EUI-64 or otherwise semi-random 64bits of ID there. (Note that there is no MAC or anything else there, hence more 'private' than EUI-64 based addresses


As for:
> this will impact users, because they won't be able to use applications such as Skype, Hangouts, and many others.

Maybe it is time that those properties upgrade to support IPv6? :)
You know, it is 2014....

And Hangouts is mostly a web-application, thus what is the issue there? WebRTC supports it just fine, thus why can't you? Stating that other tools are not IPv6 capable that are totally unrelated to DHCPv6 is not an excuse to mark DHCPv6 support as 'obsolete'.


As you ask for it, your compelling use cases:
 - networks are deploying DHCPv6 and requiring it for clients to join networks
 - DHCPv6-PD is *THE* method for getting more prefixes automatically (eg, for tethering)


Thus can you please add a UI element "DHCPv6" in the Network configuration and 'apt-get install wide-dhcpv6' ? :)
Would be quicker doing that than discussing this matter... (WIDE edition is BSD licensed, so you don't have to worry about the license nonsense unless you know of a patent issue that nobody else knows about)

@#56
I think DHCPv6-PD on 3GPP and wifi/wlan is wishful thinking.
(maybe the customer has to pay extra for more prefixes, the "standard"user will not see more than one prefix)

the situation is:
mobile broadband (one /64) works with clat or without clat (dualstack)

clat is disabled for WLAN at the moment (without having dhcpv6!)

wlan IPv6-only works with SLAAC/RDNSS
wlan IPv6-only based on dhcpv6 (stateless and statefull) doesn't work


If somebody is arguing with tethering/bridging, then the matrix should be mentioned:

mobile broadband to: usb, wlan, bluetooth (should work, but it doesn't yet)
wlan to:usb?, bluetooth?
bluetooth to: wlan? usb?

Should every network device to be tethered with the other one?
Is it possible just to bridge bluetooth, wlan and usb?

+1 for needing DHCPv6.  We want as few addresses as possible on the large enterprise wifi network.   We don't want PE (too many address on the network).  We don't want EUID64 (privacy).   DHCPv6 would deliver what we're after - if only Android supported DHCPv6.  

I am in the Networking group at a large university with 50,000 users. Our Security group, in consultation with the Office of University Counsel, has told us that we must use DHCPv6 (because RIAA+MPAA, we must be able to match a user to IP+timestamp) *or not enable IPv6*. Networking and Security have decided that Android not working on the campus wireless network is acceptable; being on the wrong side of our lawyers is unacceptable. We will warn incoming students not to expect Android to work.

Our offices have corporate-issued android devices as well as others used for QA, and business requirements to QA IPv6 connectivity for applications/services from these devices.  Currently we have DHCPv6+SLAAC+PE, but have an initiative to move to managed addressing only and turn off SLAAC+PE to reduce the number of IPv6 neighbors populated in CAM for our office switching equipment; our larger offices are large enough that this is an issue we are running into.

The lack of Android support for DHCPv6 creates a blocking issue due to the requirements described above.  DHCPv6 is the only way for us to have:
- address privacy
- managed addressing
- Provide DNS and other bootstrap configuration to devices
- One GUA per device

We also have security requirements to provide a paper trail for addressing on the corporate network, to correlate with firewall and/or IDS logs.  Without DHCPv6 support on Android, we have a hole in our compliance with this requirement due to not being able to turn off SLAAC/PE.  This is not a position we want to be in.

It looks like many of us have been subscribed to this issue for quite some time and are surprised to see that the Android dev leadership do not understand the use case for DHCPv6 support and why it is required in these environments.

@#56 "provide a paper trail for addressing on the corporate network": 802.1x is the right answer to allow only authorised nodes on the network; but indeed combining that with DHCPv6 is a much better situation due to less addresses that map to the 802.1x identity which would allow one to restrict speaking only to authorised nodes (thus avoiding the chance of somebody picking an address of another node).

Stateless IPv6 addressing, with RDNSS by RFC6106 (if the router supports it) on the dual-stack home router LAN is OK for ISPs that are picking the low hanging fruit of moving Internet content from IPv4 to IPv6. ISPs can get by with dual-stack and IPv4 RDNSS if their CPE router doesn't support RFC6106.

The lack of stateful DHCPv6 or DHCPv6-PD doesn't help with the deployment of IPv6 when there's someone that cares about the addresses being assigned.

The deployment for single-stack IPv6 with 464xlat is also hindered by clients needing a network that supports RFC6106 to advertise the servers that provide the DNS64 service.

DHCPv6 is necessary. Without discussions. Our IPv6 network is DHCPv6 only. It is necessary for management.

There are networks without SLAAC -- we do need stateful DHCPv6 support on the Android platform.

Support for 464xlat on wifi has already been added and will appear in an upcoming release. This relies on the ability to configure a second IPv6 address, because it is not possible to run 464xlat and native IPv6 on the same address. (Specifically: in the general case it's not possible to know whether an incoming packet should be processed by the IPv6 stack, or translated to IPv4 and passed to the IPv4 stack.)

It's a fair assumption that many (or at least some) networks that support DHCPv6 will limit the number of IP addresses assigned by DHCPv6 to one per MAC address. This is either because they want as few addresses as possible on the network, or because it fits in well with existing management systems that assume one host == one MAC address == one IP address, or any other reason.

On such a network, it's not possible to run IPv4-only apps, because there is no IPv6 address for 464xlat. And it's not possible to enable tethering without doing NAT for IPv6. This will cause user-visible breakage - users won't be able to run IPv4-only applications such as Skype, and even tethered applications (which may expect that IPv6 provides end-to-end addressing without NAT, like libjingle does; it supports NAT traversal for IPv4 but not for IPv6) will not work correctly. So the user experience provided by such a network is worse than one provided by an IPv4-only network. Therefore, from the point of view of most users, who are not networking experts, it may be better not to connect to such a network at all, because in most cases, an IPv4-only or dual-stack network will be available - as Wes says, at the moment IPv6-only networks are a largely theoretical problem.


As an aside: if the assertion is that DHCP is needed for tracking purposes, it's worth observing that DHCP by itself provides no security. As long as the host is free to statically configure a different IP address via manual configuration, then reliable tracking is impossible - you get the illusion of security, but no actual security. For tracking to work, the network must also enforce bindings between IP addresses and MAC addresses, to ensure that the host is not using a different IP address than the one it obtained via DHCP. But if the network is already doing that, then it's simple to simply log those bindings from the first-hop router's ND cache and send them to a logging server. That provides reliable tracking without the server (or the client) needing to use DHCPv6.


As for DHCPv6 PD: widespread support of DHCPv6 PD by mobile carriers would be a reason to support DHCPv6 PD, yes. Is there widespread support for this already? Or are carriers assuming that tethering will be implementing via /64 sharing?

> This relies on the ability to configure a second IPv6 address, because it is not possible to run 464xlat and native IPv6 on the same address.

As noted in the comments, one can ask for multiple addresses. Indeed you might not get them. But in such an environment (eg corporate) you will have other restrictions too and likely for the next 20++ years or so they will still have native IPv4 too.

In such an environment just have a "464xlat" not available warning. That is it.

> On such a network, it's not possible to run IPv4-only apps

Such a network will likely have NATted IPv4 available. And if that is not available then "too bad" for those applications that chose not to upgrade to IPv6. They kind of had a warning a long time ago.

(For that matter: why did Android not require IPv6 capability in applications? Android is much younger than IPv6 thus don't say one did not know that it was coming.... :)

> And it's not possible to enable tethering without doing NAT for IPv6.

Corporate networks and others where DHCPv6 will likely not be happy about tethering and opening up the network for such access anyway: thus "this feature is not available as the network..."

> users won't be able to run IPv4-only applications such as Skype,

Networks that are restrictive really do not want to have Skype in their network anyway. Thus what is the problem?

And for the rest of that overly long sentence, not having NAT for IPv6 is great, that is the whole point of IPv6. To solve the 'tethering' you could always bridge your packets or do ND proxy style. Trying to solve it everywhere though for every application won't be possible.

> because in most cases, an IPv4-only or dual-stack network will be available

DHCPv6 will happily live together with DHCPv4 indeed aka dual-stack. Thus can we please have it?
People love this feature parity thing.

> As an aside: if the assertion is that DHCP is needed for tracking purposes [...]

Obviously you did not see my comment #62.... did you even read the comments?

> it's simple to simply log those bindings from the first-hop router's ND cache and send them to a logging server.

And then you end up with all the privacy addresses and thousands of others that might even clash at one point or another. If one is restricting based on DHCPv6 then one does not allow the ND entry to even appear in the ND cache as that MAC based on 802.1x auth is not allowed to put it there.

> As for DHCPv6 PD: widespread support of DHCPv6 PD by mobile carriers would be a reason to support DHCPv6 PD, yes. Is there widespread support for this already?

Ever heard of this IPv6 chicken and egg issue, yes you definitely have.
When platforms do not support it, how are carriers going to use it when they want to?



As several people have given proper "compelling use cases" for DHCPv6, when is this feature coming?

You invent a new  chicken or the egg problem.
Your conclusion is in short words:

Because of skype we need clat. Because of two IP-addresses for clat.
Therefore we don't use dhcpv6 at all?

Please make it configurable "checkbox: support dhcpv6 (disables clat)", so that people have a choice, if they run into trouble with their network.

I agree partly to dhcp PD. Mobile carriers need this feature in their networks, e.g. for static replacements, (great)WLAN-hotspots or whatever.
For end devices/user /64sharing works (not at android but in general).

One thing: we develop the future not the past.
We cannot wait until the last IPv4-dependent app dies.

> "checkbox: support dhcpv6 (disables clat)"

The android devs are clearly very concerned about user experience. This is good! There are also reasons the network operator set things the way they did. The OS needs to configure the network with the options given by the router. If the M flag is set, do stateful DHCPv6. If the O flag is set, do Info requests.

If Android tries its best to configure all the scenarios and still doesn't have an IPv4 path, it can put up an alert on connect saying "There is no IPv4 path. Your experience may be degraded. Contact your WiFi provider if you have problems."

Google keeps saying they're developing for what is. Well, I've said it other places, others have said it in this thread, but it apparently needs to be repeated: Every other respectable operating system *in operation today* supports this feature. Android does not. As a WiFi network operator, I'm going to deploy in such a way to cover my largest user base. Right now, that means DHCPv6, and no Android support.

I work for a large carrier, with mobile, wifi, and cable broadband services.

Right now, we won't deploy IPv6 on mobile/wifi because of the lack of
1) DHCPv6
2) DHCPv6 PD  (for tethering)

Google, please take a look at the DOCSIS space if you need a reference for how to handle things.  They're doing it mostly right.

It breaks my heart to tell Android users to avoid the IPv6-only lab, because they just won't work, and therefore they can't validate their services.

It is true. We have IPv6 WiFi site with DHCPv6 only. All operating systems (Windows, Linux, iOS, MacOS) works good, but Android is not supported. It is very bad ...

The extension of support for 464xlat to the wifi interface with SLAAC is nice. It would be nicer still if it also honored the RA O flag to also have the possibility to get RDNSS of the DNS64 from DHCPv6.

[Comment deleted]

There exists source-verify mechanics in a lot of routers which does a DHCPv6 Lease Query to the DHCPv6 server to prohibit usage of self-configured addresses in an enforced DHCPv6 use case (we've deployed this for DOCSIS -- it works). This is in most operator cases preferable to configuring ND-cache scrubbing and logging on each access/edge router (which is an operational headache).

As for IA_PD support by carriers; let me answer a rhetorical question with another: if Android supported stateful DHCPv6, how long would it take for carriers to support IA_PD to make tethering (or multiple address assignments) work? Think 4G home routers in areas where fixed broadband isn't a viable option -- this is a trend in some areas..

The RDNSS option in RA still isn't supported by default in Windows - meaning Windows clients tethered would effectively have to rely on resolving AAAA records via IPv4 (assuming the client is dual-stacked). This kills a potential IPv6-only client environment.

You're already saying you're going to implement 464xlat on wifi, provided that there are multiple IPv6 addresses available. What's stopping you from requiring an assigned IA_PD-prefix to enable IPv6 in tethering mode on the wifi interface? This would be an acceptable compromise in my opinion, and it effectively solves your "fair assumption" of a one-IPv6-address-per-MAC scenario (which would break 464xlat anyway), and leaves the decision up to the network owners on whether to support it or not.

Probably my final comment on this topic.  From my perspective running a large IPv6 deployment, a single option rarely meets everyone's requirements and will inevitably leave someone stranded.  While my deployment will be satisfied with SLAAC + RDNSS I am quite certainly this will not be universal.  For my Wi-Fi deployment and even for my home routers I had to make sure I could support as many combinations of features possible.  So for us SLAAC + RDNSS will not be an issue either for community Wi-Fi or in home.  I believe stateless DHCPv6 should be added at some point.  I can see why stateful DHCPv6 may not be required unless Android devices wish to be delegated a prefix.  Every deployment where PD is supported that I know requires stateful DHCPv6 support.

I think the Android team needs to better consider the needs of their users and customers.  Rigid technical decisions and philosophical differences do not mix well.

Apparently all the "reasons" being brought up here about xlat etc are not the point why Google does not want to add support for DHCPv6.

The real reason is is that they think that Android has such a large deployment and is so important that they will be able to stop networks from providing more than 1 IP address by not supporting DHCPv6.

Any network that will want to limit their users from getting multiple addresses will limit that, one way or another.

As Lorenzo has nicely stated "Android will just not connect" (paraphrase).

Fortunately most networks know that addresses do not matter, people will stuff them behind NAT if they need to.
They also know that the actual traffic matters, as that is what they pay to transit partners and they also charge you per byte. As has been seen in real deployments around the world addresses is what they give out in IPv6, what they do not allow though is usage for longer than say 24 hours. (next to of course charging insane amounts for the traffic and/or limiting the amounts that you can send)

Supporting DHCPv6 will not change anything for these situations.

Good luck to all you Android users, you might want to start requiring an upgrade to Cyogenmod instead or advising your users to steer clear of this Android thing.

First, thanks for clarifying further, Lorenzo, instead of keeping us in the dark like its been for years.

Now let's start with your concerns of things becoming broken:
1. IPv6 tethering -- IPv6 NAT = legacy IPv4-minded thinking. End-to-connectivity is what the Internet was designed for. I haven't seen mentioned here specifically how adding support for DHCPv6 will break IPv6 tethering though and, as others have said, DHCPv6 improves the situation by offering DHCPv6-PD. Even the official RFC from T-Mobile (RFC 7278) in the introduction specifically mentions that it is just a workaround *until* DHCPv6-PD is implemented along with 3GPP Release-10. If that isn't an official request from carriers, I don't know what is.
2. 464XLAT on Wi-Fi -- So why have the device assume that IPv4 is not provided on Wi-Fi if IPv6 is in use & insist on pushing v4 through v6 without checking the IPv4 stack first? Please provide a practical use case that offering this "feature" is better than blocking people from using DHCPv6 for basic connectivity unless you can get them to play nice together which I'll mention an idea on below.

Recently this discussion has been fruitful since its revealed that 464XLAT has some major interoperability use cases that should be addressed before fully implementing & aren't even mentioned in the Informational RFC 6877. Its much newer than other actual standards like DHCPv6. So could someone please provide official feedback to get these issues and their workarounds, etc. officially addressed in RFCs and elsewhere?

If implementing 464XLAT on Wi-Fi (without a use case outlined to us as of yet) is happening despite its infancy & issues then I think 464XLAT should always be disabled for the Wi-Fi interface until the point that Android sees that only one IPv6 address is assigned by DHCPv6 or SLAAC & no IPv4 address is assigned then (and only then) Android could enable 464XLAT to avoid IPv4 "breakage." Sounds like there needs to be a separate bug filed/issue opened for breakage caused by 464XLAT now for the Android product but with it not being here yet then users can't do much at the moment.

I'm mystified at mentioning that "widespread support by carriers" has to come first when it should be common sense that the User Equipment needs to support it before any carrier can. Even if you haven't got a signed letter to your device engineers and/or Android developers on official letterhead stating this is a business requirement yet (although 3GPP R10 should be sufficient), the volume of end user's own network requirements clearly outlined here & everywhere you try to look should be more enough at this point. I mean both SLAAC & DHCPv6 are the very basics of IPv6 support. Carriers are just simply losing out on Android device sales even if *only* user's requirements (like DHCPv6) are not met although they do want this supported even if you guys haven't heard it loud enough or they haven't got through their own internal issues to make it plain to you either.

So again for those with tl;dr issues: carriers either are now or will need DHCPv6 to support 3GPP Release 10 & carriers are losing Android device sales without it if that helps you guys find the green light you're looking for.

Thank you for your considerations.

From comment #77:

«I think 464XLAT should always be disabled for the Wi-Fi interface until the point that Android sees that only one IPv6 address is assigned by DHCPv6 or SLAAC & no IPv4 address is assigned then (and only then) Android could enable 464XLAT to avoid IPv4 "breakage."»

You have misunderstood the issue. The 464XLAT *requires* a dedicated IPv6 address that is separate from the primary address of the device. This is documented in RFC 6877 (ideally, the CLAT has a dedicated /64 obtained from DHCPv6-PD, but where this is not the case, a single address "borrowed" from the uplink network works too).

So the problem is that if Android connects to an IPv6-only network that only allows 1 IPv6 address (note: not dual-stack, since 464XLAT is only used on IPv6-only networks), then it is impossible to enable 464XLAT, since there's no dedicated IPv6 address or prefix available to the CLAT.

A similar concern occurs for tethering: If the network only allows the Android device to obtain a single IPv6 address, then it has no additional IPv6 addresses to pass on to its downstream (tethered) devices. Hence, IPv6 tethering fails to work.

These are all valid concerns. That said, the reasoning for declining this issue appears to rely on a faulty assumption, namely the conflation of "network using DHCPv6" and "network allowing only 1 IPv6 address per device". There is nothing inherent about DHCPv6 that makes it limit IPv6 addresses per device to 1; DHCPv6 can be used to assign multiple single addresses using multiple IA_NA/IA_TA associations, or it can assign a prefix (consisting of many addresses) using IA_PD.

Limiting the number of addresses per node to 1 is something that can only happen due to operational policy; it is *not* a DHCPv6 protocol limitation.

So if Google does not want to support networks that only allow a single IPv6 address per device, that is fine, but orthogonal to a decision to support DHCPv6. In order to accompish the desired effect, the Android device could simply refuse to successfully connect to those DHCPv6 networks that does not offer IA_PD or multiple IA_NA/IA_TA associations, while at the same time accepting connections to DHCPv6 networks which do not have such limitations.

Tore

Refusing to connect to these networks doesn't make any sense either -
just disable tethering/464XLAT and pop a notification that says your
network connection may have limited access to legacy services, degrade
gracefully.  By the time IPv6-only networks become common, it can be
hoped that most services will be available via IPv6 anyway.

@79: It makes sense when the goal apparently is to use Android's market power to coax network operators to Do The Right Thing and build networks that allow single devices to obtain multiple IPv6 addresses when needed.

There's certainly a case to be made that the proliferation of networks that allow only 1 IPv6 address per device will stifle innovation; 464XLAT is an example of a technology which simply cannot work in such an environment.

It's the singling out of DHCPv6 which does not make any sense. 464XLAT, for example, does not at all conflict with DHCPv6. Quite the opposite: RFC6877 actually recommends its use.

Tore

@80: I don't disagree with what you're saying in general, but I strongly
disagree that it is in any way sane for Android to try to force people
to run their networks in some configuration that would otherwise be
perfectly valid.  Client devices should conform to the networks they
join, not the other way around.

> As for DHCPv6 PD: widespread support of DHCPv6 PD by mobile carriers would be a reason to support DHCPv6 PD, yes. Is there widespread support for this already? Or are carriers assuming that tethering will be implementing via /64 sharing?

Cisco's GGSN/PGW Star OS platform supports DHCPv6-PD. If there was a UE that also supported it then we could try it.

Until DHCPv6-PD is supported on both sides the assumption has to be to make do with sharing the 3GPP SLAAC /64 without any option to delegate prefixes to devices tethered off the 3GPP connected device..

Also RFC 7668 (IPv6 Homenet) gives DHCPv6-PD as the prime example for distributing prefixes within the network (section 3.4.4).

Edit should have been RFC 7368 above not 7668.

dhcpcd-6.x has supported DHCPv6 PD for a long time now, even supporting RFC 6603 Prefix Exclusions which is perfectly targeted for mobile devices.

So if you wanted >1 IPv6 address on one interface via DHCPv6 you could request a NA address and PD allocation on the same interface providing the DHCPv6 server supports Prefix Exclusions which in my understanding allows 464XLAT to work.

So the entire argument (as far as I understand it) at this point is not technical, merely political. This is backed up by by the simple fact that dhcpcd has not been updated in Android in quite some time .... even though the publish copyright statement in Android is older than the code, although that's another issue which I mean to take up.

Various use-cases have been clearly demonstrated, can we please have the declined tag removed now?

I think the question is whether those use cases are seen to be useful by the device's users. If the only user-visible feature provided by DHCPv6 addressing is the ability to connect to networks where IPv4-only apps and tethering cannot be made to work well, then users probably won't see DHCPv6 addressing as a desirable feature, and in fact might well prefer not to have it. If users prefer not to have it, then it doesn't make sense to implement it.

If a day comes when support for IPv4-only apps and tethering are no longer important, or DHCPv6-only networks without IPv4 and without SLAAC are substantially deployed, then DHCPv6 addressing will become useful to users and it will make sense to implement it.

DHCPv6 PD is a different issue. I would encourage filing a separate feature request for it. This one as originally filed was about stateless and stateful addressing.

Wow, that's some pretty impressive hyperbole.  The 'user-visible feature' is being able to connect to networks that handle addressing via DHCPv6 and not SLAAC, rather than /not being able to connect to them at all/.  I'd posit that the number of users wanting to be able to connect to a network outweighs the number of users wanting to tether on a network.  And you seem to be completely ignoring the comments explaining that DHCPv6 does not preclude use of 464XLAT.

It makes little sense to me to implement only PD functionality, when the sane way to do that would be to pull in an existing DHCPv6 client implementation.

It also makes no sense to me to reason that completely non-functional networking is better than reduced functionality in a specific use-case.  UX is trivially managed in the short term by notifying the user that their network access may be degraded in the case where there is only a single IPv6 address, with no dual-stack or PD available.

If we follow the logic in comment #86 that the criteria for inclusion is if device users see a feature (such as DHCPv6) is useful or not, then we may as well deprecate and remove the IPv6 protocol stack entirely from Android, right now.  Very few non technical end users see a use case for IPv6 (or even understand what it is), and the question of if they see a use case for DHCPv6 and in turn making a decision on their understanding is really just the epitome of ridiculous.  The entire IPv6 protocol and transition to it was designed to be so seamless that end users can start using it without making any configuration or behaviour changes to their systems and they should not need know what IPv6, SLAAC or DHCP is.

Users expect us (as technical people with input to a project) to make the technically best decision to ensure the broadest compatibility of their devices, since we are the people with better insight and understanding than they are.

But if you really did want end users to comment on this, I've no doubt if the question was posed to them: "Would you like your Android phone to support both the common connectivity mechanisms for the new Internet IPv6 protocol or just one of them" they would almost all emphatically say "Yes" to "both" ..............

Android breaks the internet,

Congratulations!

It looks like Android developers have given a little ground @80 with the encouragement to open a  separate request for DHCPv6-PD support, I assume client and server.

If that's done then its only a hop & skip away from doing the work to honour received RA O flag and M flags.

I'm replying to myself in @61 to clarify what I meant by "One GUA per device" -- I meant "a finite number of addresses per device", not necessarily 1 address.  This is to relieve TCAM/resource pressure on broadcast domains  where device behavior with privacy extensions under SLAAC may result in the consumption of many addresses.  Of course DHCPv6 by itself would not prevent a device from assigning itself many addresses, but it is an important component in influencing device behavior and being able to disable SLAAC.

For me as a network manager at a technical university it is a nightmare to be forced to use /64 prefixes. Just make a simple calculation: A neighbor discovery for an unknown IPv6 address is about 86 Byte long. Since in reality it is on a layer 2 network treated as broadcast with 15'000 packets the wireless of a complete area is down.If a small botnet start to scan a /64 subnet, our wireless network will be down thousand of years.
We usually see infected client to send with 200Mb/s and more if they are used for DoS. By using /64 prefixes it is so easy to implement DoS attacks, that we will implement IPv6 with longer prefixes. SLAAC will not work. Without DHCPv6 Android clients will not be able to connect to our network in the near future. I don't believe that it deliver them a great user experience.

@DValenkamp: those issues are discussed in RFC 6583 and the mitigations are known. See specifically http://tools.ietf.org/html/rfc6583#section-7

A simple solution to your problem is to configure the last-hop router to rate-limit outgoing NS packets for currently-unknown destinations to some low value that will not cause collapse on the wifi. Already-connected hosts will work fine because all those ND packets are unicast. That leaves a problem with how just-connected hosts get into the router ND cache. These can be dealt with by inserting entries into the ND cache via passive observation of traffic (e.g., DAD packets, or originated packets).

Fairphone 1 (2013) http://www.fairphone.com/ has succeeded to integrate a working DHCPv6 client.
We guess that it uses the implementation of Roy Marples http://roy.marples.name/projects/dhcpcd/index 

Has anybody the preview of android m tested?

Maybe somebody at google has had a divine Illumination.

At the university where I work, we are planning an IPv6 rollout with DHCPv6. We don't plan to support SLAAC as we consider that undesirable in our enterprise network. The ridiculous arguments from the Android developers in this thread on why not to support this enterprise standard are pitiful. Like it's going to somehow harm Android users? Sheesh. If we get complaints from Android users once we deploy, I'll tell them maybe they should switch to an iPhone ;).

But it *is* harmful.

It is harmful because it will force device operating systems to implement IPv6 NAT in order to provide feature parity with today's IPv4 functionality. NAT increases application development cost due to the necessity for developers to implement NAT traversal, impacts battery life due to the need for NAT keepalives, and makes applications flaky due to the huge variance in NAT behaviour, timeouts, statefulness (e.g., if the NAT crashes), and so on.

We have these problems in IPv4 today, but that's unavoidable due to lack of address space. Implementing "one address per device IPv6" is a missed opportunity to remove all those problems.

Obviously, in your network you're free to use whatever protocol you want, but I think it's clear which is better for users. There's a reason all residential and mobile deployments use SLAAC.

> It is harmful because it will force device operating systems to implement IPv6 NAT in order to provide feature parity with today's IPv4 functionality.

I'm afraid I don't follow this logic.

> but I think it's clear

No, it isn't.

> There's a reason all residential...

We're not talking about residential here. If Android only ever wants to operate on residential networks (as appears to be the case), then that's fine. Google will just lose out on all the revenue generated by folk who want to BYOD and go get an iOS device that will work in both places.

The key here is flexibility. There's nothing stopping Android from supporting both and therefore interoperating on both. Most Linux distros it. Mac/iOS does it. Instead Google has decided "You will do it our way and like it!", and if there's one thing customers don't like it's being told they are wrong.

Alas, points like this have been made earlier in the thread, but Lorenzo keeps telling all of us from up on high that our boots-on-ground experience doesn't mean a damn thing. My next device will not be an Android.

Sorry Lorenzo, I call BS. Your religion is showing. Again. Your conflation of SLAAC and IPv6 NAT is a desperate slippery slope argument to attempt to justify a position that has always been dodgy at best. Plenty of networks do the former without the need for the latter, because there is no assumption that the individual devices on the network need to act as routers to provide downstream connectivity to other devices, because if those devices need connectivity, they will connect and be assigned an address, and if the device itself needs multiple addresses, it will have multiple interfaces, and therefore request an address for each interface. And that's assuming the degenerate case of one address per device. DHCP does include DHCP PD, which can assign a very nice prefix for use on a network, thank you very much.
I expect this "we know better than our users" smugness from apple, but this is android, which is supposed to be a platform that is a bit more open. You've been told multiple times by actual operators that they actually plan to deploy on *their* networks contrary to your firmly held belief about what is the "right" way to do it. Get a grip, and get out of the way of deployment.

[Comment deleted]

As a network operator for a large university, I can say that Android devices will be left in the dust when our IPv6 rollout goes live. We're requiring stateful DHCPv6 across the entire campus, as we do now with DHCPv4 (in a matter of speaking by using edge-security features on our Cisco switches to drop traffic from non-DHCP addresses).

Our core Cisco routers do not support RDNSS, and will not for the foreseeable future. Perhaps home routers and Linux routers do, but Cisco has only recently made that functionality available in very recent versions of code that have not (and will not) trickle down to the older hardware platforms. SLAAC/RDNSS would not be acceptable for us anyway, due to the DMCA, BSA, and others asking us to track down machines.

As far as the "workaround" offered in #67 in terms of tracking, that solution has a host of issues (pun intended). Keeping a log of ND caches on the off-chance that the information will need to analyzed later is at best an operational nightmare. Assuming I have 10K IPv6 clients all using SLAAC and multiple temporary addresses on a single router (very real possibility in my case), the ND tables would not only explode, but logging such data would take tens of thousands of lines an hour (due to high client churn rates), not to mention the impact on the router CPU while it spins up that data. Have you ever SNMP bulk-walked an IOS router for a large (>5K entries) ARP table? Querying an ND table with multiple entries per client is processor suicide, I'll never be able to manage the routers again because they'll be too busy responding to SNMP requests. Yes, maybe that's an issue with the vendor software/hardware, but all of the major network vendors have similar issues, so that's just a reality.

Yes, I do realize that I am only gathering the DUID via the DHCPv6 request rather than the MAC address of the host as we do in IPv4. However, having a single IPv6 address and DUID combination is much easier to handle than trying to track down two or three hundred random IPv6 addresses, all of which may point back to the same single host. Logging for address requests is significantly simplified, and doesn't require my routers to max out their CPU's, and my storage requirements are minimized.

I'm guessing I'm not the only one with these concerns either. Anybody with any sort of legal liability (DMCA, etc.) will want/need to have that sort of control over addressing (or at least the ability to identify hosts with relative ease).

Even zooming out in a general sense, forcing a particular implementation upon a network operator is a bad way to do business, especially when a publicly accepted standard exists as an alternative. It's especially bad in this case because the justification for not implementing the alternative standard is because a particular edge case may or may not work under certain conditions. If the user needs it to work, offer the option to run in 'legacy mode' with DHCPv6 disabled. Develop for the future, right?

This is akin to supporting WPA/2 Personal, but not WPA/2 Enterprise with 802.1X authentication (which isn't the case with Android, but serves as a good example of a flaw in many other consumer products such as gaming consoles). We as network operators are forced to do crazy workarounds on our side to allow these devices to function, often poorly and with much hassle. You know what ends up happening? The devices get abandoned, or the user deals with sub-par service. But hey, it works at home, why won't it work at school, right?

[Comment deleted]

Lorenzo, did you seriously just conflate DHCP as a slippery slow to IPv6 NAT?  On that basis alone, you should probably be removed from making technical decisions in general.  More pragmatically though, IPv6 NAT is already here and in the kernel.  Despite the many, loud objections.  If that is the entire basis if your argument, you don't even have a leg to stand on.

We, your users, NEED DHCPv6 support. This isn't a preference or wish list.  This is a fact of the matter, as stated numerous times.  Let the pride and blue sky go.  This isn't a fight you can win without being trampled.

Wesley, what do you expect Android to do if given only one IPv6 address and the user turns on tethering? Because what the user expects is that "it works", and the outcome is that Android will need to implement IPv6 NAT. If you think that's not a bad outcome, you're obviously free to have that opinion. But I don't see how you can argue that that there will be any other outcome.

What does tethering have to do with this? The user isn't going to be tethering if they are already on WiFi.

Thanks code.google for stripping all quoted context, with context:

> It is harmful because it will force device operating systems to
> implement IPv6 NAT in order to provide feature parity with today's
> IPv4 functionality.

No it doesn't.  As has already been explained in this issue, DHCPv6 does
not preclude multiple addresses, and suggestions have been made for how
to deal with the case of no IPv4, and lack of multiple IPv6 addresses
(don't enable enhancements like 464XLAT), should some network decide to
implement things that way.

> Obviously, in your network you're free to use whatever protocol you
> want, but I think it's clear which is better for users.

Unless you want to support Android clients, in which case, you have to
weigh every other concern in your design against supporting those
clients.  Android support will likely lose out here in a number of
networks (provided operators are even aware of this issue - many
operators will likely assume that 'IPv6 support' includes the common
standards for address configuration), and so Android /users/ will be the
ones who lose.  This seems like a bad result for the Android brand, and
will force a mandate of non-Android devices for those networks.

> There's a reason all residential and mobile deployments use SLAAC.

There are things wrong with this assertion: A) you'll need data to back
up this unequivocal blanket claim; B) you presume that in the case of
deploying SLAAC, their reasoning aligns with yours; C) residential is
not the only network class; D) the Android team is trying to create a
chicken-and-egg scenario here.

> what do you expect Android to do if given only one IPv6 address and the user turns on tethering?

Disable tethering, notify the user that their network operator has provided a configuration that does not support tethering.

Well, how about
1) "Error: tethering not available here" along with a pointer to an explanation, even if it is something akin to "the network you're connected to is run by people who did it wrong, and you should complain to them about their implementation."
or, if you actually want it to "just work"
2) attempt a DHCP-PD request to get a prefix to use for local tethered network
failing that--
3) proxy the DHCP request from the tethered device so that it gets an address from the network
You're being disingenuous by suggesting that the only option here is for it to break in an unrecoverable way.

And setting that aside for a minute, how does one enable tethering to a wifi network on a device with one wifi radio and no wired interface? If you're suggesting that this is a problem for tethering in a mobile network, then you're fixated on the wrong problem, since the mobile side's addressing is controlled by the carrier, and most of the folks posting here are talking about using DHCPv6 on their campus WiFi.

> what do you expect Android to do if given only one IPv6 address and the user
> turns on tethering?

Hmm, scenario 1 (worst case, assuming you don't just request a prefix from the DHCP server, or even just another address by supplying a different DUID): "Sorry, this network doesn't support tethering".

Scenario 2 (no DHCPv6 support, even for people that have *no interest* in tethering): "Sorry, you can't get on the network because Android doesn't support basic IPv6 standards".

Oh yeah, I can definitely see how scenario 2 plays out better for android 8-/.

So why exactly is a device trying to tether via wifi to this supposed android device rather than just connecting directly anyway? Seems like a rather convoluted scenario whose sole purpose is to make up a reason to defend this odd distaste you seem to have for DHCPv6.

Somehow I can't imagine the iOS or the Windows Phone devs having this discussion before they implemented DHCPv6. What is so unique about Android that it can't support a standard it seems every other vendor is on board with?

Wes, one use case here is USB tethering when the device is on wifi. Saying "tethering is not available" is not going to fly, because it will likely be perceived by users as Android bowing to network operators.

As regards DHCPv6 PD - as you say, that has none of these shortcomings. Since you are an IETF working group chair, let me state here that I would be happy to work with you on an IETF document that recommends that stateful address assignment to mobile devices be implemented by delegating an IPv6 prefix of sufficient size, and not via stateful DHCPv6 address assignment.

If that document achieves consensus (including consensus on what a sufficient size will be), then it will be reasonable to implement the resulting RFC, and thus enable DHCPv6 PD by default, while continuing not to support DHCPv6 address assignment.

Why would Android need IPv6 NAT? And why mention tethering?

We are talking about WiFi, not mobile data.

> one use case here is USB tethering when the device is on wifi. Saying "tethering is not available" is not going to fly, because it will likely be perceived by users as Android bowing to network operators.

So what?  You're satisfied with the alternative that Android devices will *simply not connect to these networks at all*?  You think *that's* the better PR situation, and end-user experience for Android?  Not to mention that Android already gets bundled with telco crap on handsets, so you can't start with this argument now.  This is a completely empty argument.

You're also talking about rather niche use-cases here, and if you do a union on the number of users utilizing USB tethering with users on networks with this configuration, who care more about tethering than connecting, you'll likely find the number rapidly approaches zero.

> let me state here that I would be happy to work with you on an IETF document that recommends that stateful address assignment to mobile devices be implemented by delegating an IPv6 prefix of sufficient size, and not via stateful DHCPv6 address assignment.

Alternatively, you could just stop ignoring all the cogent options being suggested and deal with the fact that Android will have to implement stateful DHCPv6 to work on all networks, and that you simply cannot convince the entire world's network operators that your view of how they must deploy their networks is the only way it may be done.

This is frustratingly farcical at this point.

Hmm, so the reason you won't support DHCPv6 is because you *might* (ignoring all the suggestions offered so far not to have to) tell an Android user they can't tether on a network that otherwise they wouldn't even _have_been_able_to_connect_to_????

So it's better for the vast majority of users who just want to get on the damn network to be screwed because some small minority might not be able to tether?

I'm glad I'm not an android user if this is the attitude of the developers towards their userbase 8-/. Maybe we'll incorporate this into our helpdesk documents for our IPv6 rollout -- "You can't connect to our network because the Android developers are worried you might not have been able to tether if you did." I'm sure that will make them feel *lots* better when they have no connectivity at all.

As someone who is implementing IPv6 in a residential setting, I will say that SLAAC is not the way we're going with our deployment. We're using DHCPv6 and have had to disable IPv6 for android users specifically for this reason. I'm glad I'm not the only one who sees the insanity of them not supporting DHCPv6 over wifi.

Dustin, I'm curious why you decided to use DHCPv6 given that all major wireline operators are using SLAAC. I can definitely see that cable modems will require DHCPv6 in order to connect. But are you requiring that all devices inside the home implement stateful DHCPv6 addressing in order to get IPv6 connectivity? If so, why? No major ISP imposes that restriction on its customers.



To address the other recent comments: as stated above (e.g., comment #66), DHCPv6-only networks don't just force operating systems towards NAT. For example: a network that provides only DHCPv6 makes it impossible to support 464xlat (thus breaks IPv4-only apps) and doesn't allow building new apps that can use multiple IPv6 addresses for things we haven't yet thought of.

The problem I see is that stateful DHCPv6 address assignment imposes these disadvantages on users, but doesn't actually seem to provide any *advantages* to users.

It's clear from the comments above that DHCPv6 provides features for network operators. If the claim is, "if network operators cannot have those features, then they cannot provide IPv6 service to users", then as an industry we should work together to find ways to provide IPv6 service with these features but without the disadvantages for users. An example might be DHCPv6 PD.

If the claim is "a minority of network operators are deploying DHCPv6-only networks, and therefore all operating systems must support DHCPv6-only operation, despite the disadvantages for users", then that does not seem to be a convincing argument for as long as IPv4 exists, because operating systems can just continue to use IPv4 on those networks. If IPv4 is not supported, then users probably don't want to be on those networks anyway, because too many applications will break.

@#114 You can't claim that lack of support for 464xlat is a show-stopper and then in the same breath claim that because IPv4 still exists, there's no need to implement DHCPv6.

And you seem to be labouring under the misapprehension that somehow it is the Android project's place to dictate the minimum required level of functionality that network operators and users require to achieve their goals - this is simply not the case.  Android devices are clients, they cannot dictate the configuration of the network.  And as it turns out, all other major operating systems *do* implement stateful DHCPv6, it's only Android that's the outlier here.

By all means lobby to expand the functionality of other addressing schemes, but in the mean time, the standards exist and are obviously already being deployed.  To serve the user, Android needs to support the modes of operation that have been standardized and are being deployed.

I can't see a happy resolution to this issue while the position of some Google staff appears to hinge on political fervour, rather than an acceptance of the state of the world, and sadly it's Android users who will suffer.

I'm not quite sure how you can say implementing DHCPv6 will "harm" users with a straight face 8-/.

A user tries to connect to a DHCPv6 only network. In your view of the world, they just fail to connect and are screwed. As opposed to if Android supported the standard like just about every other IPv6 capable OS out there. How exactly is a user *harmed* by being able to actually use the network??? You say "Oh noes, but then they might not be able to tether!" Spoiler alert -- if you can't connect to the network at all, tethering is pretty much off the table anyway.

The absolutely *only* rationale you can have by saying not implementing DHCPv6 is preventing harm to your users is if you are operating under the insane premise that by refusing to implement it you will dictate to network operators how they should configure their network, and force them to your personal philosophy. As has already been pointed out, Android is a *client*. If it doesn't support the standard protocols a provider decides best fit their network, it simply won't be welcomed on the network and clients will be advised to buy a decent phone/tablet.

I don't think I've seen a single post in this thread supporting your position. On the contrary, everybody seems to be shaking their heads in disbelief over your utter and total lack of regard for actual users and what they need. What other operating systems have refused to implement DHCPv6? What other network experts agree with you?

It seems ridiculous that the entire android ecosystem is held hostage to this personal vendetta you appear to have against DHCPv6. Once again, I'm glad I'm not an Android user, and I've got no qualms about telling users trying (and failing) to connect to our network that they should find a phone with an operating system that fully supports Internet IPv6 standards. Like pretty much every other one out there other than yours.

Sheesh. Assuming Google's desire for android is to be as popular as possible, as opposed to a platform for you to evangelize your own views at the expense of functionality, hopefully somebody will eventually override you on this.

Paul, let's save that argument for a time when (if?) DHCPv6-only networks without IPv4 are meaningfully deployed and generally usable without application breakage. :-)

As regards tracking, other universities have been able to implement that without DHCPv6:

http://comments.gmane.org/gmane.ietf.ipv6/27574

And of course, first-hop security code in routers can already do most of this, to the point of sending syslog messages when new ND cache entries are created.

Hmm, android developers are as little children. "I don't want DHCPv6 ... beee" ;-)

But IPv6 implementation without DHCPv6 is as Ferrari without motor. Looks good but not working (only from hill).

comparing an enterprise network with a residential network is just completely unfair.
According to our acceptable use policy every user of the network must be identified with the traffic he caused to the Internet. The leaner I can implement this tracking the better I am doing my job.
At our university (20'000 students) we are thinking to prohibit Android because we cannot fulfill the legal requirements with reasonable effort (see #101).

Tethering:
It is just crazy to allow tethering in an enterprise network. Tethering creates a WLAN-Accesspoint (AP) for every device doing tethering. Who wants thousands of AP's in his wireless network. And even worse every client doing tethering creates a small router opening a possible backdoor into your enterprise network. This is not fun.

Android must support DHCPv6 - only like this Android is enterprise ready. Every network operator must feel free how he operates his network. Android must be flexibly configurable to support all major RFC! There is no other way to go. Google should listen to their customers (not only the consumer) not trying to play prophets.

The discussion is again about the managed/unmanaged flag and the possible consequences that an android device cannot occupy the whole WIFI-segment instead of one or more single IP-addresses. (by the way: tethering is not implemented yet in the very useful and unproblematic case: LTE to WIFI at the "pure" android)


But there is also the "other"flag for stateless dhcpv6 (isc dhclient -6 -S ) which is not supported by android. (DNS)

Only RFC6106 is supported since lollipop.

What is the intention of #117 ?

There will be IPv6-only networks without IPv4 and without android of course.

"given that all major wireline operators are using SLAAC. I can definitely see that cable modems will require DHCPv6 in order to connect."

Regarding the first part, [citation needed].

Cable uses DHCPv6 for both IA_NA to address the modem or directly connected device, and then for IA_PD to provide a prefix for the home. No SLAAC is supported between our equipment and the CPE. It'll even listen for hints and depending on policy, allocate a prefix larger than /64 (we offer up to a /56, for example, and Comcast a /60). The home router generally supports both DHCPv6 and SLAAC for devices on the home LAN, but that's quite a bit different, as it's considered an unmanaged network unlike the enterprise networks that people keep mentioning, which have vastly different requirements.

"one use case here is USB tethering when the device is on wifi. Saying "tethering is not available" is not going to fly, because it will likely be perceived by users as Android bowing to network operators."

I'm sorry, but no. You're using what is a strawman corner case at best (USB tethering for when someone is connected to wifi using an android device but has some other device that doesn't have wifi? Is that seriously a thing?) as a blocker for complete support for IPv6 on Android. The only Android device where Android devs have complete control over whether they "bow to network operators" is the Nexus line, and the few others that have flirted with selling an unlocked "dev" version that is running box-stock Android. Everything else is running an OEM-ized or carrier-ized version of android, and is subject to their whims around things like tethering, so really unless Android is going to suddenly assert Apple-like control over the core OS and its update cycle to fix its fragmentation problems, that ship sailed long ago. Any anyway, as far as I can tell, this is being perceived by the users represented here as Android bowing to Lorenzo's religious beliefs.
 
"As regards DHCPv6 PD - as you say, that has none of these shortcomings. Since you are an IETF working group chair, let me state here that I would be happy to work with you on an IETF document that recommends that stateful address assignment to mobile devices be implemented by delegating an IPv6 prefix of sufficient size, and not via stateful DHCPv6 address assignment.

Well, you know as well as I do that a WG chair has no power to move things through IETF any more than any other participant, and further that IETF can say whatever it wants, but that will not provide any sort of mandate when it comes to what people actually decide to implement. BCPs are suggestions. That said, I think that there probably is value in documenting this use case(s) you're completely wrapped around the axle about, whether the result is that we get consensus on legitimate reasons why you [SHOULD | MUST] be able to assign a prefix instead of a single address when using DHCPv6 in a managed network environment, or that they shout you down and tell you that you're making a huge deal over a minor thing, as has happened here. If this is seriously the only blocker for implementing DHCPv6 on Android, then yes by all means let's work on that. You have my work email, send me an outline of what you want to cover.

"it will be reasonable to implement the resulting RFC, and thus enable DHCPv6 PD by default, while continuing not to support DHCPv6 address assignment."

Again, no, that is not at all reasonable. Independent of whether it's even possible to implement the former without the latter and avoid a major amount of additional work either in the implementation itself or in the implementation and configuration used by the operator of the network, if your goal is to have a system that works in the widest variety of situations so that users don't experience breakage, the right thing to do is to have provisions for support of stateful DHCPv6 address assignment, with the understanding that it may need to invoke PD when or if tethering (or whatever else you think needs a prefix) is enabled.

As far as I can tell, your assertion is that DHCPv6 is so onerous that it's literally worse than leaving people using IPv4 + NAT(s), because that's what people are telling you is the alternative. It's either that, or you simply can't come to terms with the fact that your word is not the ultimate say so when it comes to the "right" way to implement IPv6 on a network, and I'm not sure which is worse.

Not that we carry much weight as an enterprise deployment, but we have only/will only assign IPv6 from DHCPv6. I suppose I will let everyone know IPv6 content is not available to Android users over our network.

I'm so tired of the '464xlat will break' argument that I actually went and looked at RFC6877:

"""
Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

<snip>
"""

You see the first line? It's an informational RFC, meaning that there is no expectation that the functionality is available, meaning that a very, very large majority of the time, 464xlat will be broken no matter what. This appears to be acceptable to everyone (OS-wise) except for Android.

TL;DR; Holding up improved functionality based on RFC6877 is not acceptable since that functionality will be available in specific enterprise networks who will make the appropriate adjustments to allow this functionality.

TL;DR; TL;DR; Android cannot currently connect via DHCPv6, and since that is true, 464xlat is already broken in those circumstances. The device should at least be able to connect, since that would be a dependency of 464xlat working.

> let's save that argument for a time when (if?) DHCPv6-only networks without IPv4 are meaningfully deployed

Huh? What does that have to do with anything? You're saying it is okay for android not to be IPv6 capable on a given network as long as that network also provides IPv4? One of the primary reasons we are finally deploying IPv6 is because some government networks have gone IPv6 only and the ability to communicate via IPv6 is a prerequisite to be eligible for certain grant work. I guess we will need to be sure to have our research office inform our faculty that they should not to purchase android devices if they plan to do any work involving IPv6.

I'm still waiting for you to point out a single person that agrees with your twisted perspective… Are there really no other android developers that work with networking? You are the single one that seems to have posted to this discussion thread.

You don't happen to be a mole working for Microsoft or Apple? Given you seem to be doing your best to convince enterprise networks to discourage android adoption 8-/...

> As regards tracking, other universities have been able to implement that without DHCPv6:
>
> http://comments.gmane.org/gmane.ietf.ipv6/27574

Let's pick out a few pertinent quotes from that message:

"It's a choice"

"that's your choice"

"But it's a choice"

Yes, that person chose to implement a particular mechanism. But he also makes it quite clear that other people should be free to choose other mechanisms.

As opposed to you, who is pretty much saying "my way or the highway".

From #114:

"To address the other recent comments: as stated above (e.g., comment #66), DHCPv6-only networks don't just force operating systems towards NAT. For example: a network that provides only DHCPv6 makes it impossible to support 464xlat (thus breaks IPv4-only apps) and doesn't allow building new apps that can use multiple IPv6 addresses for things we haven't yet thought of."

I've already posted about how 464xlat can be safely ignored since it isn't even technically a standard, just an informational RFC on how to get around a broken network design. DHCPv6 is an actual standard, and a useful one in certain environments.

For my situation specifically, the fact that tethering would be broken in a DHCPv6-only environment would actually be desirable. The behaviors in #107 and #108 would be exactly what I'm looking for. I'm under specific restrictions to disallow any device that 'extends' our campus network beyond the realm of direct campus control, meaning no external switches, no NAT routers, no mobile hot spots that bridge/NAT back on to the campus network, etc. If I have a way to control whether or not a device is allowed to tether, I'll take it. It goes back to my previous posts about legal liability and being able to identify devices accurately (as much as possible) on the network. Worst case, disable tethering via IPv6 if DHCPv6 is in use. Many, if not most, enterprise networks are going to run a dual-stack, so tethering should work fine via IPv4 for at least the next several years.

However, holding up implementation for "things we haven't yet thought of" means that literally nobody [currently] has a use for such a feature, and DHCPv6 is not designed to address such a [non-existent] situation (except for DHCPv6-PD, which does address multiple address needs in existing environments and real scenarios TODAY). I agree that DHCPv6-PD should be handled separately in another tracker, but that does not preclude the use/implementation of standard DHCPv6.

When the situation that we haven't thought of yet does arise, I'm sure the IETF will address it. In the meantime, we'd like things to work as they were designed/intended today for the non-tethering users.

"Paul, let's save that argument for a time when (if?) DHCPv6-only networks without IPv4 are meaningfully deployed and generally usable without application breakage. :-)"

Pardon me for being overly blunt, but choosing my IPv6-related deployment options for my network(s) isn't your damn job.

And now with Apple's announcement that ALL apps in IOS 9  *MUST* support IPv6 ...

perhaps Android will get the message that supporting ALL IPv6 network topologies is in their best interest.

It would appear that all arguments against implementation have addressed by outlining a reasonable set of behaviors and (what I consider to be) acceptable impairment of service in unique and rare edge cases that can be addressed later if/when requested, or at the developer's leisure. Several compelling business cases stating the need for implementation have also been presented (aside from my own).

What considerations are left to change the status away from 'Declined'?

I'm just an Android user.

I'm not the admin of some massive IPv6 deployment.  

And with the attitude of the main developer of IPv6 in Android taking his views as law/fact/the only possible solution, literally disenfranchising everyone who has already, successfully, with distinct reasons, and use cases, deployed DHCPv6 as the only IPv6 addressing method on their network, I'm personally glad I am _not_ the admin of such a network.

Dealing with high holy pissant pedants is why I ran like mad from Microsoft and Apple so long ago.  I've used Linux as my only operating system (with extension of Android being a Linux kernel) for the past 12 years.  EXPLICITLY BECAUSE IT SUPPORTED THINGS BETTER AND BECAUSE THERE WAS NO SINGLE DECISION THAT COULD SCREW THE WHOLE THING UP.

Not even Linus Torvalds going clinicly insane and selling Linux to Microsoft to close-source and turn into 'Windows Forever' would cause Linux to go sideways, as a huge team of others would fork and fix.  Its happened with LibreOffice, OpenZFS, and Illumos when Oracle crapped on SUN.  

Cyanogenmod is so far your the only really good, well organised, effort to fork-and-fix AOSP.  And it seems they either haven't been able to, or haven't found the impetus (hoping YOU WOULD FIRST) to add dhcpv6 to their release.

Why did Google hire you again?  To piss off everyone who has already deployed a network that meets their needs and now Android cannot use it (effectively/at all) ?

Please, FOR THE LOVE OF ALL THAT IS GOOD, understand you are SCREWING YOUR FAITHFUL CUSTOMERS, DEVELOPERS, AND CONSUMERS ALL AT THE SAME TIME BY NOT IMPLEMENTING ONE OF THE _ACTUAL STANDARDS_ for IPv6 address assignment.  

464xlat again will be broken entirely IF THE USER CANNOT CONNECT AT ALL.  

If(connected) { care about 464lat}; \
else { try {get connected somehow!};
finally {yell at Android for not working the way it needs to}'};


So just PRECICELY WHY do you think that your personal beliefs on "IPv6 MUST use SLAAC" actually trumps that VERY CAREFULLY CONSIDERED DECISION that the HUNDREDS if not THOUSANDS of operators of corporate networks and campuses who have not implemented SLAAC due to legal concerns, have decided and believe to be the best way for their organization?

How can the needs of the 1, outweigh the needs of the many? The ALREADY DEPLOYED MANY.  Spock would cry if he understood how obtuse you are being.

YOU ARE NOT JESUS.  You are not part of the IETF.  You are NOT the ONLY PERSON IN THE WORLD who can dictate IPv6 policies.

SO STOP DOING IT ALREADY.

ADD Roy Marples' DHCPCD v6.x AND LET IT JUST BLOODY WORK THE WAY MY LINUX BOX HAS BEEN ABLE TO WORK, SEAMLESSLY, FROM THE POINT IT WAS INTRODUCED.

I __do not__ want to try going to some random place, attempt to use wifi, and wonder why the hell I can't get an IP.  

Cyanogenmod apparently doesn't support this, according to a bug created in 2013 there, commented upon even as recently as May 31, 2015; even with the ability to add their own stuff and this is ignored, my guess is that the internals of Android are too mucky to even consider just replacing the dhcpcd binary.



GET WITH THE ACTUAL DEPLOYMENTS IN USE IN 2015 AND STOP PREACHING ABOUT 'potential use cases for multiple addresses' WHEN THEY CAN BE ADDRESSED LATER.

I currently boycott Broadcom products, due to their lack of useful open-source compatibility.  I will soon openly boycott Android products if they cannot connect to CURRENTLY IN-USE NETWORKS PROPERLY.

You, one man, are causing a HUGE rift in the community of Android, and if you do not change your ways, I hope it is the death of Android as the most popular platform.

Then you can be pointed to as 'the guy who killed Android' and the rest of the world can move on with devices that actually FOLLOW PUBLISHED STANDARDS.

Mike Hodson

Got to throw my two cents in on this one. If I'm connected to an IPv6-only network which doesn't provide automatic NAT64, then I'm not going to be able to get IPv4 content regardless if the network uses SLAAC, DHCPv6, or even manual IP allocation (in the rare case of assigned a /127).

I have actually used tethering-over-USB on wifi with machines that either do not have wifi but run Linux (i.e., development hardware at work), or on machines w/ a broken chipset. I won't call it a common usecase, but I have used it multiple times. So I get that point of the discussion.

If I'm using wifi in an environment where public internet service is not available, I can still access IPv4 intranets, and such with no issue. Captive portals (pre-login) could be the poster child for this configuration. If I was building a new private network from scratch, I'd likely do it IPv6-only so I don't have to deal with migration. The fact is its not the job of Android to always ensure internet connectivity; when tethering, it *need* to act as a router for whatever devices are connected to the hotspot/USB cable/bluetooth, and nothing further. Furthermore, DHCPv6 is both standardized, and as this thread shows, highly desirable.

It *may* be possible to meet enterprise requirements with SLAAC, but redesigning a network because a single device class doesn't support it is absolute absurdity.

As a note, the multiple address arguments appears to be bunk from where I'm sitting; Android already has to support multiple addresses (even momentary) for IPv6 privacy extensions to work: https://code.google.com/p/android/issues/detail?id=14013

Within the last couple of weeks we had 10Gb/s and 3Gb/s DoS Attack. One of them was a internal attack going to a web shop. The client was just sending TCP-Syn packet with a random source IP. With SLAAC this attack would have brought down our complete network. And none of the from Lorenzo mentioned ways would have helped to keep the network alive.
How rate limit resources on a firewall? How could a firewall differentiated between a good and a bad tcp syn packet? To got a stable network we had to limit the amount of sessions per client = IP-Address to 300. with a IPv4/22 network the worst case of 300'000 sessions has to be handled by the firewall, which is ok. With IPv6/64 every payable firewall will be killed. Using /64 prefixes open doors for a lot of DoS Attacks. Either the Firewall, Router or Access/Wireless will be easily killed. Forget about control plane policing as long as you could not differentiate between a good and a bad syn packet. In reality we were on our routers not able to differentiate between a tcp syn to a unknown host and a dhcp-reply from a server for control plane policing. (No it are not low cost routers)
We have chosen for a stable network, which is in our case without SLAAC. We will not change this. So there will be no research projects with android.

Regards

Derk

[Comment deleted]

I have been reading this issue for some time and have been considered responding. I would have thought, Lorenzo, that the multiple use cases presented would be evidence enough for you it turns out I am incorrect in that assumption.

Just like you are incorrect in many of the assumptions you have been making. You are deliberately disabling a feature that is desperately required by some network operators in order to support IPv6 on their WiFi network for something that essentially boils down to a UX issue. As has been pointed out, warning the user that certain features are not available on a network is probably the way to go.

You have assumed that the people who want to deploy this are deploying for 464xlat (i.e. IPv6 only), this is not the case, and you will find the majority of them are deploying it for Dual Stack networking. Thus negating the need for a second address for 464xlat in the first place.

The restriction of 1 IP address per node breaks tethering, yes, however given that the kind of networks that require DHCPv6 (enterprise networks) will not be happy with tethering, this is also alright. Simply stating that "tethering will not work for IPv6 access in this network" when someone starts a tethering session will solve this issue from the users perspective.

You are indeed correct that "if the assertion is that DHCP is needed for tracking purposes, it's worth observing that DHCP by itself provides no security [You must] also enforce bindings between IP addresses and MAC addresses, to ensure that the host is not using a different IP address than the one it obtained via DHCP. But if the network is already doing that, then it's simple to simply log those bindings from the first-hop router's ND cache". However, unfortunately a lot of the time the tools that enterprise environments have available are not built to do this sort of logging.

They should probably be, but that isn't something that should be held to ransom over Enterprise WiFi deployments of IPv6. If we want to get Android on board we have to use an arbitrary set of tools that support the very specific way one guy at Google want us to implement it?

I think we need to rephrase this for you. No one here is asking you to implement managed network support DHCPv6 on Android. We're TELLING you to. We shouldn't have to explain the why. Or to put it another way, as Android is open source: implement DHCPv6, or get forked (and no, that wasn't a typo. I am sure as this issue becomes more and more important over time, someone will create an AOSP fork that supports DHCPv6).

Yes, this does create UX problems that you need to consider. So consider them, and as you consider them, lodge them as more issues you need to deal with upstream.

In the meantime, give the people what they want. They want DHCPv6. They don't need to justify this requirement to you Lorenzo.

I'm just going to leave this here...

http://www.networkworld.com/article/2939436/lan-wan/it-pros-blast-google-over-android-s-refusal-to-play-nice-with-ipv6.html

Come on guys, you should all know by now that Google doesn't give a damn about you, your opinions, or your networks.

They're not scared of a fork because Android isn't really opensource (good luck running an android fork without all of the google services)- they're open source marketing, not open source in reality.

At the same time they don't care about the network admins because they know you'll be forced to hack support for their crappy devices in or you'll be hearing from the boss (or someone else high enough up to make a stink) about how their device doesn't work.

This thread has been here for almost three years. They know it's a problem, and they don't care.

I've followed this thread for ages and always hoped that there would come a time where the Android developers realize how wrong they are (or is it really just one persons religious opinion?)!

Android disqualifies itself for enterprise deployments - period.

If that is your desired goal, you have successfully left the enterprise market to the other vendors (and indirectly consumer buying decisions, since enterprises will not support Android BYOD handhelds).

But being an optimist, I still believe that the big device manufacturers will not be of the same opinion, to leave that market for others, and eventually someone will be reasonable and just go support the existing standards.

Until that time I will refuse all employees with an Android handset IPv6 connectivity on IBM's global enterprise network, for which I am responsible for the IPv6 roll-out.

Oh dear, this is a bit of a pile on. I don't think anyone is being religious here, it's just a case of differing priorities.

I'm just a neutral observer who came to this thread via the news story linked earlier. So let me try and draw some conclusions from the thread so far. It probably won't affect anyone's decisions but perhaps it'll help cool the rhetoric a bit, if everyone can see each other's perspectives. Apologies if I've mischaracterised anyone's positions.

What we have here is a conflict between the needs and desires of several different constituencies: end users, developers and network operators. In this thread Lorenzo is trying to represent the needs of end users and developers. Everyone else, as far as I can tell, is a network operator.

Network operators have a particular set of requirements: things like satisfying the legal department, implementing various network policies, being able to use existing hardware/software stacks and so on. Undoubtably many have deadlines to meet for their IPv6 rollouts. Some of them feel the shortest path to achieving these goals is to enforce a 1 device = 1 address policy, and they wish to do this with DHCPv6 address allocation.

As Android does not fit into this approach they feel understandable frustration: they have a job to do, this is a roadblock, so why is Google making their jobs difficult? Everyone knows this feeling. It always sucks.

Trying to be tactful and possibly failing, they also feel powerful. Many of them are in monopoly positions. If they just block all Android devices entirely, what are their users going to do? Take their business to a competing IT department? Hence, they cannot understand why their arguments are not considered final: it's their network and if they want to inconvenience users of the most popular smartphone OS then they will absolutely do that, so deal with it.

Users have simple needs: they want to plug their devices and apps together in whatever combination they choose, and have it all work. They want this because users also have jobs to get done, and sometimes the IT department gets in their way. It's a variant of the well known "post-it note with your password" problem. They do not want to see jargon-filled error messages, or alerts that their network operator is blocking their chosen configuration, especially if the devices in question could work around that error and provide some kind of semi-working service anyway.

App developers have not been heard from at all on this thread. Their needs are the hardest to characterise because almost by their nature, apps that the network makes hard to write often don't get written. I have some experience of this from working on peer to peer apps myself. And developers are so used to the crappyness of the IPv4 internet that their expectations are already at rock bottom: if the IPv6 internet turns out to be just as riddled with bizarre exceptions and quasi-broken setups, they won't complain much because it'll only be what they're already used to. They are wearily familiar with the costs of a broken network architecture being externalised onto them via complexity like NAT and UPnP.

Worse, often the ideas that may matter most are the ideas no developer invented yet. Lorenzo has tried to describe this when he talked about apps that want multiple addresses for use cases not yet discovered, but I didn't see anyone really engage with his point. Perhaps because it's difficult to weigh the value of unknown future inventions against easily measured deployment costs today.

The founding vision of the IPv6 internet was that nobody, anywhere, should ever suffer technical problems due to a lack of addresses. The point of a 128-bit address space is to make it so huge that you don't have to go beg permission or use weird NAT hacks to do what you want - to want an address is to have an address. This architecture has tremendous benefits in terms of simplifying the lives of users, developers and often network admins as well. But it sometimes comes into conflict with more immediate operational needs. Then the question becomes, who wins?

My sense from this thread is that the Android team is not being religious, or mindlessly obstinate. Rather they're trying to reflect the needs and concerns of constituencies that are otherwise not being represented. They're trying to avoid a situation where the internet collectively snatches defeat from the jaws of victory by making one of the key benefits of IPv6 unreliable - even though it may be done with the best of intentions.

Anyway I don't expect this message to change anyone's positions:  network admins still have deployments to deploy, Android will still have user experiences to, um, experify, and developers will mostly not see this thread and end up discussing these issues five years from now in bug reports against their apps.

But please, let's try to avoid flaming fellow internet engineers or accusing them of religion.

[Comment deleted]

@140: With respect, I don't think you have all the facts of the situation clear. While I don't think Lorenzo is being religious, I do think he is misguided.

Lorenzo (and let us be clear, so far on the face of the issue we have only heard from him, if other engineers at Google agree I would like to hear their perspective too) has given vague an unsatisfactory answers as to why he will not implement DHCPv6 client support on Android.

After much probing, the sole reason appears to be UX, specifically with regard to tethering. This as an excuse is unsatisfactory to the other engineers in the room. This isn't a differing opinion, this is, quite literally us saying "with the reasons as given we don't understand your objection". Especially considering the reason we want this support is on WiFi. To be clear: we don't care if you only allow DHCPv6 on WiFi and enforce SLAAC over mobile networks.

To be a little more specific, let's talk about the need niches you mentioned and how we can solve them.

OPERATORS:
Network policies:
Stateful firewall and proxies. This does not require any special considerations unless a certain group of users are given specific differing permissions that require extra firewall rules. Knowing, with certainty, what addresses these devices will use is much easier to implement in DHCPv6. SLAAC in this will most likely require MAC based firewall filtering, which while possible is not very well supported. DHCPv6 gives a definite advantage in this space.

Audit requirements
Auditing traffic on SLAAC involves an intrusive practice that many L3 switches and routers do not support, or do support but with massive CPU overhead that compromises network performance. Often replacing equipment is infeasible considering the cost of one switch can go in the order of tens of thousands of dollars. DHCPv6 is therefore a must in this space for a lot of operators.
 
Misc requirements
Privacy extensions add extra address usage which in some switch models causes problems. This is despite the fact that privacy extensions, per the RFC, is supposed to be elective. Many operating systems enable privacy extensions on SLAAC by default, and with BYOD operators cannot reasonably expect to ask users to turn this off. DHCPv6 works around this problem by enforcing N=M where N is the allocated addresses an M is the required addresses (Note that I didn't say N=M=1. Often it will, but it should not be assumed like it was in IPv4. This and NAT are two practices that we need to educate some operators away from. It is safe to say that the vast majority of operators deploying NOW are not in this subset.)


USERS:
Just works: (The only real requirement)
While operators are working with equipment or software that doesn't allow them to use SLAAC, be it hardware limitations, audit software limitations, or firewall software limitations, IPv6 will NOT BE DEPLOYED. This means IPv6 will not work on Android unless it support DHCPv6 or by some miracle they invest upwards of hundreds of thousands of dollars updating the networking equipment and software. DHCPv6 support is an obvious advantage here.

464XLAT:
This is only a problem in networks where operators assume N=M=1 and operators are not deploying dual-stack. This space is NOT GOING TO BE WiFi networks for at least a decade considering all the legacy IPv4 only systems an Enterprise will likely need to support. If 464XLAT is required, you would think that because of said IPv4 legacy requirements that the WIFI OPERATORS WILL TEST THIS TO MAKE SURE IT WORKS. This is a non-issue if ever there was one.

Tethering:
First off, if tethering is required on WiFi, you're doing it wrong. This is the first objection, if we have a secondary device that needs access that cannot connect to WiFi natively, our first question is going to be "Why can't that connect to WiFi natively?"

Operators do accept that sometimes there is a legitimate answer to that question, smart watches come to mind as a possible example. However, this is only going to be a problem where operators think N=M=1. So we're talking about an EDGE CASE OF AN EDGE CASE here right now. But again, this is an operator education problem, and not the fault of DHCPv6.

APPLICATION DEVELOPERS:
IPv6 support now:
Application developers are a special case, but only because they need IPv6 support in order to test IPv6 support. They will be given special sandboxes with multiple different deployment models for testing. One such deployment model WILL BE DHCPv6. iOS solved this problem by mandating IPv6 support in the next release (iOS 9), which requires App developers to make sure their application uses generic, higher level, application calls when requesting resources, and encouraging testing in IPv6 only networks.

I expect Google will want to do the same with Android, and then Application developers might start saying "why does this application work with iOS in my work provided IPv6 testing network, but it doesn't work with Android?" only to be told that Google refuse to implement DHCPv6  support. I wonder what their reaction will be then? I honestly don't know.

So while I admire Lorenzo's apparent regard for the users in general, I still don't understand what his objection is. If his problem is with Operators who aren't going to provide him DHCP-PD or the ability to allocate more than one address, then unfortunately I think he's going to have to get over this and find a way to get Android gracefully fail in this situation.

The Operators who are willing to listen to him and address his concerns, like myself, still require DHCPv6 support for very legitimate reasons. Compromise is a two way street, and while some operators have attempted to investigate the feasibility of moving to SLAAC, running the WiFi network on SLAAC as a special case, and other such things to work around this BUG, I have seen no such compromise from Lorenzo.

You talk about Operators in monopoly positions here. What about Lorenzo's monopoly? Why does he get a free pass for such tactics?

Given all of the information in this thread:

1. Are there objections to implementation aside from tethering?

2. If not, can we move ahead with implementation with an asterisk stating that there are potential known issues with tethering, and refer to a separate bug report?

3. Can we hear thoughts for or against implementation by other developers?

I want this, please.  Management of static leases at the router are then possible.

Without DHCPv6, you've wrecked MIPv6 [RFC6275] by not allowing for retrieval of its options [RFC6610]

I found this thread and followed it from the top.  Looking at implementing IPv6 (network and dev) I too am of the opinion that the only downside (or side of the argument against with any validity) is tethering.

Neither I nor anyone I know has used Tethering on wifi, so DHCP in IPv6 should be possible on Android, if someone is going to be hard-nosed about it then don't support it on mobile data, but the code needs to be added for Wifi.

I do see the point around *not* doing NAT for mobile connections, but the outcome of this is going to be determined by (in my view) how individual mobile operators view the situation...

Will they allocate a /48 per subscriber (in which case no NAT is necessary and a /64 can be presented by Android to clients) or will each handset be treated as 1 IP (in which case NAT will be inevitable) - this is a might bigger issue and beyond the scope of "Android should support dhcp client on Wifi".

Dear Lorenzo Colliti, please implement stateful DHCPv6.  For questions on how to implement DHCP forwarding with tethering, refer to http://www.howtogeek.com/137784/it-geek-how-to-use-a-dhcp-relay-junos/

Anyone who claims DHCP inhibits tethering is an idiot.  Yeah, I said it.

I just returned a couple brand new android phones because of this bug.  iOS forevah!  Death to droid!

... well this and the lack of automtic teredo tunneling (or any other transitional methods).  What's 'ip6tnl0' supposed to do?  Cause on 5.1.1, it does nothing

You know, the fact that this bug report still has activity after being set to 'Declined' 8 months ago should be some indicator that it is still desired as a feature.

My campus is going the way of 'screw Android' (although the internal descriptions of our plan usually use much more colorful language) and implementing a DHCPv6 only network. Luckily for Android users, we are also dual-stacked, so they'll still be able to reach the commodity Internet for the near-term until IPv6 picks up more availability.

When is the 'suck_an_egg_lorenzo' fork happening?

Dear all,

Like everybody else here I'm also affected by this issue.
Since Fairphone has a dhcpv6 implementation I decided to analyze their ROM.
I found out that they are using the wide-dhcpv6 client and some custom scripts around the binary.

I've created a little Android app that bundles the dhcp client with an installer and some helper scripts: DHCPv6 Client. My app requires **root permissions** and installs the DHCPv6 client from Fairphone (wide-dhcpv6) on the phone and then invokes it on a configurable basis.

You can configure the list of interfaces you want to do DHCPv6 on: WiFi, Mobile (rmnet0) or just any interface available. (configurable through the advanced menu in my App)

Usually the DHCP client would run as a daemon and renew leases in the background. Since this doesn't work on Android when interfaces disappear and reappear later, my app uses a broadcast receiver to trigger the client each time the connectivity changes.

You can download the app from the official Google Play Store:
https://play.google.com/store/apps/details?id=org.daduke.realmar.dhcpv6client

And join the discussion on XDA-Developers:
http://forum.xda-developers.com/android/apps-games/app-dhcpv6-client-t3176443

Any feedback would be appreciated :)

Regrads

Anastassios

Windows 8 does this right, I think.

They use DHCPv6 to get the prefix and other information.
Then, they generate a temporary IP which is entirely random instead of the IP they are assigned. But it gets all the necessary information, which makes it work.

If you did this, it would not break tethering.

Bump. Thus is still a desired feature. Tethering is nice to have, walk before you run though...

well said #153

stateful DHCPv6 feature missing makes Android unusable in an enterprise environment.

Please add support. end of line, end of file, end of discussion.

Let's hope Marshmellow will finally fix this issue.

Hi! I'm use Android 5.1 and dhcpv6 in my wireless network infrastructure.
I'm obtained dhcpv6 leases on my device.
The log dhcpdv6:
***************************************************************************************
Oct 10 11:15:20 server dhcpd: Solicit message from fe80::a232:99ff:fe07:c706 port 546, transaction ID 0xED463D00
Oct 10 11:15:20 server dhcpd: Advertise NA: address 2a01:d0:8124::cb to client with duid 00:01:00:01:1d:a5:5b:3a:c6:9a:d9:6e:0c:2c iaid = 234883274 valid for 43200 seconds
Oct 10 11:15:20 server dhcpd: Sending Advertise to fe80::a232:99ff:fe07:c706 port 546
***************************************************************************************
Result the device (using LanDroid):\
***************************************************************************************
Interfaces:
   ip6tnl0
   ccmni0
   ccmni1
   ccmni2
   lo
      IPv6: ::1
      IPv4: 127.0.0.1
   sit0
   ifb0
   ifb1
   p2p0
   wlan0
      IPv6: 2a01:d0:8124::cb
      IPv6: fe80::a232:99ff:fe07:c706
      IPv4: 192.168.0.141
   tunl0

Ipv4 Routes:
   192.168.0.0/255.255.255.0  dev wlan0
   default via 192.168.0.1 dev wlan0

IPv6 Routes:
   2000::/128 via fe80::7271:bcff:fed5:3700 dev wlan0
   2a00:1450:4010:c02::bc/128 via fe80::7271:bcff:fed5:3700 dev wlan0
   2a00:1450:4010:c09::69/128 via fe80::7271:bcff:fed5:3700 dev wlan0
   2a01:d0:8124::/120  dev wlan0
   2a01:d0:8124::/64  dev wlan0
   2a01:d0:8124::cb/128  dev lo
   2a01:d0:8124::cb/128  dev wlan0
   ::1/128  dev lo
   default  dev lo
   default via fe80::7271:bcff:fed5:3700 dev wlan0
   fe80::/64  dev wlan0
   fe80::a232:99ff:fe07:c706/128  dev lo
   ff00::/8  dev wlan0

WLAN connection:
   AP(BSSID): bc:ae:c5:c4:43:33
   Name(SSID): "homewlan"
   Signal(Rssi): -30
   IP: 192.168.0.141
   Netmask: 0.0.0.0
   Gateway: 192.168.0.1
   Dns1: 192.168.0.1
   Dns2: 0.0.0.0
   Dhcp Server: 192.168.0.1
   Lease duration: 18000s
   Mac Address: a0:32:99:07:c7:06
   SupplicantState: COMPLETED

Tracing google.com:

1. 2a01:d0:8124::1  (vl6.132.lan)
2. 2a01:d0:ffff:124::1  (tb.netassist.ua)
3. 2a01:d0:0:1c::3
4. 2a01:d0::25:2
5. 2001:4860::1:0:63c5
6. 2001:4860::8:0:9d95
7. 2001:4860::2:0:5f07
8. ???
9. 2a00:1450:4010:c02::65:
***************************************************************************************
Thank U!