Slashdot Mirror
IT Pros Blast Google Over Android's Refusal To Play Nice With IPv6
alphadogg writes: The widespread popularity of Android devices and the general move to IPv6 has put some businesses in a tough position, thanks to Android's lack of support for a central component in the newer standard. DHCPv6 is an outgrowth of the DHCP protocol used in the older IPv4 standard – it's an acronym for 'dynamic host configuration protocol,' and is a key building block of network management. Nevertheless, Google's wildly popular Android devices – which accounted for 78% of all smartphones shipped worldwide in the first quarter of this year – don't support DHCPv6 for address assignment.
Google's IPv6 support for mail is what annoys me. I have a static non-tunneled IPv6 address for my server, have reverse DNS set up for it that resolves properly, have SPF and DKIM records set up properly, and they still refuse to accept mail from the server, even though they accept my IPv4 mail just fine. Lots of other folks have been having the same problem, and it really makes me wonder why Google's even bothering with IPv6 SMTP when they're refusing mail from so many legitimate (i.e. non-spam) hosts.
I use router advertisement on my home network. All the other devices, except Android-powered devices play nicely with router advertisements. The Android devices lose the IPv6 address when they go to sleep, and do not re-obtain the IPv6 address when they wake up. The Android devices are the only devices with this problem on my home network.
Obviously at this point it isn't a bug, its a "feature." The only question is why did Google decide to push this negative feature?
I remember first hearing about IPv6 around 1997.
Here we are almost 20 years later still sucking on the IPv4 teat. I'd say Google might as well take their fucking time on this "feature".
It's not like anyone is in a damn hurry, regardless of what's running dry.
Kind of true. Router autodiscovery works, but has some problems. It doesn't provide DNS information to the clients, nor does it allow the clients to populate their hostnames in the local DNS the way a DHCP server does. This makes it far from ideal when you want to allow for client to client communications. It also lacks any sort of authentication mechanism which makes it vulnerable to spoofing attacks. Router autodiscovery is a really incomplete solution.
I read the internet for the articles.
Anybody who moves between networks, like a cell phone? You still do route aggregation in IPv6, so even if your host ID (lower 64 bits of the address) don't change, the network ID (upper 64 bits) will when you move between networks. Otherwise you would need to propagate every single device in the world into the global routing table, and that doesn't scale.
I read the internet for the articles.
Kind of true. Router autodiscovery works, but has some problems. It doesn't provide DNS information to the clients, nor does it allow the clients to populate their hostnames in the local DNS the way a DHCP server does.
Actually, that's what the RDNSS and DNSSL options are for. (RFC 6106)
Whether devices honor them is another issue.
For some odd reason I was thinking IPv6 didn't require DHCP. Maybe that's why Google isn't in a hurry to implement it at an extra. But don't let that stop you from having a cussing fit.
That's excellent news for those 15 users.
Get free satoshi (Bitcoin) and Dogecoins
> it's an acronym for 'dynamic host configuration protocol,' and is a key building block of network management.
The above explanation is a clear proof that Slashdot is not a "news for nerds" site anymore.
-Yenya
--
While Linux is larger than Emacs, at least Linux has the excuse that it has to be. --Linus
https://www.arin.net/resources... perhaps?
It did happen, even if you didn't notice much impact.
I can throw myself at the ground, and miss.
It doesn't; it's capable of picking out an address that doesn't conflict with anything else on the same segment. But then you don't know which address is Bob's phone and which is Fred's, so you can't tell who to fire for downloading cat videos.
DHCPv6 is a bad bolt-on, IPV6 always had superior solutions designed since the 90s (when it had another name)
This makes no sense. Routers do not care how addresses are assigned, they use neighbour discovery to find the hosts.
Finally! A year of moderation! Ready for 2019?
IPv6 supports stateless IPv6 address assignment using SLAAC (StateLess Address AutoConfiguration). There is no need for a DHCP server. There are a number of reasons why using DHCPv6 to allocate individual addresses is a bad idea. If you've ever operated a DHCP server, you know about DHCP's failure modes, so I don't have to tell you. However, people get comfortable operating DHCP servers, and there's job security in it, so there are a lot of IPv4 old-timers who simply can't imagine a world without DHCP.
Speaking as one of the authors of RFC 3315, I think that Google is, if not right, at least not wrong. I would not personally want to have to set up a DHCPv6 server just to allocate individual IPv6 addresses. Talk about driving a nail with a sledgehammer. DHCPv6 is a great solution for the problem of configuring CPE routers with IPv6 prefixes. Addresses? Not so much.
Not true. ICMPv6 router advertise messages can include DNS server addresses, and this works well. Populating hostnames in the local DNS using DHCP really hasn't caught on, even in IPv4. It's a neat hack, but hardly anybody uses it. DHCPv6 also lacks an authentication mechanism, although that's about to change, but in fact ICMPv6 has RA guard and SeND (Secure Neighbor Discovery). So you are exactly backwards on the authentication question.
At this point unless you are running an ancient version of your favorite operating system, RDNSS works fine. DNSSL is a Very Bad Idea, so you don't want your host to support that, but it probably does.
Anyone who wants privacy?
Router Advertisement can handle subnets, FWIW...
Need to type accents and special characters in Windows? Use FrKeys
There may be not requirement for DHCPv6 in IPv6, but that's not to say that DHCPv6 does not have merits to it. And DHCPv6 still requires router advertisement.
SLAAC is good for dynamic address configuration and DHCP is good for the other hundred-ish host configuration variables, right?
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
It does support dynamic address assignment through router announcements, just like the IETF intended. DHCPv6 is a bolt-on for people who don't really understand v6 at all. The claims about identifying the source of traffic are just silly. Autoconfigured addresses are persistent and do identify a specific device, at least to the degree that DHCP can.
That isn't to say that Google shouldn't add support for DHCPv6 since people seem to really wanty it, but it's not like they force you to enter a static IP or something.
Sure you do. You just need to know Bob and Fred's MAC address. Same as for DHCP.
Remember we are talking about Android devices. Most of these are phones and tablets.
When was the last time you used DHCP to set the WINS server on an Android device.
Besides, most of that configuration 'fun' should be moved to DNS (which is configured by SLAAC).
IMHO IPv6 will push people to rely more on DNS as its hard to remember v6 addresses.
On that note, in the SLAAC Router Advertisement messages, there is a facility for 'other configurations'. This at a minimum will contian DNS configs and reads like it should be able add custom configuration paramaters
Spoken like someone who's never managed a deployment that's bigger that can fit in one's basement - Something a lot of the v6 creators I think have in common.
DHCP v6 exists not to coddle or comfort admins used to a v4 world. DHCP v6 was added because v6 will /Never/ be adopted without it. Ever. Full stop.
DHCP facilitates two-way communication prior to address assignment and lends flexibility to deployments that are now considered indispensable. It lets clients tell the network about themselves so they can be assigned the corrects settings (And not just an address!)
It's shit like this that keeps v6 from being adopted. (We should have been there a decade ago) Proselytizing form old, out of touch "experts" (With four digit slashdot IDs no less) with a vision for how networks work that didn't work, and is no longer relevant either.
Where to start?
1) IPv4 vs IPv6 has nothing to do with ASN. If you do have an ASN you will be using the same ASN for both protocols. With 32 bit ASN now in wide use, there is nothing limiting you from applying for one. Get your own /48 prefix with it.
2) IPv6 has NAT.
3) Multihoming is perfectly possible using IPv6. There is no rule telling you not to do it exactly like you always did with IPv4.
4) There is no rule that say you can not split a /64. You can split it down to /128 if you want. The only thing that breaks is SLAAC but you can still use DHCPv6 or static/manual configuration.
5) All major ISPs are giving out /56 or more address space, so you have no need to split a /64.
6) All major operating systems use privacy extension enabled by default, so you MAC will not be exposed when you surf the net. Your device will be no more tracked than with IPv4-NAT since it changes address all the time.
All IPv6 gives you are options. There are now more ways to do the above things. But in no way did you lose the ability to keep doing things like yesterday.
I work for a (smallish) ISP so let me tell you why you will simply not get any IPv6 service without DHCPv6 on our network.
It has nothing at all to do with being IPv4 old-timers. That is just you not understanding the complexity of the world out there. Our network was build from the start with the idea that IPv6 is the future.
We use DHCPv6 to provide every user with his own /48 prefix. Yes you said that DHCPv6 is a great solution for prefixes. But we also use it to deliver a /128 to go with that prefix. We need this to have a stable and predictable address that we can use as next hob for your shiny new prefix.
We had this very same debate on the NANOG mailing list. Some people there asked why does your routers not sniff the DHCPv6 packet and add the route dynamically? Two reasons. One, that is not in any standard, so our vendor did not implement it. Two, it does not work if you have router redundancy (how would the backup router know the route?).
There are more reasons an ISP would not want to use SLAAC. It exposes 2**64 addresses to the ISP network access routers. This can harm the network in many different ways and you simply do not want your ND caches to be full of that crap. You want to use as few slots in the shared ND cache per user. Therefore you are going to disable SLAAC on the customer edge and use some other mechanism. One guy suggested not using GUA on the customer links and only use link local addressing here. We choose to use /128 DHCPv6 assigned addresses. In either case, GUA-SLAAC is a fail in the provider network.
SLAAC is great inside the household of our customers. But we leave that decision to the customer and his choice of CPE-router.
The problem with Android is that it should really be able to act like a CPE for tethering purposes. Therefore is should be able to accept our CPE configuration. Android should also be able to ask for a prefix to be sub-delegated from the house CPE and it should accept that this might come with extra addresses that will be used for routing or for other purposes.
Or stateless DHCPv6. Or in other words: they don't support DHCPv6 AT ALL.
... except in a managed network (where something needs to keep track of what is what, and when.) Or in an IPv6 ONLY network. As I've bitched for years, a machine needs more than just an address to operate. At minimum, it needs a list of recursive DNS servers -- something that has now been bolted onto the still-a-bad-idea RA, if supported by your hardware (which is unlikely.)
You miss the entire point: on a managed IPv6 ONLY network, android devices have ZERO connectivity. As much as *you* don't want to setup such a network, there are PLENTY of others that HAVE. And the standard dictates that it be supported. Plus, it doesn't have to be a one-device-one-address-only system. If you need more than one address, ask for more than one. If you want to tether a network behind you, ask for an additional prefix, or bridge them into the same network and let them RA/DHCP for themselves. If you cannot get the additional space, you cannot support whatever feature required it. That's a very different experience than "no fucking connection?!? WTF!!!" (which is exactly where this is headed, and the network operator answer (per NANOG) is that your device is crap, you should complain to the idiots at Google -- one in particular, actually.)
The O flag (it's a single bit) simply tells the device it should search for OTHER informational elements from (wait for it...) A DHCPv6 SERVER. That is the "stateless" mode, which android ALSO doesn't support.
I suppose you are referring to the relatively recent (and not widely supported) RDNSS fields of the RA -- which do list DNS servers.
DHCPv6 was "bolted on" 12+ years ago. It is an IETF STANDARD part of IPv6. Implementation is not "optional". Google simply refused to add it because they're butt-hurt that it *could* make certain features non-operational -- or more accurately, they don't want to do any of the work to make them possible. I can make XP and 2000 work properly within a stateful DHCPv6 only network (using a 3rd party dhcp client, because their ipv6 stacks are far too old), and other android devs HAVE added DHCPv6 support to their builds -- so we know, for a fact, it can be done, and rather trivially to boot.
IPv6 supports stateless IPv6 address assignment using SLAAC (StateLess Address AutoConfiguration). There is no need for a DHCP server. There are a number of reasons why using DHCPv6 to allocate individual addresses is a bad idea. If you've ever operated a DHCP server, you know about DHCP's failure modes, so I don't have to tell you. However, people get comfortable operating DHCP servers, and there's job security in it, so there are a lot of IPv4 old-timers who simply can't imagine a world without DHCP.
Speaking as one of the authors of RFC 3315, I think that Google is, if not right, at least not wrong. I would not personally want to have to set up a DHCPv6 server just to allocate individual IPv6 addresses. Talk about driving a nail with a sledgehammer. DHCPv6 is a great solution for the problem of configuring CPE routers with IPv6 prefixes. Addresses? Not so much.
There are quite a number of wrong assumptions in the above statements.
First of all, if a /64 network has not just terminals, tablets and phones in it but servers as well, it makes sense that it should have DHCP. The servers in the network - particularly HTTP/S servers need to have static addresses. Let's say a network has 5 servers of various types - say 2 web servers, 1 mail server, 1 FTP server and 1 NFS server, you don't want to assign them dynamic addresses. Nor do you want to give them an address based on EUI-64. It makes more sense to give them a few unique addresses, such as 2001:db8:beef:1:cafe:cad:[1-5]:[$Port#], and for the rest of the subnet, give something like 2001:db8:beef:1:feed::[1-ffff] for a random assignment of say 65536 addresses. And set up your firewalls accordingly.
The other point is that SLAAC, if you look closely, is only commonly used w/ Link Local addresses - the addresses that a computer automatically configures itself. Essentially, it's a Layer 3 mapping of a Layer 2 signature, and is useful for Layer 3 communications b/w 2 computers w/o a router. For phones & other devices, other SLAAC techniques may be used, except that system admins would have no control over addresses that are assigned. Such a hands-off approach may not work for everyone.
Firstly servers don't need DHCPv6 to assign them a address. They can just pick a address and register it in the DNS themselves. They really don't need a DHCP server to do it for them. HTTP/S doesn't care about the IP address that a machine has.
Secondly SLAAC is not only used with link locals.
Just because you want to do things one way doesn't make it a requirement.
Please stop with this 64+64 BULLSHIT. There is no "host part" and "network part" in IPv6. (there isn't, anymore, in IPv4 either.) IPv6 is 100% CLASSLESS. The only thing that (currently) demands the 64/64 split is SLAAC -- BTW, it started at 80/48 -- and a network is not REQUIRED to run SLAAC. (which is the heart of the entire roasting of Google here.)
You CANNOT make such an assumption about a non-local network. You MUST know the prefix-length to know what part is "network" and which is "host". You can look up the entire 128bit address to find the assigned block (a ::/48 or ::/32 most likely), but beyond there, you rather literally have to be there.
No it works just fine on mobile, but only using SLAAC and not DHCPv6. They are two different ways of getting address assignments. SLAAC is typically going to be an autogenerated IPv6 address, based on MAC address, where DHCPv6 is going to give an address from whatever rules are defined on the DHCPv6 server.
My Galaxy S6 has IPv6 addresses on both the mobile and wifi networks. The wifi side was configured using SLAAC as expected.
The lack of DHCPv6 is generally an issue for corporate networks with regards to Android phones more than anything.
But DHCPv6 also supplies INFORMATION REQUEST which designed to operate without address assignment. It supplies things like DNS.
With Windows not supporting RDNSS in RA, it requires DHCPv6 DNS via the information request to work in a pure IPv6 world.
In the same vein, Android not supporting DHCPv6 requires RDNSS in the RA to work in a pure IPv6 world.
So as it stands right now, we have to run both if we want to support both OS and that sadly means redundant data going around the network.
I cannot speak for Microsoft, but I do know that Android uses an old version of dhcpcd.
dhcpcd has supported DHCPv6 for a long time now, so they just have to upgrade it to get it to work, which means this is purely a political rather than technical problem.
What?
No, SLAAC isn't used with link-locals -- link-local addresses are assigned automatically by the host. It's used with whatever the network range on the segment is, which will usually be a global unicast range, or sometimes ULA. That's where it's supposed to be used, it's a normal way to do v6 and it works just fine.
Having waded through the mega-thread with Lorenzo (who I've met by the way and he is a top class guy), this appears to be the nub of the dispute. It's some kind of immovable object/irresistible force situation.
The Android team build what is primarily a consumer product. When they make decisions, they think in terms of what is best for ordinary consumers. They also consider the needs of software developers. Therefore they highly prise qualities like "it just works" and "my apps don't break" and "I can tether without restriction". From this perspective as far as I can tell, Lorenzo's position is 100% correct. The founding vision of IPv6 was that you should always have as many addresses as you need for whatever purpose, and we should never need bizarre technical hacks to work around a lack of addresses ever again.
The network admins on that thread are building what they perceive as a 'take it or leave it' service, often, provided to a captive audience like a university campus or enterprise. Therefore they highly value qualities like "I can satisfy the legal department" and "I can use my existing hardware that only supports feature X" and "I can block tethering to my network to implement some security policy". They care relatively little about user or developer experience, as evidence by the number of comments on the thread of the form "If we can't get our way we'll just ban all Android devices" or "The device should tell the user that 464xlat is unavailable and let apps break" or "the device should tell the user that tethering is forbidden". They care little about application reliability or complexity as long as they can tick some boxes at the end of the day and satisfy various policies. From their perspective Android is just making their jobs harder and Lorenzo is therefore being mind-numbingly unreasonable.
This situation is somewhat confused and hard to distill because there seem to be multiple different things being discussed on the same thread, e.g. DHCPv6 PD which is apparently unrelated to address allocation.
Now, frankly, having read and understood many of these comments, I find myself siding (weakly) with Lorenzo, and not just because I know him. As an Android user and an app developer, my priorities are more closely aligned with that of the Android team. I do not wish to experience apps breaking or "tethering denied" messages in future due to some lawyer buttcovering that was translated into a network setup with the absolute minimum of effort by a monopolist IT department. If that means I fall back to IPv4 for a while instead, well, so be it. If that means my phone cannot reach the small number of IPv6 only networks when connected to some random university campus, OK, I'll use my LTE connection. And then I'll complain to the IT office and tell them "just buy an iPhone" is not an acceptable answer, so they had better get on it and allow my device to grab as many devices as it wants without having to go through a DHCPv6 server. Just like my home and mobile ISPs do. And if that means they have to do more work to satisfy the next BSA audit - well, that's why they get paid the big bucks.