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.