[180713] in North American Network Operators' Group
Re: Android (lack of) support for DHCPv6
daemon@ATHENA.MIT.EDU (Hugo Slabbert)
Wed Jun 10 01:37:51 2015
X-Original-To: nanog@nanog.org
Date: Tue, 9 Jun 2015 22:36:03 -0700
From: Hugo Slabbert <hugo@slabnet.com>
To: Lorenzo Colitti <lorenzo@colitti.com>
In-Reply-To: <CAKGbBmn+rJ-XRBw9pgCGm6OqPRYK0hkViQOC5T_B7SnKGHtLZg@mail.gmail.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
--ncSAzJYg3Aa9+CRW
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed 2015-Jun-10 12:01:52 +0900, Lorenzo Colitti <lorenzo@colitti.com>=20
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 cho=
ose
>> the solution that fits the environment. The whole premise for not
>> supporting DHCPv6 seems to be that mobile networks don't need it, but th=
at
>> 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=20
464xlat, but my understanding of the technique is that it is (for the most=
=20
part) dependent on the network cooperating (by providing a DNS64 and NAT64)=
=20
for it to work properly. If we take the example of an Android handset on a=
=20
campus/enterprise, single stack v6 WLAN, is there any way that 464xlat=20
would work without the network operator intentionally providing the=20
necessary infrastructure for 464xlat?
E.g. the v6-only network uses SLAAC with RDNSS. The network operator=20
provides resolver addresses to the Android handset via RDNSS, and those=20
resolvers aren't DNS64. The handset queries for ipv4only.arpa, and since=
=20
the resolvers provided by the operator via RDNSS are not DNS64, it gets=20
NOERROR rather than a Prefix64-synthesized AAAA. Result: the handset=20
determines there is no DNS64 in the path, and hence 464xlat is not=20
possible.
Assume we tweak this to say the handset is very independent-minded and=20
queries its own set of DNS64 resolvers. Further assume that the network=20
operator doesn't block DNS queries out to random DNS servers on the=20
internet from client devices. For that to work, the DNS64 has to answer=20
recursive queries from this handset from a v6 address within the random=20
v6-only network the client device currently finds itself on, so you're=20
either looking at needing to provide an open resolver or have some other=20
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=
=20
the synthesized AAAAs provided by the DNS64 now also needs to provide NAT64=
=20
services to the client device coming from the random v6-only network, again=
=20
by either simply providing free services to whomever comes calling or=20
authenticating the handset in some way if it's off-net, originating on the=
=20
random v6-only network in question.
Owing to my ignorange in this space, I'm not aware of too many publicly=20
available DNS64/NAT64 services, though some quick searching reveals a=20
handful of such sites. They appear to be mostly research networks, so not=
=20
really anything that I would be comfortable pointing to as a long term=20
viable solution at which to point my clients/handsets. If I'm misinformed=
=20
and e.g. T-Mo plans on making their DNS64/NAT64 infra publicly available=20
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=
=20
working 464xlat service working on a random v6-only WLAN if the 464xlat=20
infra is not provided by that WLAN's operator. So, we either need to=20
fulfill a checklist of *several* longshot assumptions/configurations, or=20
we're looking at an environment where 464xlat is being provided by the=20
network operator for it to have a snowball's chance of working.
If the network operator is providing the 464xlat and they *want* that=20
464xlat to be available on this v6-only WLAN, then it is *their*=20
responsibility to ensure that their chosen v6 address assignment solution=
=20
(SLAAC or DHCPv6) works with 464xlat and is e.g. capable of PD or multiple=
=20
v6 addresses per client. If they *choose* to run a v6-only network without=
=20
a v4 access solution and hence with the regressions you listed, is it your=
=20
job to tell them they shouldn't do that or to tell your users they can't=20
participate in that network?
>...and functions such as tethering cannot be implemented because there are=
=20
>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=
=20
DHCPv6 will limit the number of IP addresses assigned by DHCPv6 to one per=
=20
MAC address."
Your whole argument of DHCPv6 breaking tethering, 464xlat, and other=20
technologies that require multiple addresses per interfaces hinges on this=
=20
assumption. It does not hold true in all cases (multiple posters have=20
pointed to solutions such as multiple DUIDs), and in some cases operators=
=20
may be *intentionally choosing* to design the network with such limitations=
=20
in place (research nets; pilot networks; things neither of us have thought=
=20
of yet). Is it really your assertion that your users would be better=20
served *not* being able to connect to these networks *at all* than to=20
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=20
networks that have existing AUPs and enforcement techniques prohibiting=20
certain network functions (e.g. content filtering, restricted outbound=20
access, etc.), and would be making an *active choice* as to whether they do=
=20
or do not want to support functions such as tethering, 464xlat, etc. If I=
=20
find myself on such a WLAN, restricting what I'm trying to do, TBH I write=
=20
it off as something being done intentionally or broken in the network, drop=
=20
off the WLAN and just do it on the cell network. Does the average user do=
=20
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."=
=20
It is up to the network operator to make the design choices that best fit=
=20
their network, including if their design goals are to *restrict* certain=20
network functions. You are saying that you know better.
--
Hugo
[1]=20
https://www.nanog.org/sites/default/files/wednesday_general_byrne_breakingf=
ree_11.pdf
--ncSAzJYg3Aa9+CRW
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCgAGBQJVd8zDAAoJEJqxD/2xeDE+g5UQAKPklgQpITRKebUZJ/Xbdlmh
xau79SYcKtc8EIOyYnod3hieZsrjZGsgNtjABSUBZo2YlVWwYp9HPSfb90g+nA0A
tg3Gmuvf0W2vmyIH4gwkRnLjW3fuXDJhx/n/AS6Dl9CBkuPjQxjYybxqef72d+xA
gkLCpSzr09ugWoy1Ig7D2nNoo9HApiCOUGNIn3sc2GoG+2mKPQesfsJiXQDhpWCu
/RuhZASz5d7J5TYcsC1m28F6mWwoURAL8gOFz33Ma8mVQ41RpJftmfPjnVqBkEUK
PffqlaOI9IJbvQEEhQ51BTvH1trmLFi1VhbaC/kIK3x1tJ3XOQqIGUUrVrMuBNAb
YuVvlCfgTjVT6dqCVR3KcyGHtFpwNM4z0DuXUCCs2IjNwWwaA1veeHSi7TjEb6s3
QZ58iGXYo3dNueRi6gLzh50HPW+C1tEzNYyJRR9vpTsoK41fSAxtISSYWlwM9lFV
mbDUDzbKTo4QOjgUKu5i8LaKh/6vSLQCY7kHhLIO39Gje5Jtc8pZzmojK9kb1aji
YG5vu0b2vYz8TRvJRbuXg3vlUCCcMDKS3f4wLu24oMlmF5nFXGMt/KyvkwKENnxd
g7YQO3o5Y/5NOmUUOP/Z+XytDcBijmFmlwy6NNzePrNG2O2MxP3O95joVcPCfXB1
/inqeowryF0fhB9uv0F9
=MUyp
-----END PGP SIGNATURE-----
--ncSAzJYg3Aa9+CRW--
