On 6/8/2015 11:35 PM, Christopher Morrow wrote:

On Mon, Jun 8, 2015 at 11:19 PM, Randy Bush <randy@psg.com> wrote:

...

...

We're in the beginning steps of bringing up IPv6 at the fairly large university where I work. We plan to use DHCPv6 rather than SLAAC for a variety of reasons. One of our guys recently noticed that Android has no support for DHCPv6, and a rather odd issue thread discussing it: curious about the reasoning, for what is probably singular devices on a LAN ?

Lack of RDNSS support in Windows? That's the complication on my IPv6-only network. Matthew Kaufman

On Tue, Jun 9, 2015 at 3:09 AM, Paul B. Henson <henson@acm.org> wrote:

On Tue, Jun 09, 2015 at 07:30:48AM +0100, Alan Buxey wrote:

...

Care to elaborate on the reasons?

Heh, there's a reason I said "variety" ;). Honestly, I'm like 90% systems and 10% network, our network guys could probably better explain all of the underlying thought process. My primary task on the deployment is standing up the DHCPv6 servers and IPv6-enabling our operating systems and applications. If you look at comment #101 on the issue thread, that's actually from one of of network admins briefly discussing some of the underlying rationale.

it seems as though the large concern is: "network gear wont' hand out resolver data" you'll have v6 and v4 right? dual-stack would let you still get dns services over v4 while providing v6 transport as necessary/available. there seem to be some other largely un-numbered concerns about 'router management' ... but I'd submit that there are quite a few dual-stack networks out there (campus and wide-area and consumer) and we're not seeing this sort of problems supposed. -chris

Hi,

and we wonder at the pitiful ipv6 deployment.

if more network admins actually did network stuff then IPv6 deployment would be plentiful and we could even start the discussion about turning off IPv4.... ;-) alan

Agreed - apparently the solution is to implement SLAAC + DNS advertisements *AND* DHCPv6. Because you need SLAAC + DNS advertisements for Android, and you need DHCPv6 for Windows. Am I the only one that thinks this situation is stupid? On Tue, Jun 9, 2015 at 1:17 PM, Randy Bush <randy@psg.com> wrote:

i love this discussion. another enterprise wants to use ipv4 with minimal change from ipv4, has problems, and the usual suspects tell them to drink koolaid.

and we wonder at the pitiful ipv6 deployment.

randy

On Tue, Jun 9, 2015 at 4:27 PM, Joel Maslak <jmaslak@antelope.net> wrote:

Agreed - apparently the solution is to implement SLAAC + DNS advertisements *AND* DHCPv6. Because you need SLAAC + DNS advertisements for Android, and you need DHCPv6 for Windows.

Am I the only one that thinks this situation is stupid?

If you think this is stupid, look in to the situation for modern WiFi and Android. https://code.google.com/p/android/issues/detail?id=17972 https://code.google.com/p/android/issues/detail?id=59502 https://code.google.com/p/android/issues/detail?id=62076 Summary: - No 802.11k (though 802.11r in barely new devices) - No DFS Channel support in Nexus-branded units, due to Google's resistance to certification. - Most WPA2-Enterprise schemes are sullied with warnings about traffic being monitored as a response to private CAs being installed. Windows support for enterprise features is downright stellar in comparison. --Doug

Once upon a time, Doug Clements <dclements@gmail.com> said:

If you think this is stupid, look in to the situation for modern WiFi and Android.

Haven't bothered to see if there's a bug (since my experience with Android and Google bug reports was a waste of time), but since my Android devices (Samsung and LG) upgraded to Lollipop, I no longer have functioning IPv6 on wifi. They connect and get an address (with privacy extensions even), but do not install an IPv6 default route. They can talk to local IPv6 devices, but not the Internet. The phone handles IPv6 over the cell network fine. This used to work; now we have progress! -- Chris Adams <cma@cmadams.net>

On Tue, Jun 09, 2015 at 02:56:26PM -0700, Owen DeLong wrote:

Further, the cellular companies would do well to be more adaptive to the capabilities that exist in the hardware rather than insisting that they choose the solution and the hardware makers must adapt.

Hahahahahaha! Fun fill in the blanks game: "We're the phone company, __ ___'_ ____ __ ____." - Matt -- <FreeFrag> The most secure computer in the world is one not connected to the internet. Thats why I recommend Telstra ADSL. -- bash.org/?168859

On 6/9/15, 11:06 PM, "Lorenzo Colitti" <lorenzo@colitti.com> wrote:

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

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

WG] I have suggested before that google needs to do the same thing with their app developers. Since you believe that your market power makes you able to influence the way that people deploy IPv6 (i.e. Not using DHCPv6 because you refuse to support it), perhaps it's time to wield that power to move the needle on IPv6 use in the app community instead of telling network operators that are deploying IPv6 that they're "doing it wrong"?

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

WG] or you could argue that not supporting stateful DHCPv6 blocks IPv6 deployment by preventing it from being used on networks where it is otherwise available on applications that are perfectly happy to have one IPv6 address. That's a lot of traffic that ends up going to the NAT for no good reason. Thanks, Wes Anything below this line has been added by my company’s mail server, I have no control over it. ----------- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

On Tue, 9 Jun 2015, Chris Adams wrote:

Android devices (Samsung and LG) upgraded to Lollipop, I no longer have functioning IPv6 on wifi. They connect and get an address (with privacy extensions even), but do not install an IPv6 default route. They can talk to local IPv6 devices, but not the Internet.

My Nexus4 with Android 5.1.1 works just fine with IPv6 on wifi. So talk to your handset manufacturer, they must have broke something. -- Mikael Abrahamsson email: swmike@swm.pp.se

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

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

This is not how current Android works. Each network can run IPv4, IPv6 or both independently of any other network. If you can reproduce this on a device running current Android (preferably a Nexus device), please file a bug. There is indeed an issue with OEMs dropping RAs when the screen is off. Because it is the OEM that provides the wifi firmware and not Android, it's not really fair to say it's an Android bug. FWIW, recent Nexus devices do not have that bug.

On Tue, 9 Jun 2015, Tony Hain wrote:

I filed a platform bug on this back in the ICS timeframe, and it still persists. As I recall, there are 2 flags provided by the OS related to RA handling. Rather than using the one that sets a preference between the Cell vs. Wifi interface, at least Samsung (possibly others) have chosen to use the other flag that says to completely ignore the WiFi RA if an RA on the Cell interface has ever occurred. This means devices that have no IPv6 on their Cell interface will appear to work fine on WiFi.

I just re-verified (same Nexus4 using 5.1.1 on swedish mobile provider Tele2): I disable wifi. I have dual stack on my mobile bearer (PDP context). Verified with 10/10 for both ipv4 and ipv6 on test-ipv4.com (no 464xlat though, this is NAT44:ed IPv4 and native IPv6 on the mobile side). I enable wifi. After a few seconds the Nexus4 connects to my home wifi and starts using it, I get 10/10 for IPv4 on test-ipv4.com and 9/10 for IPv6 because my provider DNS resolver doesn't support native IPv6 lookups.

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

Well, it's not present on my Google device anyhow. -- Mikael Abrahamsson email: swmike@swm.pp.se

On Jun 9, 2015, at 4:43 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:

On Tue, 9 Jun 2015, Joel Maslak wrote:

...

Agreed - apparently the solution is to implement SLAAC + DNS advertisements *AND* DHCPv6. Because you need SLAAC + DNS advertisements for Android, and you need DHCPv6 for Windows.

Am I the only one that thinks this situation is stupid?

You don't need to hand out addresses by means of DHCPv6 IA_NA to windows, it does A=1 mode for SLAAC just fine.

There is a big difference between handing out resolver, ntp-server, dns search domains etc by means of DHCPv6, and handing out addresses based on DHCPv6 (stateless vs stateful).

...

From what I have understood Android has made design decisions that means some things will break if you would only give is a single IPv6 address. This is most likely what some operators want to achieve when they say they want to use DHCPv6 IA_NA.

In order to actually solve the problem they're trying to solve, you need SAVI (https://tools.ietf.org/wg/savi/) and 802.1x (or similar mechanism) in order to actually gain the control these people are looking for. My question, do they implement this on IPv4?

It’s way more fun to fight about it when NDP and DHCPv4 were coming of age at the same time, and DHCP was seen as only a minor upgrade to BootP at the time. The IPv6 purists seem to think that DHCP == NAT == EVIL at times which is frustrating. The result is we have both M=0, M=1, etc.. options and something can be sent via NDP or DHCP, including possible DHCP-PD in conjunction. The reality is I need things to “just work”. It was interesting to inherit someones half-done IPv6 implementation on our VPN platform, they didn’t understand that proxy-arp didn’t really exist in IPv6 land and the block had to be routed to the VPN box. There are many minor and subtle differences in these technologies which become obvious when some time is spent digging through them. - Jared

On 6/9/15 1:27 PM, Joel Maslak wrote:

Agreed - apparently the solution is to implement SLAAC + DNS advertisements *AND* DHCPv6. Because you need SLAAC + DNS advertisements for Android, and you need DHCPv6 for Windows.

Am I the only one that thinks this situation is stupid?

No, you're not. Some of us have been saying that requiring RA is a bad idea, and that adding features to it is a bad idea, for over 15 years now. Unfortunately the anti-DHCP crowd hasn't budged, no matter how many operators have told them that they cannot manage an IPv6 network with the current state of the protocol. Doug -- I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks!

Hi,

supporting DHCPv6 seems to be that mobile networks don't need it, but that totally ignores 802.11 which is equally important.

...and what about 802.3 for those Android boxes/systems on the wired? :-)

I would hope we're past the religious arguments of SLAAC vs DHCPv6 but it seems like every time the topic comes up the entire conversation turns into a holy war on what method is the best. They're both valid, and both useful.

agreed....too many times I find out that DHCPv6 is chosen as a stateful method because they want to record/track MAC addresses like they do for DHCP.... a little bit of explaining the protocol differences and they soon take up the SLAAC ;-) alan

On Wed 2015-Jun-10 12:01:52 +0900, Lorenzo Colitti <lorenzo@colitti.com> wrote:

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

...

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

No, the premise is that from a user's point of view, DHCPv6-only networks cause regressions in functionality compared to IPv4-only or dual-stack networks. For example: IPv4 apps cannot be supported at all due because 464xlat cannot be made to work...

Pardon my ignorance as I don't currently have field experience with 464xlat, but my understanding of the technique is that it is (for the most part) dependent on the network cooperating (by providing a DNS64 and NAT64) for it to work properly. If we take the example of an Android handset on a campus/enterprise, single stack v6 WLAN, is there any way that 464xlat would work without the network operator intentionally providing the necessary infrastructure for 464xlat? E.g. the v6-only network uses SLAAC with RDNSS. The network operator provides resolver addresses to the Android handset via RDNSS, and those resolvers aren't DNS64. The handset queries for ipv4only.arpa, and since the resolvers provided by the operator via RDNSS are not DNS64, it gets NOERROR rather than a Prefix64-synthesized AAAA. Result: the handset determines there is no DNS64 in the path, and hence 464xlat is not possible. Assume we tweak this to say the handset is very independent-minded and queries its own set of DNS64 resolvers. Further assume that the network operator doesn't block DNS queries out to random DNS servers on the internet from client devices. For that to work, the DNS64 has to answer recursive queries from this handset from a v6 address within the random v6-only network the client device currently finds itself on, so you're either looking at needing to provide an open resolver or have some other magic to auth the handset to the DNS64 before answering its queries. Assuming we get this far, the NAT64 indicated in the Prefix64 stuffed into the synthesized AAAAs provided by the DNS64 now also needs to provide NAT64 services to the client device coming from the random v6-only network, again by either simply providing free services to whomever comes calling or authenticating the handset in some way if it's off-net, originating on the random v6-only network in question. Owing to my ignorange in this space, I'm not aware of too many publicly available DNS64/NAT64 services, though some quick searching reveals a handful of such sites. They appear to be mostly research networks, so not really anything that I would be comfortable pointing to as a long term viable solution at which to point my clients/handsets. If I'm misinformed and e.g. T-Mo plans on making their DNS64/NAT64 infra publicly available and hard-coding client devices to point at it, I stand to be corrected. That is an *awful* lot of assumptions we have to break through to get to a working 464xlat service working on a random v6-only WLAN if the 464xlat infra is not provided by that WLAN's operator. So, we either need to fulfill a checklist of *several* longshot assumptions/configurations, or we're looking at an environment where 464xlat is being provided by the network operator for it to have a snowball's chance of working. If the network operator is providing the 464xlat and they *want* that 464xlat to be available on this v6-only WLAN, then it is *their* responsibility to ensure that their chosen v6 address assignment solution (SLAAC or DHCPv6) works with 464xlat and is e.g. capable of PD or multiple v6 addresses per client. If they *choose* to run a v6-only network without a v4 access solution and hence with the regressions you listed, is it your job to tell them they shouldn't do that or to tell your users they can't participate in that network?

...and functions such as tethering cannot be implemented because there are no IP addresses to assign to downstream devices.

You had noted on the bug/request: "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." Your whole argument of DHCPv6 breaking tethering, 464xlat, and other technologies that require multiple addresses per interfaces hinges on this assumption. It does not hold true in all cases (multiple posters have pointed to solutions such as multiple DUIDs), and in some cases operators may be *intentionally choosing* to design the network with such limitations in place (research nets; pilot networks; things neither of us have thought of yet). Is it really your assertion that your users would be better served *not* being able to connect to these networks *at all* than to connect to them on the terms dictated by the network operator? On a bit of a side note: Multiple posters on the bug/request are coming from enterprise/campus networks that have existing AUPs and enforcement techniques prohibiting certain network functions (e.g. content filtering, restricted outbound access, etc.), and would be making an *active choice* as to whether they do or do not want to support functions such as tethering, 464xlat, etc. If I find myself on such a WLAN, restricting what I'm trying to do, TBH I write it off as something being done intentionally or broken in the network, drop off the WLAN and just do it on the cell network. Does the average user do something different?

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

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

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

And there it is: "SLAAC is better and it isn't that hard; use it instead." It is up to the network operator to make the design choices that best fit their network, including if their design goals are to *restrict* certain network functions. You are saying that you know better. -- Hugo [1] https://www.nanog.org/sites/default/files/wednesday_general_byrne_breakingfr...

On Tue, Jun 9, 2015 at 11:43 PM, Lorenzo Colitti <lorenzo@colitti.com> wrote:

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

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

We use DHCPv6 to assign just one IP address to the CPE. This is because otherwise our routers do not know where to route the /48 that is also passed along with DHCPv6-PD. The routers are stupid I know, but it is what we got. So we simply implemented a variant of static routes for 2001:db8:x::/48 to 2001:db8::x/128. The DHCP server knows to give you matching /48 and /128. Apart from operational simplicity, we also do not want our routers to keep track of a million ND cache entries. Our system pushes that down to the CPE. In the network we only have one ND cache entry per customer. The Android tethering guy seems to think that tethering should be a bridge. But it should of course be routed. The phone in tethering mode should be getting exactly what we do - one /128 on the uplink interface and a ton of address space it can use internally and sub delegate to tethering clients. What exactly is the argument against supporting a sane environment like that? As a side note, NAT is not the only solution if someone should try to block tethering. I would propose a VPN tunnel. You can then have as much address space you want from the VPN. This is extra easy if you are not locked into the belief that tethering should be a bridge instead of routed. Regards, Baldur

On 10 June 2015 at 14:03, Mikael Abrahamsson <swmike@swm.pp.se> wrote:

On Wed, 10 Jun 2015, Baldur Norddahl wrote:

We use DHCPv6 to assign just one IP address to the CPE. This is because

...

otherwise our routers do not know where to route the /48 that is also passed along with DHCPv6-PD.

If you use DHCPv6-PD you only need a LL address, you do not need a GUA address. Yes, a GUA WAN address is nice for fault finding, shows up in traceroute etc, but it's not needed. If your routers require a GUA WAN address in order for DHCPv6-PD to work, then they're not standards compliant.

I need the GUA to have a stable and predictable next hop for my static route of the /48 prefix delegation. What standard exactly requires my router to be able to snoop a DHCP-PD to create routes dynamically? That was left out and one solution is the one we use. Note that the /48 static routes are configured on the routers well in advantage of the customer even signing up for the service. It is just there waiting for a customer to be assigned the corresponding /128.

Apart from operational simplicity, we also do not want our routers to

...

keep track of a million ND cache entries. Our system pushes that down to the CPE. In the network we only have one ND cache entry per customer.

Well, if you have a GUA /128, then you have two per customer (because you'll have the LL one as well). If you didn't use the GUA address, you'd only have one.

Yes my bad, we will have exactly two cache entries per customer. That is still better than SLAAC with unbounded caches and all the possibility of getting DoS attacks on NDP, extra CPU use etc on my network. Why would I want that, when I can deliver perfect service to the customer with a fixed cache of 2 entries? I have nothing against SLAAC it just does not belong in the carrier network. Regards, Baldur

On 10 June 2015 at 15:53, Mikael Abrahamsson <swmike@swm.pp.se> wrote:

Well, then you're not doing what most people do when they do DHCPv6-PD, you're using something else. This is the first time I have heard of anyone doing what you describe.

I mentioned because the Android guy seems to be guilty of knowing how everyone does or want to run their network. There are always more ways to do this than you thought of. Normally it's done by the router acting on DHCPv6 packets and installing a

route if need be.

I would probably do it like that if my equipment had support. But it does not. And I can not point at any RFCs to tell my vendor that their stuff is broken, because the requirement simply is not in any RFCs. Also consider this: 1) The DHCP relay might not be the same router that needs to do the forwarding. 2) There might be more than one router that can forward. 3) There might not even be a DHCP relay, the DHCP server could be attached directly. In our case we have GPON access switches that do DHCP(v6) snooping. These things can block illegal traffic, but other than that, they are purely layer 2 devices. There is no relay there and no layer 3 forwarding, so no routes can be installed by anything. Upstream from the access switches there are many ways you can structure your network. You might want to have two routers for redundancy. You may attach the DHCP server directly here if it is a small network (although we use relays). Static routes with a fixed GUA next hop for the /48 prefix delegations means you can have some pretty dumb (=cheap) stuff in your network. All you need is an intelligent DHCP server and that is just open source software on a Linux. I considered having the DHCP server add the routes via a script that is triggered by lease handout. But the fixed static routes is much simpler and robust.

I do agree that you do not want your equipment sitting in the same broadcast domain as all the customers devices, but do use PD. I'm just baffled by the way you have implemented "PD".

We all work with the equipment we got and the quirks in there. Just do not go around and assume everyone has the same requirements as you. Saying there is no use case for DHCPv6 except for PD is dumb and that was why I put forward a use case to illustrate how this is used in the real world. At least by us. Regards, Baldur

On Wed, 10 Jun 2015, George, Wes wrote:

On 6/10/15, 9:13 AM, "Baldur Norddahl" <baldur.norddahl@gmail.com> wrote:

...

What standard exactly requires my router to be able to snoop a DHCP-PD to create routes dynamically? That was left out and one solution is the one we use.

WG] We use this in cable-land, so it's definitely documented in the DOCSIS standards. Not sure it exists anywhere in the IETF standards, and so YMMV on which platforms do and do not support it.

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_dhcp/configuration/1... "DHCPv6 Relay Agent Notification for Prefix Delegation The DHCPv6 relay agent notification for prefix delegation allows the device working as a DHCPv6 relay agent to find prefix delegation options by reviewing the contents of a DHCPv6 RELAY-REPLY packet that is relayed by the relay agent to the client. When a prefix delegation option is found by the relay agent, the relay agent extracts the information about the prefix that is being delegated and inserts an IPv6 static route matching the prefix delegation information onto the relay agent. Future packets destined to that prefix via relay will be forwarded based on the information contained in the prefix delegation. The IPv6 static route is then left in the routing table until the prefix delegation lease time expires or the relay agent receives a release packet from the client releasing the prefix delegation." I can't find IETF standards language apart from this: "14. Relay agent behavior A relay agent forwards messages containing Prefix Delegation options in the same way as described in section 20, "Relay Agent Behavior" of RFC 3315. If a delegating router communicates with a requesting router through a relay agent, the delegating router may need a protocol or other out-of-band communication to add routing information for delegated prefixes into the provider edge router."

From what I can find, a lot of vendors seem to have functionality implemented to look at the relayed messages and install static routes without any OOO-communication.

-- Mikael Abrahamsson email: swmike@swm.pp.se

From: Mikael Abrahamsson Sent: Wednesday, June 10, 2015 12:05 AM

You seem to fail to realise that you are not Lorenzos customer, his customer is the OEMs that build mobile phones, and their customers who buy Android phones.

And he fails to realize that the people who buy android phones actually want them to work. And the companies manufacturing android phones want their users to be satisfied. And when every single mobile phone other than an android phone does seem to work, who do you think they're going to blame? I can already tell you our helpdesk response "Unfortunately, the android operating system does not fully implement IPv6 standards and as such is not capable of interoperating with our network. Consider switching to an iPhone, or a Windows Phone, or a [every other phone that works]."

So while you are doing what you think is best for your network, Lorenzo is doing what he thinks is best for his platform and the hundreds of millions of Android users that are out there.

I am sure all of those millions of users sleep better at night knowing that omniscient and caring Lorenzo is looking out for their long-term interests while denying them short-term usability.

So I happen to agree with Lorenzo that a single IA_NA per device world is a crippled world. Lorenzo said he was willing to work on a document that creates a recommendation for certain minimum amount of IPv6 addresses per device and/or PD, so let's get that happening then?

How about we support existing already widely deployed Internet standards so they can be used while future standards are being developed?

On 6/9/15, 11:01 PM, "Lorenzo Colitti" <lorenzo@colitti.com> wrote:

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

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

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

WG] ok, I *finally* understand the distinction you're making here, despite the weird way you're making the argument. You're equating DHCPv6-only with "single stack IPv6", which is odd, because you're simultaneously waving away concerns about android not working on IPv6-only networks because it won't be able to get addresses by saying that you assume that no one is turning off IPv4 on their network tomorrow since that'll break lots of other things. The reality is that this whole argument is needlessly conflating multiple things in a way that isn't helpful, so I'm going to try to break this into pieces in order to make forward progress and try to get us away from what is devolving into a debate that is equal parts religion and kool-aid drinking contest among IPv6 übernerds. 1) there are *dual stack* networks out there that happen to support IPv4 and IPv6 via DHCP only (I.e. No SLAAC). This is a fact, and you may not like it, but there's simply no way that you're going to be able to change it in 100% of the situations. Most of the folks involved in this discussion are asserting that Android needs to support those so that the things that can work over IPv6, even with just a single address, will. 2) on a dual stack network, when the device gets fewer IPv6 addresses than it wants/needs, it can continue using the same solution it uses on an IPv4 network, even if it's a sub-optimal NAT-based solution. Having a single IPv6 address is still a net improvement over where we are today, where 100% of the traffic has to be on IPv4 and probably behind multiple layers of NAT. 3) 464xlat being broken is a non-issue on a dual-stack network, since it is expressly designed to act as a shim for IPv4-dependent apps on an IPv6-only network. 4) At some point in the future, there will be IPv6-only networks. At that time, Android will no longer be able to rely on IPv4 as a fallback mechanism, and if it can only get one address, that will break things. Definitely a problem, but not necessarily one that has to be solved immediately, since anyone doing an IPv6-only network today already knows that they need to make a lot of allowances for transition mechanisms and other things to prevent breakage, or are using IPv6-only in tightly controlled situations where there is no breakage because they can ensure 100% IPv6 support among the things using the network. 5) there are multiple possible ways for a device to get multiple IPv6 addresses if it needs them, including DHCPv6 with multiple IA_NA requests, a DCHPv6-PD request, SLAAC, or some sort of bridging that allows multiple virtual interfaces to use the same physical interface, such as the simple type of hypervisor networking that allows multiple VMs to get DHCP addresses assigned from the same network. So what this means is that there is a draft to be written about the need for multiple address support on IPv6 networks for mobile devices, enumerating the ways that they use those multiple addresses, and how it differs from today's IPv4-only or dual-stack implementations, along with a big discussion on the breakage that can happen on IPv6-only networks if a device can't get the addresses it needs. It is a fool's errand to assume that we can dictate one and only one solution to #5 (regardless of one's perceived influence and market power), so the best we can do is to document the preferred one(s) and hope that we've made a good enough case or made them easy enough to use that the majority of network operators do support them. Sunset4 is the right place for that draft, so let's discuss it at the next IETF. However, the spectre of #4 does NOT mean that DHCPv6 is unusable because it would break things today on a dual-stack network, so you need to stop trying to imply that, and stop trying to optimize for use cases that you yourself admit basically don't exist today by blocking support for something that we could use today to have more devices using IPv6, were it available. Thanks, Wes George Anything below this line has been added by my company’s mail server, I have no control over it. ----------- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

From: Lorenzo Colitti <lorenzo@colitti.com<mailto:lorenzo@colitti.com>> Date: Wednesday, June 10, 2015 at 11:21 AM To: "George, Wes" <wesley.george@twcable.com<mailto:wesley.george@twcable.com>> Cc: NANOG <nanog@nanog.org<mailto:nanog@nanog.org>> Subject: Re: Android (lack of) support for DHCPv6 "I don't think it's a good plan to implement stateful DHCPv6 now and postpone the solution of the problem until IPv4 goes away many years from now. By then, a lot of water will have flowed under the bridge by then, and a lot of one-address-only networks will have been deployed and have moulded industry thinking. So, much as it pains me to stand in the way of IPv6 adoption - and you should how much I've tried to do on that front - I think that that wide deployment of one-address-per-device IPv6 might actually do more harm than good, and I expect that many operators who are going to require stateful DHCPv6 addressing are going to use it for one-address-per-device IPv6. I really think it's better if we get this right now, not kick the can down the road. That means we as an industry need to find a solution for IPv6 deployment in university/enterprise networks that does not devolve into one-address-per-device IPv6, *before* one-address-per-device IPv6 becomes universally implemented and usable." WG] I wasn't suggesting kicking the can. I agree that we need a solution, and getting started on it now so that the guidance and potential solutions are available as soon as possible is the right plan, because it reduces our potential reliance on IPv4 as a fallback for those things that need multiple addresses today. However, I think you're going to have a lot of trouble building consensus for your view that the right response is to try to completely block one-address-per-device IPv6 deployment by any means possible, and I think you're going to have even less success actually doing it, given that most other devices have already built support for it. Turning off IPv4 on a dual-stack network is a major change, as complex (or more) than deploying IPv6 to start with, especially if you haven't been focused on getting everything using IPv6 so that it's not dependent on IPv4, not to mention those unpredictable users. So I don't think it's unreasonable to expect that some changes to the existing IPv6 deployment will be necessary to support such a thing, and therefore I disagree with your assertion that allowing one-address-per-device in the short term will lead to unsolvable problems later, due to inertia or otherwise. It's also not guaranteed that everyone doing stateful DHCPv6 will limit devices to one address, so we need to be a bit careful with the prognostications of universal doom. Rhetorical question: given the growing evidence that IPv6 is often lower latency than IPv4, and Google's heavy focus on improving performance for user experience (page load times, SPDY, etc) especially in the mobile space, how long do you think you'll really be able to justify not supporting IPv6 on a subset of deployments to avoid the risk of future tragedy before you're overruled by the potential to shave off a few more ms of latency? Thanks, Wes Anything below this line has been added by my company’s mail server, I have no control over it. ---------- ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

On Wed, 2015-06-10 at 11:48 +0900, Lorenzo Colitti wrote:

With stateful DHCPv6 addressing, we're back to using NAT again.

Hope the question doesn't make me look like an idiot, but why does using stateful DHCPv6 mean having to go back to NAT? Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882

Once upon a time, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> said:

On Wed, 10 Jun 2015 12:59:47 +1000, Karl Auer said:

...

Hope the question doesn't make me look like an idiot, but why does using stateful DHCPv6 mean having to go back to NAT?

How does the device ask for a *second* DHCPv6'ed address for tethering or whatever?

It's called "bridging". Let whatever is being tethered ask directly for its own address. -- Chris Adams <cma@cmadams.net>

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

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

Ooo, that's fun, can I play too? BGP - RFC 4271 - DRAFT STANDARD USM for SNMPv3 - RFC 3414 - INTERNET STANDARD

On Tue, 9 Jun 2015, Jon Bane wrote:

When I build something I want people to use, I tend to put in the features they need and want so they continue to use it. It is crystal clear here and in the bug post, that people need DHCPv6 on WiFi. We don't need your guiding hand to protect us from ourselves. We need the tools to manage our environments to meet our requirements, not yours.

What would you find acceptable behaviour from a device that finds itself on a wifi network that only gives it a single DHCPv6 IA_NA ? That some apps silently stop working because 464XLAT doesn't work, that it throws up a splash screen for the user to say that the network its connected to doesn't work, or that it just doesn't use this network and continues to use cellular (basically like it would one where the connection manager can't verify connectivity), and also that tethering won't work. -- Mikael Abrahamsson email: swmike@swm.pp.se

On Tue, 9 Jun 2015, Jon Bane wrote:

Isn't that the problem of the network operator? To know and accept the tradeoffs for how they operate their network? If this theory that DHCPv6 is going to break the world comes true, then the operators will adjust their methods. Personally, I find operating a dual-stack network far simpler than futzing with XLAT or NAT64. It is a known configuration vs. a complete list of unknown gotchas in translation solutions. Not to mention the added complexity on the client and the network edge.

Ok, so lets see a scenario going forward: Android starts to support IA_NA and IA_PD. If it only gets a single IA_NA, 464XLAT and tethering (and potentially even more functionality in the future) doesn't work. How long do you think it'll take before we have a similar discussion here about why Android doesn't support NAT66 to workaround those problems? -- Mikael Abrahamsson email: swmike@swm.pp.se

On Tue, Jun 9, 2015 at 11:14 PM, Chris Adams <cma@cmadams.net> wrote:

Once upon a time, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> said:

...

On Wed, 10 Jun 2015 12:59:47 +1000, Karl Auer said:

...

Hope the question doesn't make me look like an idiot, but why does using stateful DHCPv6 mean having to go back to NAT?

How does the device ask for a *second* DHCPv6'ed address for tethering or whatever?

It's called "bridging". Let whatever is being tethered ask directly for its own address.

it remains to be seen if that would actually work, and it's probably network-dependent, right? If your notional network implemented SAVI restrictions then a single dhcpv6 assigned address might be all you get. A bunch of this discussion (on both sides) seems (to me) get get back to: "I designed something, took a left turn and kept on driving.... and I just don't want to revisit assumptions." Example: "I do not want to support SLAAC because I don't want to do RDNSS, I will provide dns servers/etc via dhcpv6" Example: "We will not support DHCPv6 because people might assign one address only." Both of those have a way to a solution, neither has to be a hard/fast rule, right?

Of course I've been up too long, ignore the idiot (me). :) On Tue, Jun 9, 2015 at 9:37 PM, Joel Maslak <jmaslak@antelope.net> wrote:

Most APs don't support bridging, not enough addresses in the protocol (without enabling WDS or whatever modern versions of that are).

On Tue, Jun 9, 2015 at 9:14 PM, Chris Adams <cma@cmadams.net> wrote:

...

Once upon a time, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> said:

...

On Wed, 10 Jun 2015 12:59:47 +1000, Karl Auer said:

...

Hope the question doesn't make me look like an idiot, but why does using stateful DHCPv6 mean having to go back to NAT?

How does the device ask for a *second* DHCPv6'ed address for tethering or whatever?

It's called "bridging". Let whatever is being tethered ask directly for its own address. -- Chris Adams <cma@cmadams.net>

On Tue, 2015-06-09 at 23:09 -0400, Valdis.Kletnieks@vt.edu wrote:

How does the device ask for a *second* DHCPv6'ed address for tethering or whatever?

RFC 3315 says you just chuck in multiple IA_NA (or IA_TA) options. The server will respond with multiple addresses. And if a device makes a second (, third, fourth, ..) request with a different DUID, it'll get a second (,third, fourth,...) address oo, I guess. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882

On Tue, 9 Jun 2015, Michael Thomas wrote:

Wouldn't the right thing to do is have the provider support dhcp prefix delegation, and the tether can run dhcp for its clients? (or even slaac?)

Do you think the people who insist on wanting to use DHCPv6 IA_NA will instead be fine with DHCPv6 IA_PD /64 per device instead? The device doesn't *have* to have IA_NA on the "wan" interface, it could assign this /64 to itself and use it for tethering and its own use, so with A=0, M=1, O=1 DHCPv6 could give (minimum, preferrably larger like /62 or /60) /64 PD and this would solve Lorenzos stated problem (albeit with added code). -- Mikael Abrahamsson email: swmike@swm.pp.se

In message <5577C6BE.6020905@mtcc.com>, Michael Thomas writes:

On 06/09/2015 08:37 PM, Karl Auer wrote:

...

On Tue, 2015-06-09 at 23:09 -0400, Valdis.Kletnieks@vt.edu wrote:

...

How does the device ask for a *second* DHCPv6'ed address for tethering or whatever? RFC 3315 says you just chuck in multiple IA_NA (or IA_TA) options. The server will respond with multiple addresses.

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

Wouldn't the right thing to do is have the provider support dhcp prefix delegation, and the tether can run dhcp for its clients? (or even slaac?)

Yes. Providers should support both IA_NA and PD. Tethering could have been done properly with PD at the time but it was decided to leave PD to the next round of the phone spec. as as a result there was all the prefix sharing kludges.

Mike -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Wed, 2015-06-10 at 15:32 +0900, Lorenzo Colitti wrote:

It's certainly possible to make Android request N IPv6 addresses via DHCPv6, and not accept the offer if it is offered fewer than N addresses. But that only really makes sense if there's a generally-agreed upon minimum value of N. I'd be happy to work with people on an Internet draft or other standard to define a minimum value for N, but I fear that it may not possible to gain consensus on that.

You need as many as you need. Request them. Worry about it if you don't get them. This is exactly what happens when N=1, BTW. A DHCPv6 server is almost certainly not going to have an upper limit that significantly crimps your style... Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882

On Wed, 2015-06-10 at 19:49 +0900, Lorenzo Colitti wrote:

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

I think that's a wrong question, or maybe I am completely missing your point. Seems to me that N will vary depending on what you are trying to do. And you could well be trying to do several things at once, each with a different requirement. And these things may happen over time, so that at one time you need N, while later you need ten times that many - or half as many, or none. With DHCP you just ask for more when you need more, or release ones you don't need. You don't have to arrange everything up front and then be stuck with it. You know how many addresses you need to provide a given service; you know how to degrade the service gracefully, or whether a graceful degrade is even possible. In other words, you the requester know how many addresses you want and how many you have to have - which are two possibly quite different numbers. Addresses are just a resource, and like any other resource, if the environment can't supply them, you either degrade the service, fail to provide it, or possibly keep trying and provide it later when the resource becomes available. At their most basic, standard DHCPv4 and DHCPv6 clients do exactly that - they keep trying until they get addresses. Not being able to get enough addresses is pretty much like not being able to get enough RAM or disk space, but you make it sound like running out of power! It is not an all-or-nothing proposition at a platform level, and demanding to know "what is N?" implies that it is. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882

On Wed, Jun 10, 2015 at 2:06 PM, Lorenzo Colitti <lorenzo@colitti.com> wrote:

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

...

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

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

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

Laudible goal. I think with mifi devices typically limiting to 8/16 I have a sense that a /56 (which btw, was the unit we expected to use for mass-customer deployment edge numbering) is going to be ok. Its inevitable that in some other N+ years, we're going to be astonished by how many IPs are needed behind the connecting device, but a /56->/64 gap is going to work for now. So pragmatism drives me to say 'we probably have enough in the model we're working on' I say this, because whilst I personally don't like the HD ratio model, its what we adopted as a global measure of density of use, and I think respecting allocation practice which reflects the HD ratio model is good, and drives us to /56 for mass-customer deployments. (I know there are policy people who may believe /48 is where we're going to go. I can only say thats not how I understand address allocation modelling works in many regions, right now. I also know there are people who think a single customer can be a /128. I don't agree with that either) -G

On Wed, 2015-06-10 at 21:06 +0900, Lorenzo Colitti wrote:

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

...

Seems to me that N will vary depending on what you are trying to do. A model where the device has to request resources from the network before enabling tethering, or before supporting IPv4-only apps, provides a much worse user experience. The user might have to wait a long time, or the operation might even fail.

I understand. I took issue only with the idea that any value of N could be "right". Don't forget though that IPv4 phones also need resources from the network - their public IPv4 addresses. Why isn't that a showstopper too? Hm... The essential difference with IPv6 compared to IPv4 is that (due to address abundance) all addresses are (or at least can be) globally routable. There can be a direct bidirectional relationship between a connected device and the world; of necessity, that relationship brings with it a higher degree of interdependence. It's a pretty simple thing really: You can have all that that IPv6 offers (both now and potentially), or you can cripple it so that the user experience is "just like IPv4". I get where you are coming from. It's just a bit sad, is all. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882

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

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

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

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

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

...

And that's not counting future applications that can take advantage of multiple IP addresses that we haven't thought of yet, and that we will have if we get stuck with

there-are-more-IPv6-addresses-in-this-subnet-than-grains-of-sand-but-you-only-get-one-because-that's-how-we-did-it-in-IPv4

...

networks.

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

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

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

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

On Wed, Jun 10, 2015 at 8:35 AM, Tore Anderson <tore@fud.no> wrote:

* Lorenzo Colitti

...

Tethering is just one example that we know about today.

In android's case I am perpetually bemused by the fact they use dnsmasq for tethered dhcp, and dnsmasq long ago added support for doing smarter things with slaac, and dhcpv6. Merely upgrading that package in the android distro would get everything needed except dhcp-pd support into android (for which openwrt has got some decent daemons for). dnsmasq is not used in android for dns (which is too bad as dnssec support was also added to it and I hope most of the bugs ironed out, in the last 3 years), as their dns resolver is in java and is admittedly mildly more secure if less featureful. I am told that well over 50% of all android development comes from volunteer developers so rather than kvetching about this it seems plausible for an outside effort to get the needed features for tethering and using dhcpv6-pd into it. If someone wanted to do the work.

...

Another example is 464xlat.

You can't do 464XLAT without the network operator's help anyway (unless you/Google is planning on hosting a public NAT64 service?). If the network operator actively wants 464XLAT to be used, by providing DNS64/NAT64 service, then it seems fairly reasonable to assume that they're not going to deploy an IPv6/DHCPv6-only network that limits the number of IA_NA per attached node to 1.

...

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

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

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

Tore

-- Dave Täht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast

Once upon a time, Lorenzo Colitti <lorenzo@colitti.com> said:

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

Except for the ones that don't. Tethering is far from "just works, period." VPNs, VOIP, and games are things that don't always just work (behind any kind of NAT). -- Chris Adams <cma@cmadams.net>

From: Lorenzo Colitti Sent: Wednesday, June 10, 2015 5:07 AM

getting rid of NAT. Today in IPv4, tethering just works, period. [...] IPv4-only apps always work.

Wow. If your phone just "always works", you certainly lead a charmed life.

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

Far better that the user stare at the useless android brick in their hand that is incapable of connecting to the network at all. Maybe you should try taking a poll of actual users? Dear user, would you rather: A) have a phone that connects to the network and the most part works barring some side cases B) have a phone that is incapable of connecting, but saves you from being unable to use certain functionality that otherwise would have been unavailable. By preventing you from using any functionality at all.

Hi Lorenzo,

It's certainly possible to make Android request N IPv6 addresses via DHCPv6, and not accept the offer if it is offered fewer than N addresses. But that only really makes sense if there's a generally-agreed upon minimum value of N. I'd be happy to work with people on an Internet draft or other standard to define a minimum value for N, but I fear that it may not possible to gain consensus on that.

I definitely think we should start pushing for N>1 because that will really hurt IPv6 in the future. However any fixed N is a potential danger as requirements will change in the future. But maybe we can do something smarter here.

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

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

Asking for more addresses when the user tries to enable features such as tethering, waiting for the network to reply, and disabling the features if the network does not provide the necessary addresses does not seem like it would provide a good user experience.

I don't think it is unreasonable. If the network doesn't support the features you need then let the user know (grey out the feature and add a note that says "broken network"). It will put pressure on the network department to fix their DHCPv6 implementation. I have read Lorenzo's arguments and while I don't agree with all of them I do see the risk of creating a situation where N=1 is the default. That would be bad. But instead of not supporting DHCPv6 I think we should work on making sure N>>1. Cheers, Sander

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

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

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

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

In practice, your device will just not be supported.

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

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

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

Oh, I definitely see that DHCPv6 is easier for network operators. But even if you're dead set on using DHCPv6, what I don't see is why don't you support DHCPv6 PD instead of IA_NA? It's the same amount of state. Same accountability. Same transaction model. But unlike NA, the device gets as many addresses as it needs. Nothing breaks, and you get future flexibility. Mobile devices don't have to implement NAT, and application developers don't have to work around it. You size your IPv6 pools based on the size of your IPv4 pools, and don't run out of addresses. Technically, that sort of arrangement is superior to IA_NA in basically every way. So... why use IA_NA? Even if the answers are "that's what we do in IPv4, and we want to do it the same way", or "we're worried that this is strange and will tickle vendor bugs", "it's not supported by the IPAM we use today", or "this is what we've decided, our network our rules", I would hope that we as an industry can think a little longer term than that. Also, in terms of hotspot functionality being the major driver

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

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

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

It is possible to implement DHCPv6 without implementing stateful address assignment. If there were consensus that delegating a prefix of sufficient size via DHCPv6 PD of a sufficient size is an acceptable substitute for stateful IPv6 addressing in the environments that currently insist on stateful DHCPv6 addressing, then it would make sense to implement it. In that scenario, Android would still not implement DHCPv6 NA, but it would implement DHCPv6 PD. What needs to be gauged about that course of action is how much consensus would be achieved, whether network operators would actually use it (IPv6 has a long and distinguished history of people claiming "I can't support IPv6 until I get feature X", feature X appearing, and people changing their claim to "I can't support IPv6 until I get feature Y"), and how much of this discussion would be put to bed. That course of action would seem most feasible if it were accompanied by an IETF document that explained the deployment model and clarified what "sufficient size" is.

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

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

Ray, please do not construe my words on this thread as being Google's position on anything. These messages were sent from my personal email address, and I do not speak for my employer. Regards, Lorenzo On Thu, Jun 11, 2015 at 12:15 AM, Ray Soucy <rps@maine.edu> wrote:

Respectfully disagree on all points.

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

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

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

...

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

...

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

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

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

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

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

...

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

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

-- Ray Patrick Soucy Network Engineer University of Maine System

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

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

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

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

Did you intentionally leave the "in that scenario," words that came right before the ones you quoted? How does a sentence that says "in that scenario, android would <X>" constitute a statement of direction?

I don't really feel I was trying to take things out of context, but the full quote would be: "If there were consensus that delegating a prefix of sufficient size via DHCPv6 PD of a sufficient size is an acceptable substitute for stateful IPv6 addressing in the environments that currently insist on stateful DHCPv6 addressing, then it would make sense to implement it. In that scenario, Android would still not implement DHCPv6 NA, but it would implement DHCPv6 PD." To me, that's essentially saying: "EVEN IF we decided to support DHCPv6-PD, and that's a big IF, we will never support stateful address assignment via DHCPv6." This rings especially true when compared against the context of everything else you've written on the subject. I think that's how most others on this list would read it as well. If that isn't what you meant to say, then I'm sorry. I'm certainly not trying to put words in your mouth. I still feel that it's a very poor position to take. Given that you don't speak for Google on the subject, if you're not the decision maker for this issue on Android, could you pull in the people at Google who are, or at least point us to them? A lot of us would like the chance to make our case and expose the harm that Android is doing by not supporting DHCPv6. I think the Android team is very overconfident in their ability to shape the direction of IPv6 adoption, especially with years old Android releases being still in production and it taking incredibly long for changes to trickle down through the Android ecosystem. That delay is also why we have a hard time accepting the mindset that IF you see a need for it in the future you'll add it. That will be 4 to 8 years too late. On Wed, Jun 10, 2015 at 12:29 PM, Lorenzo Colitti <lorenzo@colitti.com> wrote:

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

...

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

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

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

-- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net

On 6/10/15 08:36, Jeff McAdams wrote:

There is no other rational way to interpret your statement than to be a statement of Google's position.

False dichotomies suck.

On Jun 10, 2015, at 11:36 AM, Jeff McAdams <jeffm@iglou.com> wrote:

There is no other rational way to interpret your statement than to be a statement of Google's position.

As someone who posts from a personal email but my management has told me that I’m well identifiable as who I work for, I’m sympathetic to the way one can suffer a bit of personality split when certain business realities come into play. I’m sure people might mock me for it, but lots of people have mocked me for years so why should I care about this one so much? When a business reality or necessity hits you in the face, sometimes you can’t do anything about it. Would I have preferred if Apple and AT&T let me tether on my grandfathered unlimited plan? Sure. Could I do this before on my unlimited GPRS/Edge plan with my Nokia? Of course, but the reality is I can just carry another device/SIM and use a tablet to tether. As google is in a business of selling ads on the internet, I can see why they might not want to pick a fight with a carrier at every stage in the process. The ROI just isn’t there is my guess. IPv6 is mature enough to be widely deployed, but some of these cases need to have some give/take on both sides to work out. I’m reminded of the adage of if both sides are unhappy you cut the baby properly in half. - jared

On 06/10/2015 02:51 PM, Paul B. Henson wrote:

...

From: Lorenzo Colitti Sent: Wednesday, June 10, 2015 8:27 AM

please do not construe my words on this thread as being Google's position on anything. These messages were sent from my personal email address, and I do not speak for my employer. Can we construe your postings on the issue thread as being Google and/or Androids official position? They are posted by lorenzo@google.com with a tag of "Project Member", and I believe you also declined the request in the issue under that mantle.

Oh, stop this. The only thing this will accomplish is a giant black hole of silence from anybody at Google and any other $MEGACORP in a similar situation. Mike

I agree that some of the rhetoric should be toned down (go out for a beer or something, guys ... I did). There is a difference between fiery debate with Lorenzo and a witch hunt, and some of this is starting to sound a bit personal. I shouldn't have worded things the way I did, I went for the cheap shot in one of those last notes and that isn't really constructive. I'm sorry. I think for many this thread represents years of frustration, though, and LC making the statements in the way he did made him a focal point for that frustration. The problem is there are many of us on the "front lines" trying to push for IPv6 adoption outside the bubble of idealism and when people of great influence like LC take positions like DHCPv6 isn't required it's like a slap in the face to all that effort. We really need to see Google and Android come on board with DHCPv6 support and I'm interested in how we can help make that happen. On Wed, Jun 10, 2015 at 7:00 PM, Jeff McAdams <jeffm@iglou.com> wrote:

No.

Given that Lorenzo was posting with absolute statements about Google's approach, and with what they would do in the future in response to hypothetical standards developments, these questions are completely valid.

On Jun 10, 2015 5:24 PM, Michael Thomas <mike@mtcc.com> wrote:

...

On 06/10/2015 02:51 PM, Paul B. Henson wrote:

...

...

From: Lorenzo Colitti Sent: Wednesday, June 10, 2015 8:27 AM

please do not construe my words on this thread as being Google's

position

...

...

...

on anything. These messages were sent from my personal email address, and I do not speak for my employer. Can we construe your postings on the issue thread as being Google and/or Androids official position? They are posted by lorenzo@google.com with a tag of "Project Member", and I believe you also declined the request in the issue under that mantle.

Oh, stop this. The only thing this will accomplish is a giant black hole of silence from anybody at Google and any other $MEGACORP in a similar situation.

Mike

-- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net

I like to think of it more like the command tent ;-) On Wed, Jun 10, 2015 at 9:40 PM, Todd Underwood <toddunder@gmail.com> wrote:

Anyone who thinks Lorenzo hasn't been on the front lines of pushing for IPv6 adoption is pretty late to the party or confused about the state of affairs.

T

On Wed, Jun 10, 2015, 21:30 Ray Soucy <rps@maine.edu> wrote:

...

I agree that some of the rhetoric should be toned down (go out for a beer or something, guys ... I did).

There is a difference between fiery debate with Lorenzo and a witch hunt, and some of this is starting to sound a bit personal. I shouldn't have worded things the way I did, I went for the cheap shot in one of those last notes and that isn't really constructive. I'm sorry.

I think for many this thread represents years of frustration, though, and LC making the statements in the way he did made him a focal point for that frustration.

The problem is there are many of us on the "front lines" trying to push for IPv6 adoption outside the bubble of idealism and when people of great influence like LC take positions like DHCPv6 isn't required it's like a slap in the face to all that effort.

We really need to see Google and Android come on board with DHCPv6 support and I'm interested in how we can help make that happen.

On Wed, Jun 10, 2015 at 7:00 PM, Jeff McAdams <jeffm@iglou.com> wrote:

...

No.

Given that Lorenzo was posting with absolute statements about Google's approach, and with what they would do in the future in response to hypothetical standards developments, these questions are completely valid.

On Jun 10, 2015 5:24 PM, Michael Thomas <mike@mtcc.com> wrote:

...

On 06/10/2015 02:51 PM, Paul B. Henson wrote:

...

...

From: Lorenzo Colitti Sent: Wednesday, June 10, 2015 8:27 AM

please do not construe my words on this thread as being Google's

position

...

...

...

on anything. These messages were sent from my personal email address, and I do not speak for my employer. Can we construe your postings on the issue thread as being Google and/or Androids official position? They are posted by lorenzo@google.com with a tag of "Project Member", and I believe you also declined the request in the issue under that mantle.

Oh, stop this. The only thing this will accomplish is a giant black hole of silence from anybody at Google and any other $MEGACORP in a similar situation.

Mike

-- Ray Patrick Soucy Network Engineer University of Maine System

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

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

-- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net

In message <9DA9C5B8-E60C-4462-873A-EA5052128067@heliacal.net>, Laszlo Hanyecz writes:

Lorzenzo is probably not going to post anymore because of this.

It looks to me like Lorenzo wants the same thing as most everyone here, aside from the university net nazis, and he's got some balls to come defend his position against the angry old men of NANOG. Perhaps the approach of attacking DHCP is not the right one, but it sounds like his goal is to make IPv6 better than how IPv4 turned out.

Things like privacy extensions, multiple addresses and PD are great because they make it harder for people to do address based tracking, which is generally regarded as a desirable feature except by the people who want to do the tracking. DHCPv6 is a crutch that allows operators to simply implement IPv6 with all the same hacks as IPv4 and continue to do address based access control, tracking, etc. It's like a 'goto' statement - it can be used to do clever things, but it can also be used to hack stuff and create very hard to fix problems down the road. I think what Lorenzo is trying to do is to use his influence/position to forcefully prevent people from doing this, and while that may not be the most diplomatic way, I admire his courage in posting here and trying to reason with the mob.

-Laszlo

There is a difference between arguing that additional addesses should be supported and saying stuff consensus and stuff what you want from the product, I am not going to give you DHCPv6 support because it may be used to only hand out only one address. The better long term strategy is to support DHCPv6 and then complain that you can't get a address for 464XLAT and/or a privacy address. Having a brower come up and say "Unable to obtain privacy address. Do you still want to post this request" for every request will have much more impact and is actually solvable with a couple of tweaks to the DHCPv6 configuration than getting policy changed to support SLACC. Recording N addresss against a user (where N is small) is not any harder than recording 1 address and gives the traceback needed. A RFC compliant DHCPv6 server will hand out multiple address by default. I haven't checked ISC's DHCPv6 server and if it doesn't do multiple addresses by default please open a bug ticket (dhcp-bugs@isc.org) as it should. 464XLAT isn't even needed to do IPv4 over a IPv6-only WiFi. There are other ways to do it, e.g. DS-Lite, which work better than 464XLAT. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Jun 12, 2015, at 12:51 AM, Ray Soucy <rps@maine.edu> wrote:

That's really not the case at all.

You're just projecting your own views about not thinking DHCPv6 is valid and making yourself and Lorenzo out to be the some sort of victims of NANOG and the ...

DHCPv6 and Android are just collateral damage here but I think the argument is about steering what the generally accepted form of "end user IPv6 on WiFi" will be. It would be great if we could agree on that so we don't all have to write support for many different ways and provide complicated user interfaces for configuring it, right? Plug and play?

...

university net nazis

Did you really just write that?

As far as "net nazi", I meant it in the same sense as a BOFH. Someone who is intentionally degrading a user's experience by using technical means to block specifically targeted applications or behaviors. And "angry old men" is also not a literal meaning, but an observation of how this has turned into a flame war where it's a lot of seemingly angry people mobbing the Android developer.

What we're arguing for here is choice, the exact opposite of the association you're trying to make here. It's incredibly poor taste to throw that term around in this context, and adds nothing to the discussion.

People are not logical. They adopt a position and then look for information to support it rather than counter it; they even go as far as to ignore or dismiss relevant information in the face of logic. That's religion. And this entire discussion continues to be rooted in religion rather than pragmatism.

DHCPv6 is a tool, just as SLAAC is a tool. IPv6 was designed to support both options because they both have valid use cases. Please allow network operators to use the best tool for the job instead of telling us all we're required to do it your way (can you even see how ridiculous this whole "nazi" name calling is given the position you're taking)

Without getting into all the "actually there is edge case X" discussions, when you connect to a WiFi network at an office, home or public place today, it's pretty 'standard' to find a DHCP server handing out rfc1918 IPv4 addresses, recursive name servers, and the network doing some form of NAT or proxying. This is pretty much what we expect when we open up a laptop and connect to a network, and if it doesn't work we call the help desk and ask why it doesn't do what we expect. Every user application that wants to do peer to peer networking has to come up with some complicated workaround to communicate through the various forms of NAT and proxies. What do we expect to happen with regard to IPv6? I think it would be great if end to end connectivity was common enough that application developers could assume it will be there, and avoid having to do those workarounds. On the other hand, if it becomes common and acceptable to use DHCPv6 to provide a single address only, then applications will just circumvent it once again with things like NAT, VPNs and reflector servers, which actually makes it worse for everyone involved.

You don't get to just say "I'm not going to implement this because I don't agree with it," which is what Google is doing in the case of Android.

The reason Lorenzo has triggered such a backlash on NANOG is that is fundamental argument on why he doesn't see DHCPv6 as valid for the Android is quite frankly a very weak argument at best. If you're going to stand up and say you're not going to do what everyone else has already done, especially when it comes to implementation of fundamental standards that everything depends upon, you need to have a better reason for it than the one Lorenzo provided.

It seems like several people have taken the position that they will use their influence to steer others away from Android because it doesn't work with their chosen network configuration. This to me sounds very much like Android taking the position that the network should support their chosen address configuration protocol instead of that other one. I think in the end we're going to find that both the network side and the client side end up having to support the whole matrix of possible configurations, if the end goal is to provide a good user experience, but this is not a good OS developer and network operator experience because it creates more work for everyone and more trouble for users when the complicated workarounds don't work. -Laszlo

I honestly hope he collects himself and takes the time to respond, because it really is a problem.

As much as you may not want DHCPv6 to be a thing, it's already a thing.

On Thu, Jun 11, 2015 at 7:42 PM, Laszlo Hanyecz <laszlo@heliacal.net> wrote: Lorzenzo is probably not going to post anymore because of this.

It looks to me like Lorenzo wants the same thing as most everyone here, aside from the university net nazis, and he's got some balls to come defend his position against the angry old men of NANOG. Perhaps the approach of attacking DHCP is not the right one, but it sounds like his goal is to make IPv6 better than how IPv4 turned out.

Things like privacy extensions, multiple addresses and PD are great because they make it harder for people to do address based tracking, which is generally regarded as a desirable feature except by the people who want to do the tracking. DHCPv6 is a crutch that allows operators to simply implement IPv6 with all the same hacks as IPv4 and continue to do address based access control, tracking, etc. It's like a 'goto' statement - it can be used to do clever things, but it can also be used to hack stuff and create very hard to fix problems down the road. I think what Lorenzo is trying to do is to use his influence/position to forcefully prevent people from doing this, and while that may not be the most diplomatic way, I admire his courage in posting here and trying to reason with the mob.

-Laszlo

On Jun 10, 2015, at 10:24 PM, Michael Thomas <mike@mtcc.com> wrote:

...

On 06/10/2015 02:51 PM, Paul B. Henson wrote:

...

...

From: Lorenzo Colitti Sent: Wednesday, June 10, 2015 8:27 AM

please do not construe my words on this thread as being Google's position on anything. These messages were sent from my personal email address, and I do not speak for my employer. Can we construe your postings on the issue thread as being Google and/or Androids official position? They are posted by lorenzo@google.com with a tag of "Project Member", and I believe you also declined the request in the issue under that mantle.

Oh, stop this. The only thing this will accomplish is a giant black hole of silence from anybody at Google and any other $MEGACORP in a similar situation.

Mike

-- Ray Patrick Soucy Network Engineer University of Maine System

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

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

The only thing I would add is that DHCPv6 is not just about "tracking" clients. Yes there are ways to do so using SLAAC, but they are not pretty. Giving too much weight to tracking being the reason for DHCPv6 is just as bad as giving too much weight to tethering as the reason against it. It skews the conversation. For us, DHCPv6 is about *operational consistency*. Universities have been running with the end-to-end model everyone is looking to IPv6 to restore for a very long time. When you connect to our network, wired or wireless, you get a public IP with no filtering in place in most cases. We have been living the end-to-end model, and that has given us operational experience and insight on what it actually takes to support access networks using this model. Almost every peer institution I talk to has implemented custom systems refined over decades to preserve the end-to-end model in a time of increasing security incidents and liability. These include IPAM systems, which feed into vulnerability scanning, or host filtering for incident response, etc. These systems are in place for IPv4, and modifying them to support IPv6 (which most of us have done) is relatively easy in the case of DHCPv6. By maintaining consistency between IPv4 and IPv6 we avoid having to retrain hundreds of IT workers on supporting connectivity. By saying that you won't support DHCPv6, you effectively force us into a choice between investing considerable effort in redesigning systems and training IT personnel, while introducing confusion in the support process because IPv4 and IPv6 are delivered using completely different methods. You have just made it cheaper for us to turn to NAT than to support IPv6. That's unacceptable. You might be thinking "well that's just universities and a small percent of users", but the point here is that we do these things for a reason; we've been living without NAT and our collective operational experience doing so is something that would be wise to take into consideration instead of dismissing it or trying to call us names. Organizations running SLAAC who say everything is fine, think everything is fine because IPv6 has received almost no attention from bad actors in terms of security incidents or denial of service attacks. Even well known servers with IPv6 addresses on our network rarely see SSH attempts over IPv6 today. *This will fundamentally change as IPv6 adoption grows*. Are you prepared to be able to deal with abuse reports of hosts on your network participating on denial of service attacks? Can you associate the identity of a system to an individual when law enforcement demands you to do so? How much longer will it take you to track down a host by its IPv6 address to disable it? How many other users have degraded service while they're waiting for you to do that? For most people that are used to the typical IPv4 model (NAT and open pool DHCP), these events are very infrequent, so of course they don't get it. For those of us running a more liberal network which preserves the end-to-end model, free from aggressive filtering on user traffic, these incidents are literally daily occurrences. The fact is that you never know what service a user might enable on their device only to be exploited and degrade service for their peers. So yes, we are looking to the future in the case of DHCPv6, because we've learned from the past. On Fri, Jun 12, 2015 at 3:05 AM, <Valdis.Kletnieks@vt.edu> wrote:

On Fri, 12 Jun 2015 02:07:22 -0000, Laszlo Hanyecz said:

...

...

...

university net nazis

Did you really just write that?

As far as "net nazi", I meant it in the same sense as a BOFH. Someone who is intentionally degrading a user's experience by using technical means to block specifically targeted applications or behaviors.

Well, which is more BOFH-ish:

1) We insist that you connect in a way that allows us to identify and track you for DMCA and other legal requirements that, quite frankly, we'd really rather not have to do, but it's a cost of doing business.

2) We don't let you connect at all because we can't do so without exposing ourselves to more legal liability than we want.

Besides which, that's a total red herring.

If you actually go back and *read*, I don't think anybody's "intentionally degrading by blocking targeted applications" - except those who are refusing to provide features to allow the applications to work on more network configs. The vast majority of us would *prefer* that Android got fixed so it can ask for more addresses and do more stuff. Most of us don't *care* if a user sucks up 13 adresses across 4 devices at the same time - IPv6 addresses are *cheap*. On the other hand, covering your ass when a subpoena shows up and you realize you don't have the data needed to point at the user they're *really* looking for is incredibly expensive.

OK? Let me say that again: We're all asking Google to quit being stubborn and add a feature to Android so we can make the user experience *better*.

Now who you calling a BOFH?

...

On the other hand, if it becomes common and acceptable to use DHCPv6 to provide a single address only

I encourage my competitor universities to design their networks that way. :)

-- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net

On Fri, Jun 12, 2015 at 11:18 AM, James R Cutler <james.cutler@consultant.com> wrote:

“please let me manage my business and don’t take away my tools just to satisfy your prejudices.”

There are probably several ways to interpret that in ways you hadn't considered for this discussion, I can think of a few. They are: - Who is taking away what from who in a University, in order to save who's $$? :-) - Suppression of hate talk/art/literature has historically been used to restrict some businesses for the greater good of mankind. -Jim P.

Once upon a time, Todd Underwood <toddunder@gmail.com> said:

lorenzo already stated that the cost was in user satisfaction related to tethering and the business reason was the desire to not implement NAT in v6 on android.

So, just to roll back for a second, I hadn't really thought about what was being discussed exactly. This is about connecting an Android device to wifi, right? I didn't think you could have an Android device connect to wifi _and_ tether at the same time; when I turn on the hotspot on my phone, it disables wifi client mode (automatically disconnects from any wifi AP) to enable AP mode. I'm pretty sure that's the way all my Android phones have worked. Why is this an issue (i.e. what am I missing)? -- Chris Adams <cma@cmadams.net>

On Fri, 12 Jun 2015, Baldur Norddahl wrote:

Can someone explain to me how Android uses SLAAC to implement tethering?

https://tools.ietf.org/html/rfc7278 -- Mikael Abrahamsson email: swmike@swm.pp.se

Personally my view is that DHCPv6-PD support would be much better for tethering, but I don't get to tell Google how to do that just like they don't get to tell me how to give out addresses. My only request would be if you do implement DHCPv6-PD for tethering, please make it only request a prefix when you actually enable tethering, not as the default. That would be bad for different reasons. Wouldn't the simple play here be for Android to just throw up a message saying "This network does not support tethering" if SLAAC isn't enabled, and to let users complain to local operators if that's something they want? Google doesn't get blamed, operators are happy, and ultimately users have a better experience because the expectations of the network are clear rather than trying something that will likely not work consistently across networks. If the concern is that you don't want to carriers to use DHCPv6 then you could just limit it to 802.11. The point is that there are several options here to address peoples concerns and make IPv6 adoption that much easier, but the position of Google on DHCPv6 support for Android is just another barrier to widespread adoption of IPv6. I honestly appreciate the work Google has been doing for years to promote IPv6 adoption, but they're wrong here. On Fri, Jun 12, 2015 at 11:30 AM, Todd Underwood <toddunder@gmail.com> wrote:

lorenzo already stated that the cost was in user satisfaction related to tethering and the business reason was the desire to not implement NAT in v6 on android.

many people didn't like those reasons or think that they are less important than their own reasons.

shockingly, everyone believes that their own priorities are more important than everyone else's priorities.

the 'cranky about the lack of DHCPv6' crowd has already made their points and further shut down conversation by demanding that lorenzo speak for Google on this thread. indeed, shouting loudly and shutting down conversation was almost certainly the intent of many of the posts here. so mission accomplished.

fists have been pounded. conversation has been halted. well done.

can me move on now?

t

On Fri, Jun 12, 2015 at 11:18 AM, James R Cutler < james.cutler@consultant.com> wrote:

...

Ray Soucy has given us an nice summary. It goes along with “please let me manage my business and don’t take away my tools just to satisfy your prejudices.”

Selection of management policies and implementations is ALWAYS a local issue (assuming consideration of legal necessities). Especially in the end-to-end model, the requirements management of end systems has not changed because the IP layer protocol has changed. This is a good reason for not prohibiting continuing use of DHCP-based solutions. “Purity of protocols” is not a reason for increasing management costs such as described by Ray.

This debate about DHCPv6 has been going on far too long. I want to know how much it will cost the “SLAAC-only” faction to quit fighting DHCPv6. My conjecture is that it would be minimal, especially as compared to the costs for the activities described by Ray.

Putting it differently: What business purpose is served by fighting full-functioned DHCPv6 deployment. Don’t give me any RFC or protocol arguments - just tell me the business reasons for forcing others to change how they manage their business.

James R. Cutler James.cutler@consultant.com PGP keys at http://pgp.mit.edu

...

On Jun 12, 2015, at 10:07 AM, Ray Soucy <rps@maine.edu> wrote:

The only thing I would add is that DHCPv6 is not just about "tracking" clients. Yes there are ways to do so using SLAAC, but they are not pretty.

Giving too much weight to tracking being the reason for DHCPv6 is just as bad as giving too much weight to tethering as the reason against it. It skews the conversation.

For us, DHCPv6 is about *operational consistency*.

Universities have been running with the end-to-end model everyone is looking to IPv6 to restore for a very long time.

When you connect to our network, wired or wireless, you get a public IP with no filtering in place in most cases.

We have been living the end-to-end model, and that has given us operational experience and insight on what it actually takes to support access networks using this model.

Almost every peer institution I talk to has implemented custom systems refined over decades to preserve the end-to-end model in a time of increasing security incidents and liability. These include IPAM systems, which feed into vulnerability scanning, or host filtering for incident response, etc.

These systems are in place for IPv4, and modifying them to support IPv6 (which most of us have done) is relatively easy in the case of DHCPv6.

By maintaining consistency between IPv4 and IPv6 we avoid having to retrain hundreds of IT workers on supporting connectivity. By saying that you won't support DHCPv6, you effectively force us into a choice between investing considerable effort in redesigning systems and training IT personnel, while introducing confusion in the support process because IPv4 and IPv6 are delivered using completely different methods.

You have just made it cheaper for us to turn to NAT than to support IPv6. That's unacceptable.

You might be thinking "well that's just universities and a small percent of users", but the point here is that we do these things for a reason; we've been living without NAT and our collective operational experience doing so is something that would be wise to take into consideration instead of dismissing it or trying to call us names.

Organizations running SLAAC who say everything is fine, think everything is fine because IPv6 has received almost no attention from bad actors in terms of security incidents or denial of service attacks. Even well known servers with IPv6 addresses on our network rarely see SSH attempts over IPv6 today.

*This will fundamentally change as IPv6 adoption grows*.

Are you prepared to be able to deal with abuse reports of hosts on your network participating on denial of service attacks? Can you associate the identity of a system to an individual when law enforcement demands you to do so? How much longer will it take you to track down a host by its IPv6 address to disable it? How many other users have degraded service while they're waiting for you to do that?

For most people that are used to the typical IPv4 model (NAT and open pool DHCP), these events are very infrequent, so of course they don't get it. For those of us running a more liberal network which preserves the end-to-end model, free from aggressive filtering on user traffic, these incidents are literally daily occurrences.

The fact is that you never know what service a user might enable on their device only to be exploited and degrade service for their peers.

So yes, we are looking to the future in the case of DHCPv6, because we've learned from the past.

On Fri, Jun 12, 2015 at 3:05 AM, <Valdis.Kletnieks@vt.edu> wrote:

...

On Fri, 12 Jun 2015 02:07:22 -0000, Laszlo Hanyecz said:

...

...

> university net nazis

Did you really just write that?

As far as "net nazi", I meant it in the same sense as a BOFH. Someone who is intentionally degrading a user's experience by using technical means to block specifically targeted applications or behaviors.

Well, which is more BOFH-ish:

1) We insist that you connect in a way that allows us to identify and track you for DMCA and other legal requirements that, quite frankly, we'd really rather not have to do, but it's a cost of doing business.

2) We don't let you connect at all because we can't do so without exposing ourselves to more legal liability than we want.

Besides which, that's a total red herring.

If you actually go back and *read*, I don't think anybody's "intentionally degrading by blocking targeted applications" - except those who are refusing to provide features to allow the applications to work on more network configs. The vast majority of us would *prefer* that Android got fixed so it can ask for more addresses and do more stuff. Most of us don't *care* if a user sucks up 13 adresses across 4 devices at the same time - IPv6 addresses are *cheap*. On the other hand, covering your ass when a subpoena shows up and you realize you don't have the data needed to point at the user they're *really* looking for is incredibly expensive.

OK? Let me say that again: We're all asking Google to quit being stubborn and add a feature to Android so we can make the user experience *better*.

Now who you calling a BOFH?

...

On the other hand, if it becomes common and acceptable to use DHCPv6 to provide a single address only

I encourage my competitor universities to design their networks that way. :)

-- Ray Patrick Soucy Network Engineer University of Maine System

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

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

-- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net

On Thu, 2015-06-11 at 20:51 -0400, Ray Soucy wrote:

DHCPv6 is a tool, just as SLAAC is a tool. IPv6 was designed to support both options because they both have valid use cases.

Yes, a thousand times yes.

You don't get to just say "I'm not going to implement this because I don't agree with it," which is what Google is doing in the case of Android.

Actually, you DO get to just say that. Anyone can, but especially something as big as Google. And if DHCPv6 turns out to be important enough to enough people, Android will lose market share and either fork, die or change its mind. It wouldn't be the first mobile platform to disappear into the sludge of history.

I honestly hope he collects himself and takes the time to respond, because it really is a problem.

Not for him, and apparently not for Google. It's only a problem for people that want to do DHCPv6 with Android clients. Whether that becomes a problem for Google is another matter. I certainly hope Google sees the light early. Their current stance is very disappointing. And it's odd to see someone at that level so comprehensively missing the point. For someone with the breadth of experience and jacked into the mother lode like Lorenzo - very unusual. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882

From: Laszlo Hanyecz Sent: Thursday, June 11, 2015 4:42 PM

from the university net Nazis

Wow, it must be nice to live in a fairyland utopia where there is no DMCA, no federal laws such as HEOA, and a wide variety of other things you clearly know nothing about that require universities to be able to track their users and manage their networks.

attacking DHCP is not the right one, but it sounds like his goal is to make IPv6 better than how IPv4 turned out.

I don't think a single person here has a goal of making IPv6 worse, nor necessarily has any objection to the improvements he has suggested. OTOH, I think the number of people who think he is making a good decision in refusing to implement DHCPv6 is practically nil.

diplomatic way, I admire his courage in posting here and trying to reason with the mob.

If he really wants to validate his position on not implementing DHCPv6, maybe he should approach all of the other vendors who already did and get them to remove it. Being the one and only holdout on implementing a widely deployed Internet standard looks more like lunatic fringe than visionary leader 8-/.

Well, most systems implemented DHCPv6 support a long time ago. Despite other efforts to have Google support DHCPv6 for Android, nothing has happened. There is nothing wrong with using NANOG to call out a major vendor for this, even if they are a significant sponsor. Just because you don't agree with the direction of the discussion doesn't mean it has no value. On Thu, Jun 11, 2015 at 9:03 PM, Ca By <cb.list6@gmail.com> wrote:

Yeh, we get it. Repeating yourself is not helpful. The horse is dead ....

Please move your android feature request to a forum more fit for your request.

On Thursday, June 11, 2015, Paul B. Henson <henson@acm.org> wrote:

...

...

From: Laszlo Hanyecz Sent: Thursday, June 11, 2015 4:42 PM

from the university net Nazis

Wow, it must be nice to live in a fairyland utopia where there is no DMCA, no federal laws such as HEOA, and a wide variety of other things you clearly know nothing about that require universities to be able to track their users and manage their networks.

...

attacking DHCP is not the right one, but it sounds like his goal is to make IPv6 better than how IPv4 turned out.

I don't think a single person here has a goal of making IPv6 worse, nor necessarily has any objection to the improvements he has suggested. OTOH, I think the number of people who think he is making a good decision in refusing to implement DHCPv6 is practically nil.

...

diplomatic way, I admire his courage in posting here and trying to reason with the mob.

If he really wants to validate his position on not implementing DHCPv6, maybe he should approach all of the other vendors who already did and get them to remove it. Being the one and only holdout on implementing a widely deployed Internet standard looks more like lunatic fringe than visionary leader 8-/.

-- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net

On Thu, Jun 11, 2015 at 4:42 PM, Laszlo Hanyecz <laszlo@heliacal.net> wrote:

Lorzenzo is probably not going to post anymore because of this.

Oh, I imagine we'll all need to take a time-out after this thread; I know it's got my back fur all riled up, too. :(

It looks to me like Lorenzo wants the same thing as most everyone here, aside from the university net nazis, and he's got some balls to come defend his position against the angry old men of NANOG. Perhaps the approach of attacking DHCP is not the right one, but it sounds like his goal is to make IPv6 better than how IPv4 turned out.

If we had the choice of waiting to make IPv6 better, that might be a more laudable position; if we were having this discussion ten years ago, when v4 addresses were still plentiful, pushing for the best future of IPv6 would have been great. Unfortunately, with v4 exhaustion, companies face the decision of "is v6 easy enough to deploy so that I can just do that, or do I stick with v4 and more layers of NAT to stretch my meagre v4 resources out as long as I can." Dogmatic positions like this swing the pendulum firmly towards the latter, unfortunately. He's got balls, I'll definitely say that much. I just feel like his balls are coming to the party ten years too late. :(

Things like privacy extensions, multiple addresses and PD are great because they make it harder for people to do address based tracking, which is generally regarded as a desirable feature except by the people who want to do the tracking. DHCPv6 is a crutch that allows operators to simply implement IPv6 with all the same hacks as IPv4 and continue to do address based access control, tracking, etc. It's like a 'goto' statement - it can be used to do clever things, but it can also be used to hack stuff and create very hard to fix problems down the road. I think what Lorenzo is trying to do is to use his influence/position to forcefully prevent people from doing this, and while that may not be the most diplomatic way, I admire his courage in posting here and trying to reason with the mob.

Without address tracking, devices aren't going to be allowed onto corporate networks. You may hate that, but legal liability makes that an absolute necessity. Like it or not, regardless of whatever privacy extensions, multiple addresses, and PD you push for, in order to use those devices on corporate networks, there must be a way to track which devices had those addresses.

-Laszlo

Matt PS--any discussion of Lorenzo's balls on my part is purely my personal opinion, and is not undertaken on behalf of any employer. In other words, nobody pays me to talk about Lorenzo's balls.

On Thu, Jun 11, 2015 at 7:42 PM, Laszlo Hanyecz <laszlo@heliacal.net> wrote:

DHCPv6 is a crutch that allows operators to simply implement IPv6 with all the same hacks as IPv4 and continue to do address based access control, tracking, etc.

Hi Lazlo, Who are you to tell me how I must or must not use this new technology? I will use it if I please and as I please. Your (and Lorenzo's) arguments that I must not do stateful address assignment do not please me and do not engender me to implement or support your variant of the new technology. You are, of course, welcome to tell me I'm not important enough for you to care. Should you do so, don't expect more than disdain the next time you express frustration with the technology's rate of uptake.

I think what Lorenzo is trying to do is to use his influence/position to forcefully prevent people from doing this, and while that may not be the most diplomatic way, I admire his courage in posting here and trying to reason with the mob.

Hopefully he learned in this escapade that no one, NO ONE, has sufficient position nor influence nor, ultimately, sufficient wisdom to dictate how a technology is to be used. Having offered our respective suggestions, we can but listen as prospective users tell us what additional capabilities they require. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

On Fri, 12 Jun 2015 10:33:55 -0700, Dave Taht said:

The core bits of what I don't understand about the flamage is how hard would it be for an end-user - or corporate client - to just add any of these functionalities to this, cyanogenmod, etc.

What percent of Android users have even *heard* of cyanogenmod?

On Fri, Jun 12, 2015 at 10:51 AM, Todd Underwood <toddunder@gmail.com> wrote:

On Fri, Jun 12, 2015 at 1:43 PM, <Valdis.Kletnieks@vt.edu> wrote:

...

On Fri, 12 Jun 2015 10:33:55 -0700, Dave Taht said:

...

The core bits of what I don't understand about the flamage is how hard would it be for an end-user - or corporate client - to just add any of these functionalities to this, cyanogenmod, etc.

What percent of Android users have even *heard* of cyanogenmod?

a larger percentage than have ever *heard* of IPv6. :-)

game. set. match.

Change and innovation have to start somewhere, and usually occur on the edges of the ecosystem. Good ideas (and bad) get filtered up (or out) that way. Cyanogen is one of several android derivatives innovating (or at least, was, last I looked).

t

-- Dave Täht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast

The thing about this is that I get the impression that there was violent agreement that DHCPv6 with PD would be Good Thing. I think that the disagreement is about single address assignments being a Bad Thing or Good Thing. For Android, it seems that if operators implemented the ability to fetch a prefix that would be great for Android. For operators, if you do DHCPv6-PD and Android implements it... the camel's nose is under the tent... Mike On 06/12/2015 09:53 AM, William Herrin wrote:

On Thu, Jun 11, 2015 at 7:42 PM, Laszlo Hanyecz <laszlo@heliacal.net> wrote:

...

DHCPv6 is a crutch that allows operators to simply implement IPv6 with all the same hacks as IPv4 and continue to do address based access control, tracking, etc. Hi Lazlo,

Who are you to tell me how I must or must not use this new technology? I will use it if I please and as I please. Your (and Lorenzo's) arguments that I must not do stateful address assignment do not please me and do not engender me to implement or support your variant of the new technology.

You are, of course, welcome to tell me I'm not important enough for you to care. Should you do so, don't expect more than disdain the next time you express frustration with the technology's rate of uptake.

...

I think what Lorenzo is trying to do is to use his influence/position to forcefully prevent people from doing this, and while that may not be the most diplomatic way, I admire his courage in posting here and trying to reason with the mob. Hopefully he learned in this escapade that no one, NO ONE, has sufficient position nor influence nor, ultimately, sufficient wisdom to dictate how a technology is to be used. Having offered our respective suggestions, we can but listen as prospective users tell us what additional capabilities they require.

Regards, Bill Herrin

On Wed, Jun 10, 2015 at 8:26 AM, Lorenzo Colitti <lorenzo@colitti.com> wrote:

Ray,

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

Regards, Lorenzo

Ah, Lorenzo, Lorenzo... I was going to just let the thread go quietly by until you pulled out the "I'm not speaking for my employer" card. :( Can we take what you posted here https://code.google.com/p/android/issues/detail?id=32621#c53 from your google.com account to be official Google position, when you closed the issue requesting DHCPv6 support as "Declined?" Again, in comment #109 https://code.google.com/p/android/issues/detail?id=32621#c109 you speak from your Google.com account when you repeat *twice* the position that you won't support stateful DHCPv6: "and not via stateful DHCPv6 address assignment" followed by "while continuing not to support DHCPv6 address assignment." It's hard to not see _that_ as being Google's position, when you post it from your google.com account in response to an issue raised about broken functionality on the Android platform. So perhaps you're right, and the words you use on _this_ thread are your personal opinion; unfortunately, they seem to be the same words and opinions you use from your google.com account when denying input from Android users who don't seem to want their devices to be crippled by incomplete DHCPv6 support. I wonder at what point large enterprises will simply say "sorry, without working DHCPv6 support, Android devices will not be supported on this network"--at which point this will stop being a religious issue, and will shift to being a business issue, as Google will have to decide whether being stubbornly dogmatic while losing large customers is worth it or not. Thanks! Matt PS--just because some poor unfortunate soul found a way to scrape neighbor tables to work around the lack of DHCPv6 lease logs does *not* make it a practical or wise alternative. A certain network has been trying to test out that workaround, and every time they scrape the neighbor table, the CPU on the routers pegs at 100%. PPS--I am likewise posting this from my personal account (which is still running an old enough Cisco image that it pre-dates IPv6 support entirely, making most of this a moot point for me personally). The opinions expressed here are purely my own, and should in no way be construed to apply to anyone but myself, and possibly the mice living in the garage.

Ray Soucy wrote:

Respectfully disagree on all points.

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

In Lorenzo's defense, I believe he is taking the long term pragmatic position, while you appear to be taking the short term idealistic position. For argument's sake... let's assume that a shiny new browser comes along the is designed to limit third party cross site correlation and tracking. It does this by using a different source address for every destination. This browser works fine on any network that allows N>1, but is stuck in the myopic historical world of older browsers on networks where N=1. To the pragmatism point, would you rather have a device like that do N NA requests (creating N ND state entries), or have it do PD (creating 1 ND + 1 Routing entry)? Tony

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

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

...

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

...

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

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

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

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

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

...

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

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

-- Ray Patrick Soucy Network Engineer University of Maine System

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

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

Lorenzo Colitti wrote:

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

Considering that a DOS attack from a node using a lot of addresses to effectively disable logging, SLAAC must not be used, unless maximum N, the maximum number of addresses for a node to have, is standardized ( assuming a node is securely identified through the first hop security, which is necessary to enforce the number of addresses used by each node). Masataka Ohta

I've already written systems to do this kind of thing, but the logging requirements quickly go through the roof for a non-trivial network; especially in the case of temporary addressing now default on many systems. That isn't so much the issue as operational consistency and supportability. The requirement for hosts to be dual stack will exist for some time. For the sanity of IT workers and users alike (most of which don't really know the details of IPv6 and barely understand address scopes let alone multiple addresses) there needs to be some level of consistency between how hosts are addressed and communicate between the two protocols. Saying we'll develop one system for IPv4 and one for IPv6 ultimate results in "Let's not deploy IPv6 just yet". This rings especially true when security concerns come up. Consistency between IPv4 and IPv6 needs to be possible in this transition period, or people simply decide to not deploy. Consistency in addressing and maintaining a one host one address model has major implications for policy construction, flow analysis and incident response, denial of service mitigation, etc. If the consistency isn't there, you need to "re-invent the wheel" for every aspect, then maintain different systems for IPv4 and IPv6 along side one another. Even worse, if we keep seeing adoption held up by inconsistent client implementations I fear we'll start seeing commercial products which NAT or proxy IPv4 to IPv6 to avoid using IPv6 internally. It's very ugly and requires some DNS magic to work, but it's not impossible. We're already seeing this in terms of cloud computing and virtualization. Servers have IPv4 addresses and only a load balancer with an external IPv6 address. We absolutely need to make it possible for people to adopt IPv6 before we can reach a point where IPv4 can go away, and for some organizations the answer of "Just use SLAAC" is simply not acceptable. They just won't do it. Preventing IPv6 adoption hurts us all. And Android not supporting a MAJOR part of IPv6 like DHCPv6 is preventing adoption. On Wed, Jun 10, 2015 at 1:42 PM, Sander Steffann <sander@steffann.nl> wrote:

...

It's not the *only* option. There are large networks - O(100k) IPv6

nodes - that do ND monitoring for accountability, and it does work for them. Many devices support this via syslog, even. As you can imagine, my Android device gets IPv6 at work, even though it doesn't support DHCPv6. Other universities, too. It's obviously not your chosen or preferred mechanism, but it does work.

/me starts to write that whitepaper that educates people on how to do this

Cheers, Sander

-- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net

From: Ray Soucy Sent: Wednesday, June 10, 2015 6:06 AM

As for thinking "long term" and "the future", we need devices to work within current models of IPv6 to accelerate _adoption_ of IPv6 _today_ before we can get to that future you're talking about.

Not supporting DHCPv6 ultimately holds back adoption, which makes people see IPv6 as optional for longer, and discourages deployment because vendor support is all over the place and seen as "not ready".

This isn't theory, we've been _living_ with this as a reality for years now. The networks are ready; the clients are not.

Universities see a constant stream of DMCA violation notices that need to be dealt with and not being able to associate a specific IPv6 address to a specific user is a big enough liability that the only option is to not use IPv6. As I said, Android becomes a second class citizen on the network under your model.

Your ideas are intriguing to me and I wish to subscribe to your newsletter ;). When someone shows up with a device that only supports WEP, or doesn't support WPA2-Enterprise, we tell them they need to replace it with a device supporting current standards that provide the minimum level of security we have decided upon for our network policy. When someone shows up with an android device that can't connect to our IPv6 network, we will tell them to replace it with a device that fully supports current standards. I still find it hard to believe that Google as a corporate entity thinks it is more important to try and force network operators to conform to their ideals for configuration than it is to make android feature equivalent with its competitors.

From: Ray Soucy Sent: Wednesday, June 10, 2015 4:36 AM

In practice, your device will just not be supported. [..] If your client is broken because of an incomplete implementation, I just won't give it an IPv6 address at all. I think a lot of others feel the same way. [...] already provide ubiquitous wireless coverage. I don't want users enabling a hotspot (rogue AP) on campus because it has a negative impact on service for others, so the whole argument is really meaningless in the context of higher education and campus networking.

Yes. That. All of that. I think you'll find a lot of higher education institutions will agree with this viewpoint.

On 6/10/15, 2:32 AM, "Lorenzo Colitti" <lorenzo@colitti.com> wrote:

I'd be happy to work with people on an Internet draft or other standard to define a minimum value for N, but I fear that it may not possible to gain consensus on that.

WG] No, I think that the document you need to write is the one that explains why a mobile device needs multiple addresses, and make some suggestions about the best way to support that. Your earlier response detailing those vs how they do it in IPv4 today was the first a lot of us have heard of that, because we're not in mobile device development and don't necessarily understand the secret sauce involved. This is especially true for your mention of things like WiFi calling, and all of the other things that aren't tethering or 464xlat, since neither of those are as universally agreed-upon as "must have" on things like enterprise networks. I'm sure there are also use cases we haven't thought of yet, so I'm not trying to turn this into a debate about which use cases are valid, just observing that you might get more traction with the others.

Asking for more addresses when the user tries to enable features such as tethering, waiting for the network to reply, and disabling the features if the network does not provide the necessary addresses does not seem like it would provide a good user experience.

WG] Nor does not having IPv6 at all, and being stuck behind multiple layers of NAT, but for some reason you seem ok with that, which confuses me greatly. The amount of collective time wasted arguing this is likely more than enough to come up with cool ways to optimize the ask/wait/enable function so that it doesn't translate to a bad user experience, and few things on a mobile device are instantaneous anyway, so let's stop acting like it's an unsolvable problem. Thanks, Wes Anything below this line has been added by my company’s mail server, I have no control over it. ---------- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

In message <CALFTrnNyvWssFhEJYW8mRjmkYx6i=4nZO+6r7ns5+OU5UYG8eA@mail.gmail.com> , Ray Soucy writes:

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

Or just support DS-Lite along with DHCPv6. DS-Lite does not require its own IPv6 address. 464XLAT and DS-Lite both limit IPv4 packet sizes to less than native. DS-Lite works with DNSSEC. DNS64 doesn't. DS-Lite doesn't require mucking with packet contents. DS-Lite doesn't result in sites being unreachable just because the IPv6 instance is down which is a side effect of DNS64.

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

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

...

On 6/10/15, 2:32 AM, "Lorenzo Colitti" <lorenzo@colitti.com> wrote:

...

I'd be happy to work with people on an Internet draft or other standard to define a minimum value for N, but I fear that it may not possible to gain consensus on that.

WG] No, I think that the document you need to write is the one that explains why a mobile device needs multiple addresses, and make some suggestions about the best way to support that. Your earlier response detailing those vs how they do it in IPv4 today was the first a lot of us have heard of that, because we're not in mobile device development and don't necessarily understand the secret sauce involved. This is especiall=

y

...

true for your mention of things like WiFi calling, and all of the other things that aren't tethering or 464xlat, since neither of those are as universally agreed-upon as "must have" on things like enterprise networks= . I'm sure there are also use cases we haven't thought of yet, so I'm not trying to turn this into a debate about which use cases are valid, just observing that you might get more traction with the others.

...

Asking for more addresses when the user tries to enable features such as tethering, waiting for the network to reply, and disabling the features = if the network does not provide the necessary addresses does not seem like = it would provide a good user experience.

WG] Nor does not having IPv6 at all, and being stuck behind multiple layers of NAT, but for some reason you seem ok with that, which confuses me greatly. The amount of collective time wasted arguing this is likely more than enough to come up with cool ways to optimize the ask/wait/enabl= e function so that it doesn't translate to a bad user experience, and few things on a mobile device are instantaneous anyway, so let's stop acting like it's an unsolvable problem.

Thanks,

Wes

Anything below this line has been added by my company=E2=80=99s mail serv= er, I have no control over it. ----------

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified th= at any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy o= f this E-mail and any printout.

--=20 Ray Patrick Soucy Network Engineer University of Maine System

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

MaineREN, Maine's Research and Education Network www.maineren.net -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

* Lorenzo Colitti:

I think what I said is that supporting DHCPv6-only networks will eventually force OS manufacturers to implement IPv6 NAT. This is because there are many features inside a mobile OS that require multiple IP addresses.

On many networks, there will be fairly tight limits on the number of usable addresses per “port” even with SLAAC, similar to the evolution of Ethernet switching, which led to configurable limits of MAC addresses per port. So you'll likely need IPv6 NAT in the future anyway.

From: Lorenzo Colitti Sent: Tuesday, June 09, 2015 7:49 PM

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

"Implementing stateful DHCPv6 would break planned use cases such as IPv6 tethering" "And it's not possible to enable tethering" "tethering cannot be made to work well" "what do you expect Android to do if given only one IPv6 address and the user turns on tethering" 'Saying "tethering is not available" is not going to fly' Yes, while you have mentioned a few other things, based on your postings on the issue thread tethering seems to be one of your hot topics.

I think what I said is that supporting DHCPv6-only networks will eventually force OS manufacturers to implement IPv6 NAT.

As opposed to not supporting DHCPv6 operation forcing users to adopt phones based on operating systems other than android?

You don't "have to do" SLAAC and RDNSS. For as long as the network provides IPv4, there won't be a problem for anyone.

Thank you very much for being the guy in charge of determining what my problems are. As I already mentioned in the issue thread, one of our motivations for moving forward with IPv6 deployment is that some grants our faculty want to apply for require native IPv6 communication. So an android device that is incapable of connecting to our IPv6 network due to deficiencies in its implementation of IPv6 standards will not be usable for that grant work. But I will be sure to tell the faculty that the android developer responsible for that breakage assures them it is not a problem. After which I will encourage them to switch to another platform which provides for its users' needs rather than its developers' crusades.