A few more RFCs, a few more IP over IP bandaid, a few more extensions, and we will get there. By God IPv6 is a stain in the history of computer science.
IPv6 should have really just worked like NAT/IP over IP on IPv4 hardware and fast path on IPv6 hardware. But instead we got a monster that keeps growing with things like NAT64, 4over6, DS-Lite, MAP-E, and now BGP stopgaps and a growing
> IPv6 should have really just worked like NAT/IP over IP on IPv4 hardware
This literally exists. There's no need for it to be part of the original specification because it's a completely separate concept.
There's nothing wrong with ipv6 other than the general human desire to not change things that "work" and for people who are currently powerful because they own a bunch of ipv4 to resist changes.
The Abstract and Introduction sections of the RFC [0] explain what the point of this is. The "Changes Compared to RFC 5549" section is especially good reading, as it both alerts you to the fact that this is an update to a seventeen year old RFC and explains what changed in the update.
RFC 8950 is quietly useful for operators who want to drop IPv4 addresses from point-to-point links and run an IPv6-only fabric while still carrying IPv4 routes over BGP. How well is it supported in practice across vendors and open-source routing daemons like FRR and BIRD?
IPv6 should have really just worked like NAT/IP over IP on IPv4 hardware and fast path on IPv6 hardware. But instead we got a monster that keeps growing with things like NAT64, 4over6, DS-Lite, MAP-E, and now BGP stopgaps and a growing
https://en.wikipedia.org/wiki/List_of_IPv6_transition_mechan...
This literally exists. There's no need for it to be part of the original specification because it's a completely separate concept.
There's nothing wrong with ipv6 other than the general human desire to not change things that "work" and for people who are currently powerful because they own a bunch of ipv4 to resist changes.
[0] <https://datatracker.ietf.org/doc/html/rfc8950>