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