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.
> 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.
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):
* https://en.wikipedia.org/wiki/Address_Resolution_Protocol
That's basically MP-BGP! Your dream is real.
(Keep in mind that the setup described here has work for years now.)
https://www.rfc-editor.org/info/rfc8950/
I guess the point with this to facilitate usage of IPv6.
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…
It's to facilitate use of IPv4 in an IPv6-mostly network.
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.
[0] <https://datatracker.ietf.org/doc/html/rfc8950>
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
https://en.wikipedia.org/wiki/List_of_IPv6_transition_mechan...
> 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.
> 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.
> This literally exists. There's no need for it to be part of the original specification because it's a completely separate concept.
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/
Running a IPv6-only network that doesn’t interact with IPv4 networks in any way is great and it works.
The actual gap is the mess of mixing/transitioning, and it wasnt planned properly in the last 30years
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.
This isn't one of those. It's for ISPs who run a native IPv6 backbone and want to exchange and route IPv4 traffic without setting up IPv4 addressing.