In the mainline Linux kernel, I am able to add a default route using a IPv6 address as the next hop like this.
ip route add 0.0.0.0/0 via inet6 2602:[...]
Currently, when I attempt to do the same on VyOS, I get an error.
> set protocols static route 0.0.0.0/0 next-hop 2602:[...]
Error: 2602:[...] is not a valid IPv4 address
When implemented properly, I expect this feature to be able to add such a route to my IPv4 tables to be able to send IPv4 traffic to a IPv6 router. Currently, this is possible in VyOS with BGP expended multihop, however having the support for static routes is more preferable.
Not everything supported by the Linux kernel is necessary a good thing.
This is one of those bad ideas IMHO.
What happens is that your IPv4 address is mapped to a IPv6 address and then sent out. Problem is what happens on destination side where the traffic arrives as IPv6 - for example when your IPv4 application wants to talk to a IPv4 destination and it doesnt work since some routing along the road decided to switch to IPv6 for nexthop?
Same if you think that this will only affect the nexthop that is that the sender host would convert this nexthop IPv6 and only find out the mac-address of the nexthop and send to that - that would also be a great cause for errors specially if you or the provider have setup a proper dualstack. Or if its a IPv6 only network since IPv4 packets uses a different ethertype (and around there those are being filtered).
So my €0.05 is that I think VyOS should NOT support this syntax and if it does a big WARNING should be written out during configuration, commit and boots that even if VyOS supports the syntax its not recommended.
Looking at some RFCs this is valid usage. I agree it is a bad idea most of the times but that doesn’t mean VyOS shouldn’t support it. It’s up to the network administrator to decide if it is a good use case.
For instance, I detest NAT but that doesn’t mean it shouldn’t be supported.
Some extra context on the whys of having this feature is due to our IPv6 only network. We prefer to use IPv6 as much as possible, using our router as the nexthop to get IPv4 connectivity. The main advantage of this design is that we do not need to setup a seperate IPv4 transit network to get IPv4 connectivity to our network devices.
The core router would do this. I am configuring our nexthop to the core router which is receiving full tables to IPv4 destinations. The core router is configured to route a /32 to our specific host, similar to what is being proposed here. We are broadcasting a specific CIDR so that the wider internet is able to reach our network for other sources to send to us.
This isn’t true. What you’re meaning is NAT64 and has nothing to do with nexthops or path selection.
Please inform yourself of what Next-Hops, in context of routing, are. And maybe you should also read about extended nexthop to inform yourself instead of yelling that this is bad without understanding it.
@roedie unforteunately this is true. FRR don’t directly support static IPv4 Routes with inet6 NHs. This only works via BGPs Extended Nexthop Capability at the moment.
Extended Nexthops are already used in some DCs today, mostly in IPv6-only Fabrics which also need to transport legacy IPv4 packets. I even saw people searching for help for routing IPv6 subnets via inet4 NHs - crazy - i know…
So I’m a bit confused what the IETF Draft wants to say, but it’s archived anyway… I understand this paper more like a analysis of what exactly happens and its consequences, if this technique is used. As the paper mentioned at least traceroutes may look strange to externals - which is true.
It looked like that the Linux Devs extended the kernel on behalf of the mentioned RFC above.
@nepeat purely out of curiosity, why do you want to set this kind of routes static? Why not the regular way via BGP? (static routes are evil and sometimes bite you in the a… )
@mkrsn In my case, one of our upstreams provides IPv4 over v6 nexthops like this. To get around this, we have to add ip route add commands to the /config/scripts/vyos-postconfig-bootup.script at present.
)