So does ND and DAD - those 2 too would break if you tried a prefix length of, say, 96.

But you don't have broadcasts in IPv6. The equivalent that you have is a multicast to all nodes of that subnet, so the equivalent of x.x.x.255 would be ff02::1 i.e. a multicast to all nodes in the local link multicast group. Also, in IPv6, since the client can automatically create its own link local address - fe80::[EUI-64], can't the router automatically use that to assign a subnet address once it finds that node within the network? In other words, all communication can be layer 3 only, instead of having to go through layer 2?

That's DHCPv4. In case of DHCPv6, the DHCP server proactively gives addresses to everybody it discovers in its network through router advertisements. The process is reversed here - the server gives the client addresses first, as opposed to the client asking for it first.

I was talking only about DHCPv6, not DHCPv4

Can your host files - or any other /etc files - work in conjunction w/ Sendmail to enable email recall, if a recipient hasn't yet read it? If not, why not?

Given that it works w/ Microsoft Exchange/Outlook, it's obviously not far fetched. You might have a point if you said that it's impossible on Sendmail like Todd Knarr did, although that would still miss the point about why a message that's not been read by it's intended recipient can't be recalled.

Problem is that not everybody will be comfortable w/ randomly assigned addresses, especially for devices where they'll want to use the raw IP addresses instead of DNS, just like in IPv4. B'cos there are sometimes that DNS adds just another layer of complexity and if an application doesn't work, it's sometimes easier for an implementer to just work w/ the IP addresses. In the past, it might have been something like 192.0.2.57, while now it would be something 128 bits. If the admin can manually assign it, it can be something as simple as 2001:db8:2:23::5. With RAs and NDs and DADs, it could end up like 2001:db8:3ea5:9g4e:8bac:6ecb:a79f:b1a7. Good luck w/ adaption if admins have no control over what sort of addresses get generated.

DHCP was never seen as the albatross that NAT was. Just that DHCPv6 was so different from DHCPv4 that the former was perceived as being a lot less essential in IPv6 than its counterpart in IPv4. However, the IETF always seriously defined DHCPv6 as a part of the standard, although it may have been far down the totem pole in importance. In the case of NAT, however, the IETF was dragged kicking & screaming due to the few use cases that made NAT popular, namely load balancing and multi-homing.

All IPv6 routers that I know of assume the 64/64 split - regardless of whether or not they're using SLAAC. Violate that, and you're breaking not just auto-configuration, but also things like RAs, NDs, DADs, et al

If you use an Android phone or tablet to tether another device, it would become a de-facto IPv6 router. Which is when the above scenario kicks in

But if you're using SLAAC, the address of that interface will be static. It won't change, since its assignment mechanism would be EUI-64 or whatever other static assignment mechanism is being used. Privacy extensions imply that SLAAC is no longer being used, and then the scenario that you describe would play out. Plus, wouldn't deprecated addresses be flushed out of cache pretty quickly?

Ethernet cards are the ones that have those 48-bit MAC addresses. Other network interface cards follow different standards

2 has changed. The IETF included one particular NAT mechanism called NAPT - Network Address Port Translation. This does a 1:1 mapping b/w GUA and ULA/LLAs. The advantage of this is that it provides the internal network abstraction that network admins desire, in the absence of multi-homing standards. However, one does not have to do the PAT equivalent in IPv4 and consume ports the way one did there. (So for things like mapping applications, the map can use as many ports as it likes w/o them being needed in the address translation.)

So by endorsing NAPT, the IETF came up w/ one mechanism for not just network abstraction and load balancing, but also ONE standard way for NAT lovers to implement their favorite rebel protocol in IPv6. This way, even NAT is cleaner on IPv6 than in IPv4, where you have static NAT, dynamic NAT and PAT, and what's used is usually the third.

One thing I do agree w/ you - I think the /64 assignment as the subnet size is insane, and leaves the prefix size wanting. While ARIN is generous w/ /48 assignments, both APNIC and RIPE see a potential of running out of space, and are therefore more conservative in their assignments, usually assigning /56. I happen to think that had the subnet boundary been fixed at the 96:32 mark, that would have allowed for a more rational allocation of space to the ISPs, while still allowing autoconfiguration, albeit somewhat less unique (1 in 4 billion still). The only thing ISPs would have gotten would have been /56-64s, but they'd have had the choice to allocate their customers /80 or /96, depending on how much they needed. Also, it would have been easier to organize the IPv6 internet into a globally routable hierarchy w/ really compact routing tables, and also, organizations that needed PI addresses could have gotten their own /64s which they could have then split and assigned geographically, and maybe administered/allocated directly by the IANA, as opposed to individual RIRs

Only on a mobile network. How would a WiFi use any SLAAC mechanism, since only a subset of devices would have Ethernet and thereby EUI-64? Any SLAAC mechanism that one comes up w/ has to account for all the devices that may live on that network.

DHCPv6 is nothing like DHCPv4. It was designed from the ground up differently, just like IPv6 itself was. It's the only mechanism out there that an IPv6 network admin has to control which devices get which addresses. Denying a DHCPv6 solution just forces people into a 2 sizes fit all, which is far from ideal. Also, DHCPv6 is the only thing that allows one to have, say /96 subnets (assuming that they don't give a fuck to SLAAC) or even a /128 assignment.