But one wouldn't always use an Android device w/ the carrier. In fact, I generally disable internet connectivity on the go, and only enable it when I'm near a recognized WiFi hotspot. For this sort of a situation, if DHCP is used in assigning addresses, the Android device wouldn't work.
Verizon is very much IPv6 - in fact, that's what I get w/ my phones. I have an iPhone 5s and a Moto-X. Both work w/ the Verizon IPv6 network.
static IP 6 address has the devices MAC address in it. Therefore tracking becomes an issue for some
Not on phones - since when do they have Ethernet cards? The phone static address would be a function of EMEI addresses or something like it.
Isn't half the point of IPv6 that we can just give EVERYTHING a static IP? Who needs dynamic assignment?
No, the point of IPv6 is that everything that needs a public IP can have it, w/o running short. The static vs dynamic argument comes up when one is discussing whether a stateful address is needed for something that has to be constant, such as a server IP address. As opposed to say your iPhone, which should change addresses every few seconds so that nobody can discover it and penetrate it, even if they manage to infiltrate the network
There have been possibilities analyzed like the million light bulbs w/ IP addresses issue, but the whole idea is that there shouldn't be any address shortages of any type holding up any technology adaptions.
It's about Android devices not being able to
However, Mobile IPv6 would work fine on Android, since it uses a variation of SLAAC that would keep the interface ID constant while switching across various mobile networks. Mellon didn't mention whether his phone works fine on an IPv6 enabled WiFi network - that's where it could have issues if DHCPv6 is the preferred mechanism of address assignment
There is only one other explanation that I get - that Google expects Android to be used only in cellular mode, rather than WiFi, and therefore, since it support Mobile IPv6, its IPv6 support is complete. But I agree w/ you that that is unsatisfactory.
DHCPv6 ought to be the first thing supported by any IPv6 implementation. SLAAC and stateless configuration should be secondary.
That's not the point. Android devices, like laptops, are clients that have to accept whatever addresses are given to them by the network they are in.
Let's say you've got IPv6 from your provider, and have configured your router to issue IPv6 addreses like 2001:db8:cafe:1:dead:beef:1:[0-ffff] to the devices on your network. You've decided that you want to use other addresses for other purposes later, but for now, you just want to assign this to all your toys. Your router proactively issues 5 addresses to your toys. Your iPad gets one, your laptop gets another and now it's time for your Android phone to take what's given to it. But it doesn't, since Google has configured Android in such a way as to reject the addresses your router is giving it.
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
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.
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.
IPv6 doesn't require DHCPv6 - if you are fine w/ either auto-configuration or transient assignment of addresses. It's only required if the network admin has an address layout plan and wishes to implement it - that's when DHCPv6 is needed.
Unlike DHCPv4, which has to be requested for IPv4 addresses, DHCPv6 proactively assigns IPv6 addresses to the various nodes, depending on the assignment rules. If one wishes, one could configure DHCPv6 to assign only Unique local and not Global Unicast addresses. I'm not sure whether DHCPv6 can be used to configure Link Local Addresses - speaking of which, those are the ONLY ones that use EUI-64.
TFA, what does Android have outside Linux that refuses to implement DHCPv6?
To this day, there is no better feature of emails i.e. Microsoft Exchange here - than Message Recall. The ability to recall a message that's not yet been read or opened by the recipient - maybe due to the wrong recipient, or something you wished to edit. That's a lot more useful than the limited 30 second margin to undo a send.
Why couldn't Sendmail - bloated as it is - be tweaked to support such a feature?
Computers will not be perfected until they can compute how much more than the estimate the job will cost.