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.

But the lifetime of the addresses, or them being demoted to 'deprecated' and all that - all that is done only if there is a DHCP server, no? If it was using SLAAC, it would be static. And even for transient addresses, it would need some sort of DHCP service to keep the prefix fixed, while toggling the Interface ID

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.

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.

Also, how would using SLAAC expose 2^64 addresses? I can understand how it could expose the MAC address if EUI-64 is used, but how would it risk exposing that many addresses? You won't have anything even close to that many devices on that network at any time.

It's about Android devices not being able to

• - accept an IPv6 address from a router where DHCPv6 is the chosen mechanism for distributing addresses
• - act as CPEs and be tethered if needed if given a DHCPv6 assigned address

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.

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.

SLAAC is only used w/ Link Local Addresses. I've not heard about it being used w/ Unique Local or Global Unicast addresses. Anybody who does it that way is asking to be screwed.

My router - a netgear - supports DHCPv6, if I enable IPv6. If I use that in conjunction w/ Comcast's modem and get a /64 from Comcast, how is my router prevented upstream by Comcast from using DHCPv6? (I have Charter, not Comcast, and they don't support IPv6 so far, although they do have published plans to do it, but my router is ready for it whenever they choose to flip the switch).

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?

It's been at least 10 years since Chinese factories are just as competent w/ BGAs as they are w/ PDIPs

I use not Linux, but PC-BSD, and while I'm happy w/ it, there are some things which I can't do, which is why I got the $100 Winbook on the side for those missing apps. Aside from being able to open and edit Office documents (I use Calligra rather than Libre Office), there are times I need to do things like GoToMeeting or other apps that just don't work outside Windows or Android/OS-X. Also, there are some web sites that recognize your environment and throw up their arms in despair if you try to run them.

However, PC-BSD works great, since most of the sites I visit are viewable under either Chromium or FireFox, and the only major game I play is FreeCiv. On the Winbook, I did get Steam and Civ4. It would be nice if there were a Steam VM under PC-BSD where I could play Civ 4 as well.