I don't understand why you can't have any protocol that can (potentially recursively) resolve to a layer 2 address as a next hop.
v4 route with v6 next hop? Seems reasonable.
v6 route with v4 next hop? Why not?
v4/v6 route with a mac address as a next hop? Trivial.
v4/v6 route with a DNS next hop? Could be recursively resolved to a v4/v6 address, and then potentially recursively resolved to a MAC address. I wouldn't recommend it, but sure.
v4/v6 route with a netbeui name as a next hop? You appear to be mad, but I'm not going to be the one to stand in your way.
> I don't understand why you can't have any protocol that can (potentially recursively) resolve to a layer 2 address as a next hop.
Which Layer 2? Ethernet? Token Ring? Infiniband? ATM? Fibre Channel?
Both IPv4 and IPv6 were created when there were multiple Layer 2 protocols in use. That's why where was a completely different protocol to handle Layer 2 to 3 mappings (often itself referred to as a Layer "2.5" one):
More like, the point is to facilitate turning off IPv4. It's much nicer to manage a single-stacked backbone, but you still need IPv4 out in the edges somehow (for many cases, anyway). I guess this is another way to do that.
Heck, I would be happy if I could remove some IPv4 linknets from my IS-IS, myself, and just route using IPv6 link-local nexthops…
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.
Multiple ISPs in my country have already deployed IPv6 with NAT64 support, and with CLAT support now available, I think IPv6-only networks will be the next step for most ISPs.
There is also MAP-T which basically does CGNAT with IPv6-only provider network. The local network gets IPv4, the router translates to IPv6 which goes to stateless IPv4 NAT proxy. The advantage is that the proxy is stateless unlike CGNAT. The downside is requires custom code on the router.
IPv6 mostly (RFC 8925) is a rather nice migration option.
Modern operating systems will gladly do CLAT, and old operating systems (or fussy users) can still get their IPv4 by just ignoring the new DHCPv4 option. But admins can finally stop keeping an IPv4 around for every potential client as most applications and users really don't care.
It's also just nice to not need numbered point-to-point links (ie. just use IPv6 LL).
(this is one of those things that's really magical with OSPv3 - it just runs on IPv6 LL addresses, no need to set anything up other than set the link to be within some area and it just works! well, as much as they do with OSPF anyway.)
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.
If your solution is that “if everyone just used IPv6 we wouldn’t have this problem” then it’s not a solution. Standards like USB, Wi-Fi, HDMI, DP, etc. are so successful because they are by out-of-the-box backwards compatible with their predecessors.
> There's nothing wrong with ipv6 other than [long list of human things]
The unfortunate reality is that technology exists to serve us. If humans don't want to use it, it means that your technology is wrong. End of story. It doesn't matter if you (or any of us) think it's elegant and beautifully designed.
Yeah, that is the whole point. It was never going to be a clean cut. "Works in my lab" isn't good enough for real world.
The issue isn't that it wasn't planned properly, the issue is that the real world wasn't taken into consideration by people who either worked for the likes of Google who were aching for a globally unique identifier per device or just delusional about how much we can change in real world.
> Yeah, that is the whole point. It was never going to be a clean cut.
As predicted:
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.
Rather, IPng will need to co-exist with IPv4 for some period of
time. There are a number of ways to achieve this co-existence
such as requiring hosts to support two stacks, converting between
protocols, or using backward compatible extensions to IPv4. Each
scheme has its strengths and weaknesses, which have to be weighed.
Furthermore, we note that, in all probability, there will be IPv4
hosts on the Internet effectively forever. IPng must provide
mechanisms to allow these hosts to communicate, even after IPng
has become the dominant network layer protocol in the Internet.
Creating an IPng was always going to be complicated:
So it's a matter of mathematical and physical fact that to expand
the address size, you must change the protocol, and that means
[three] things immediately:
You have to change the version number.
You have to add new code to handle the new version.
[…]
You need a coexistence technique so that updated systems,
with the new protocol, can connect to old systems that know
nothing of the new protocol.
Two minutes of thought show that this third requirement has only
two solutions:
(3A) Dual stack, in which the new machines speak both
the old (IPv4) and new (IPng) protocol.
(3B) Translation, in which something translates addresses
between the old and new protocols.
v4 route with v6 next hop? Seems reasonable. v6 route with v4 next hop? Why not? v4/v6 route with a mac address as a next hop? Trivial. v4/v6 route with a DNS next hop? Could be recursively resolved to a v4/v6 address, and then potentially recursively resolved to a MAC address. I wouldn't recommend it, but sure. v4/v6 route with a netbeui name as a next hop? You appear to be mad, but I'm not going to be the one to stand in your way.
Which Layer 2? Ethernet? Token Ring? Infiniband? ATM? Fibre Channel?
Both IPv4 and IPv6 were created when there were multiple Layer 2 protocols in use. That's why where was a completely different protocol to handle Layer 2 to 3 mappings (often itself referred to as a Layer "2.5" one):
* https://en.wikipedia.org/wiki/Address_Resolution_Protocol
(Keep in mind that the setup described here has work for years now.)
Heck, I would be happy if I could remove some IPv4 linknets from my IS-IS, myself, and just route using IPv6 link-local nexthops…
See §6, "Usage Examples": IPv4 over IPv6 Core, IPv4 VPN Unicast over IPv6 Core, IPv4 VPN Multicast over IPv6 Core.
* https://datatracker.ietf.org/doc/html/rfc8950#name-usage-exa...
So it's to facilitate legacy IPv4 usage when the rest of your infrastructure is IPv6.
[0] <https://datatracker.ietf.org/doc/html/rfc8950>
Modern operating systems will gladly do CLAT, and old operating systems (or fussy users) can still get their IPv4 by just ignoring the new DHCPv4 option. But admins can finally stop keeping an IPv4 around for every potential client as most applications and users really don't care.
(this is one of those things that's really magical with OSPv3 - it just runs on IPv6 LL addresses, no need to set anything up other than set the link to be within some area and it just works! well, as much as they do with OSPF anyway.)
Edit: After reviewing their post history it makes a bit more sense.
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.
Takes on Hacker News can truly be wild sometimes.
I certainly don't recall being able to use DP on a VGA monitor without some sort of adapter!
The unfortunate reality is that technology exists to serve us. If humans don't want to use it, it means that your technology is wrong. End of story. It doesn't matter if you (or any of us) think it's elegant and beautifully designed.
By that token, IPv6 never had to exist at all then, but we know that is completely missing the point.
IPv6 is a privacy nightmare without privacy extensions. It is designed with "a stupid desire to pretend we can boil the ocean".
Close to 3 decades and we are barely scraping 50%: https://stats.labs.apnic.net/ipv6/
The actual gap is the mess of mixing/transitioning, and it wasnt planned properly in the last 30years
The issue isn't that it wasn't planned properly, the issue is that the real world wasn't taken into consideration by people who either worked for the likes of Google who were aching for a globally unique identifier per device or just delusional about how much we can change in real world.
As predicted:
* https://datatracker.ietf.org/doc/html/rfc1726#section-5.5Creating an IPng was always going to be complicated:
* https://github.com/becarpenter/misc/blob/main/why6why.md* https://datatracker.ietf.org/doc/html/rfc1671