This can be fixed not only with privacy addresses but also with DHCPv6 instead of SLAAC. The use of the MAC in this way was a bad bit of design but it's easily remedied. There is nothing in IPv6 that mandates that addresses be assigned this way. Like IPv4 they can be anything.

I personally like stuff like :feed:cafe:babe:beef or :dead:d00d :).

I agree they can be fixed, although I disagree that DHCPv6 is the solution given Android doesn't support DHCPv6. In practice most vendors I know of just use privacy addresses by default now for IPv6, at least outside servers, so it's mostly a non-issue but the fact remains it's something not applicable to IPv4. And for quite a while it was an issue, it's just that IPv6 hasn't been popular enough for consumers to care instead of just security people.

> There is nothing in IPv6 that mandates that addresses be assigned this way. Like IPv4 they can be anything.

Yes but that's nitpicking at the core RFCs vs the many other supporting RFCs. There's no IPv4 RFC for using a MAC in the IP address, whereas there is with IPv6 (rfc2373 from a quick look, maybe others).

Sure, you can fix it, but you have to fix it; with v4 it just wasn't a problem.

It's not really a problem in v6 either. Most OSs ship with privacy extensions enabled.

Is exposing a MAC a considerable issue? Also I feel like you can randomize your MAC easily enough.

It allows for tracking users since the second half of your address is always constant. It's a fixed problem though since basically all consumer devices these days use privacy extension addresses, which don't expose your MAC address and periodically change to a new random IP address

Then operating systems shall start shipping with that option enabled by default.

They already do, both the mac and windows computers on my desk have it enabled.

Yes, and it's additional overhead for the people designing the operating system to worry about. More complexity, more attack surface.