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.
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…
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.
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.
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.
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 router still needs a non-link-local address in order to be able to send ICMP errors off-link -- which you're going to want if you want sensible output from traceroute..
In other words, given a need for IPv4, it enables switching to mostly IPv6... seems like transition technology and reality might finally meet because both moved towards the other.
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
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):
> They still do things the old way but Backbone can run IPv6 only at its core.
This would turn an internal IPv4 into an externally routed IPv6, which is a neat trick which would replace all the NAT madness that we do run today.
I'd like nothing more than the ability to run ipv4 internally indefinitely, especially with things like mesh networks where the ACLs are carried over from ages ago (2018 doesn't feel that long ago, but it is).
Most of the time I don't even need a route to a direct connection, I just need legible flow logs out of a kubernetes platform.
You still need at least one IPv4 address somewhere if you want to send ICMP back, yes. (Typically a loopback, i.e., something not connected to a specific interface. Routers use loopback interfaces for rather different purposes than a Linux workstation.) But you don't need to set up an IPv4 address on every interface, so you don't need a linknet plan.
You can also forego the IPv4 addresses entirely, but then traceroute (and presumably also stuff like Path MTU Discovery; have consistent MTUs!) won't work. traceroute is often broken for entirely different reasons, though.
(Short version: IPv6-only networks can provide a gateway for IPv4-only clients and advertise it via reverse DNS.)
SixGate has an interesting contrast with this RFC. RFC8950 removes IPv4 from the network core while preserving IPv4 reachability, whereas SixGate removes IPv4 from the service side while preserving reachability for IPv4-only clients.
In both cases, IPv4 survives as a compatibility layer rather than a fundamental requirement. The difference is that RFC8950 is aimed at network operators, while SixGate is aimed at the last remaining IPv4-only users.
In both cases, the goal is the same. Turn IPv4 from a requirement into an optional compatibility feature.
I find the reason why I can't run IPv6 is that we have ISP failover and the IPv6 doesn't failover gracefully with two different wan providers. With IPv4, the local ip table isn't impacted by a change in WAN ip for the most part and the local network keeps on chugging perfectly.
33 comments
[ 5.9 ms ] story [ 73.3 ms ] thread[0] <https://datatracker.ietf.org/doc/html/rfc8950>
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…
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.)
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.
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...
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.
(Keep in mind that the setup described here has work for years now.)
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
This would turn an internal IPv4 into an externally routed IPv6, which is a neat trick which would replace all the NAT madness that we do run today.
I'd like nothing more than the ability to run ipv4 internally indefinitely, especially with things like mesh networks where the ACLs are carried over from ages ago (2018 doesn't feel that long ago, but it is).
Most of the time I don't even need a route to a direct connection, I just need legible flow logs out of a kubernetes platform.
… proceeds to traceroute with IPv4 addresses showing up for each router…
It’s neat but still requires IPv4 to be configured on the router? What am I missing?
You can also forego the IPv4 addresses entirely, but then traceroute (and presumably also stuff like Path MTU Discovery; have consistent MTUs!) won't work. traceroute is often broken for entirely different reasons, though.
(Short version: IPv6-only networks can provide a gateway for IPv4-only clients and advertise it via reverse DNS.)
SixGate has an interesting contrast with this RFC. RFC8950 removes IPv4 from the network core while preserving IPv4 reachability, whereas SixGate removes IPv4 from the service side while preserving reachability for IPv4-only clients.
In both cases, IPv4 survives as a compatibility layer rather than a fundamental requirement. The difference is that RFC8950 is aimed at network operators, while SixGate is aimed at the last remaining IPv4-only users.
In both cases, the goal is the same. Turn IPv4 from a requirement into an optional compatibility feature.
Which can also be true for IPv6. If you need stable LAN addressing you can add ULA prefix to your network. Some CPEs do this by default.