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.
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.
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.
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.
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.
Router Advertisement can handle subnets, FWIW...
Need to type accents and special characters in Windows? Use FrKeys
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
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.
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.