They thought about these things and put features into the protocol to support them. This is, once again, the opposite of your belief that they didn't.

Android does now support IA_PD, so the people who need to track IP use via DHCPv6 requests should now be happy. (We'll just put aside the question of whether doing that even makes sense in a world where devices can be told to use any IP.)

What more do you want from it?

What could they have possibly done differently to make you happy with it?

> people who either worked for the likes of Google who were aching for a globally unique identifier per device

v6 doesn't give you globally unique device identifiers. Devices get IPs from the network in v6, just like they do in v4. You're either thinking of MAC addresses or perhaps things like HIP (https://datatracker.ietf.org/doc/html/rfc7401). I guess there is Mobile IPv6 which allows you to take your address to another network, but then there's also privacy extensions which prevent your machine from using the same IP for very long, so it's still not a unique identifier for your device.

How else would you do it? Forcing every packet to reserve space for every possible option (including all future ones) seems obviously worse.

   With one exception, extension headers are not examined or processed
   by any node along a packet's delivery path, until the packet reaches
   the node (or each of the set of nodes, in the case of multicast)
   identified in the Destination Address field of the IPv6 header.

None of it does anything particularly amazing, but that's kind of the point -- the programs that people are generating are for the use cases that are too personal, trivial or specific for anyone to have bothered making a software package for.

There are a number of big ISPs in Europe that that have a "new" native v6+CGNATed v4 platform, and an "old" native v4+no v6 one. That's where a lot of the "I had to ask the ISP to disable v6 to get inbound connections" comes from -- the actual relevant part was getting out from behind CGNAT, and the loss of v6 was just a side-effect caused by the ISP moving you to their old platform.

Inbound v6 should generally work on those ISPs. If it didn't... I'd be tempted (perhaps unfairly) to blame the user for not configuring things properly, or their software for not supporting v6. A lot of people will give up and blame a problem on v6 when they would have found and fixed it instead on v4.

I was thinking more along the lines of network namespaces -- although actually, I should have been thinking of TUN interfaces. Any packets sent into one of those are delivered to the attached program, which can do what it likes with them. Those are usually used by e.g. OpenVPN for L3 things, but nothing stops a program from handling the L4 headers.

Note that RFC 7278 doesn't prescribe ND proxy use for the mobile network case. Mobile networks provide the /64 over a point-to-point interface, so they can simply put the /64 and their own address on the LAN interface and it'll work fine, as described in the examples at the end of the RFC.

I don't think it's a good idea to put more of the stack than necessary into each individual program though, because then you're reliant on each program implementing everything correctly and you have to worry about bugs and security issues in every single program you're running rather than just in the kernel.

Considering that even something as simple as opening a socket (which involves calling one function to give you three numbers which you pass unchanged to a second function) is largely a clusterfuck in existing programs, I don't trust them to implement the whole TCP stack.

...it does. You can spend five seconds in tcpdump to see that it does:

    $ ping6 fe80::506c:e9ff:fe08:9ba3%eth0

    11:58:48.741688 d6:57:10:b8:52:77 > 33:33:ff:08:9b:a3, ethertype IPv6 (0x86dd), length 86: fe80::d457:10ff:feb8:5277 > ff02::1:ff08:9ba3: ICMP6, neighbor solicitation, who has fe80::506c:e9ff:fe08:9ba3, length 32
    11:58:48.742459 00:23:6e:5b:b8:2b > d6:57:10:b8:52:77, ethertype IPv6 (0x86dd), length 86: fe80::506c:e9ff:fe08:9ba3 > fe80::d457:10ff:feb8:5277: ICMP6, neighbor advertisement, tgt is fe80::506c:e9ff:fe08:9ba3, length 32

Yes, those bytes can be picked by looking at a MAC address, but that's only one way to pick them and the protocol doesn't treat those bytes as having any particular significance, and in particular it never assumes they contain a MAC or tries to use them as an actual MAC, so it doesn't qualify as a layering violation.

I know you're talking about SLAAC, but SLAAC is just a convenient way of picking a unique address. Changing the address wouldn't result in e.g. the packet being sent to a different MAC. Even sending packets to link-local addresses still does NDP, rather than parse the MAC out of the address.

How do you want to go about doing this? Although, 100% of the time people have asked me to do this they chicken out at actually doing it, so I suppose you will too. You might prefer to test with some network namespaces instead.

You don't need to take that on faith either -- you can just test it.

It doesn't actually do that.

  We believe that it is not possible to have a "flag-day" form of
  transition in which all hosts and routers must change over at
  once. The size, complexity, and distributed administration of the
  Internet make such a cutover impossible.

  IPng is a new version of IP which is designed to be an evolutionary step
  from IPv4.  It is a natural increment to IPv4.  It can be installed as a
  normal software upgrade in internet devices and is interoperable with
  the current IPv4.  Its deployment strategy was designed to not have any
  "flag" days.

> The “you don’t have to use NAT anymore” is great theoretically, but it renders a lot of casual network maintainers mental model of network security obsolete without a clear and simple alternative

If your mental model of security relies on NAT then your mental model was wrong, and obsoleting it was the right thing to do.

If v6 made you realize this, then it seems it's more intuitive than v4+NAT was for you.

You haven't fixed any of the problems involved in deploying v6, and you added a step that was known 35 years ago to be impossible on the Internet. This isn't a useful contribution, it's just a waste of time that you could have spent on doing v6.

Also... service discovery. Needing static addresses is a kludge.