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