It's time for more from our series of articles on measurement.network. This time we turn to V4LESS-AS and doing IPv4 with an IPv6 nexthop.
There is a new (well, comparatively new... this started with RFC5549 15 years ago, but RFC8950 is from 2020, so...) thing in town: doing IPv4 with an IPv6 nexthop.
With this, not only can you exchange routing information for IPv4 prefixes via an IPv6 BGP session, but you can also put in an IPv6 address as the nexthop for an IPv4 prefix. Sounds funny, but it's actually really useful.
IPv4 with IPv6 nexthop under the hood
The core of the idea can be best understood by focussing on what 'nexthop' in a route actually means. It kind of means 'figure out the next host responsible for packets to this destination'.
In our ethernet-y world, this usually boils down to finding the MAC address of that nexthop (or the MAC address of the nexthop responsible for that nexthop).
In the IPv4 world, that is done with the Address Resolution Protocol (ARP). In the IPv6 world, there's no ARP, but there is the Neighbour Discovery Protocol (NDP) for finding the Link Local address of the responsible neighbour on a link.
Still, Link Local addresses are not put into Ethernet headers. Instead, our hosts translate them to the actual MAC to throw in there. The bottom line is that nothing stops us from using NDP to find the MAC of the host to which we have to forward an IPv4 packet, at least if it has an IPv6 nexthop, and whatever device we are using supports this.
Fun things to do
Doing IPv4 with an IPv6 nexthop is kind of fancy because we need no translation, no state, no rules, no NAT. Just routing. This means that we can build a network like the following:
In that network, we have:
- NO IPv4 on the Gateway for the host that gets a /32
- NO IPv4 on any transfer links (Tired of wasting /31s?)
- NO IPv4 on any router
- NO IPv4 on eBGP(!)
Additionally, we can centrally manage our IPv4 IPAM and make an IPv4 address appear where we need it simply by injecting a route with the IPv6 GUA of the host requesting it as the nexthop.
Endless possibilities
Imagine a world where there is no shortage of IX prefixes where a /64 can last forever and a /48 even longer. Imagine an IPv4 free core. Imagine a clean IPv6 addressing scheme, in which your customers get a public IPv4 address upon request (well, mostly for hosting - access is a whole different beast). That world can be a reality!
Dreams and magic
However, as with all other forms of dreams and magic, reality is a bit more complex. For some reason, operators tend to be 'a bit cautious' when it comes to completely upending their network architecture.
Something something 'do not test in production'. And of course the well known 'But have you heard about THIS corner case?!'. And I mean, yes, the Internet is a collection of corner cases, but somehow, for some funny reason, it still works.
So, let's hunt down the bugs and corner cases. This is what V4LESS-AS does.
V4LESS-AS
V4LESS-AS (AS215250) is a development ground for running an AS fully on IPv4-with-IPv6 nexthop. For this purpose, V4LESS-AS is present at IXPs, where passive sessions for all neighbours at the IX are pre-configured.
To start peering, just setup a session on your side, and it will just come up! Furthermore, V4LESS-AS hosts RIPE Atlas probes and NLNOG Ring Nodes to allow operators to introspect such a network.
At the moment, V4LESS-AS is present at 13 'real' IXPs and 17 often more considered to be related to breakfast-operations. (And a big thank you to all sponsors for providing IX access :-))
There are more details on V4LESS-AS from the usual suspects:
Test cases
Of course, running a test-bed means having test cases. For V4LESS-AS, the following test-cases are configured and available:
Prefix hijack – RPKI invalid / IRR invalid
When configuring RFC8950 sessions, filters may not apply correctly due to v4 prefixes being learned over a v6 session. To test for that, V4LESS-AS announces 193.31.54.0/24, which has a ROA for being originated by AS211286 (MSMT-NTWRK), as well a corresponding route object. You should not ingest this prefix.
All IPv4 addresses in this prefix respond to ICMP. If you can ping any IP in that network, you need to check your filters.
Forged origin prefix hijack – origin RPKI valid / IRR valid
And once again. When configuring RFC8950 sessions, filters may not apply correctly due to v4 prefixes being learned over a v6 session. To test for that, V4LESS-AS advertises 193.31.55.0/24, pretending it was learned from AS211286. The prefix has a ROA for being originated by AS211286 (MSMT-NTWRK), as well a corresponding route object. As this is a forged origin hijack (AS211286 is not in AS215250’s AS-SET) you should not ingest this prefix.
All IPv4 addresses in this prefix respond to ICMP. If you can ping any IP in that network, you need to check your filters. (Yes yes, I know, technically AS-Set foo; use ASPA. ;-P)
MTU1500 path, no IPv4 source address for ICMP on-path
In this setup, a node receives an IPv4 address via IPv4-with-IPv6 nexthop, and the path to all upstreams/peers has an MTU of 1500. All on-path routers do not have an IPv4 address, and originate ICMP packets from 192.0.0.8.
MTU1400 path, no IPv4 source address for ICMP on-path
In this setup, a node receives an IPv4 address via IPv4-with-IPv6 nexthop, and the path to all upstreams/peers has an MTU of 1400. All on-path routers do not have an IPv4 address, and originate ICMP packets from 192.0.0.8.
MTU1500 path, IPv4 unicast source address for ICMP on-path
In this setup, a node receives an IPv4 address via IPv4-with-IPv6 nexthop, and the path to all upstreams/peers has an MTU of 1500. The last two hops use an dedicated unicast IPv4 address to originate ICMP packets.
MTU1400 path, IPv4 unicast source address for ICMP on-path
In this setup, a node receives an IPv4 address via IPv4-with-IPv6 nexthop, and the path to all upstreams/peers has an MTU of 1400. The last two hops (around the MTU break) use an dedicated unicast IPv4 address to originate ICMP packets.
Leaking RAs Into Peering LANs
In networking culture, it is considered 'not so cool' to leak router advertisements into peering LANs. After provisioning a port on AMS-IX, though, I got a somewhat concerned mail from the NOC asking me whether I might be willing to consider to stop leaking RAs into their peering LAN.
I was a bit surprised, and checked the configuration of my router. I indeed found the following entries in the router-advert { section:
service {
router-advert {
}
}So, a bit confused, I set out to ask tcpdump. Lo and behold, there it was:
2025-08-07 10:00:04.769311 9c:dc:71:42:ec:d1 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 110: fe80::9edc:71ff:fe42:ecd1 > ff02::1: ICMP6, router advertisement, length 56
2025-08-07 10:00:14.770669 9c:dc:71:42:ec:d1 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 110: fe80::9edc:71ff:fe42:ecd1 > ff02::1: ICMP6, router advertisement, length 56
2025-08-07 10:00:24.783380 9c:dc:71:42:ec:d1 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 110: fe80::9edc:71ff:fe42:ecd1 > ff02::1: ICMP6, router advertisement, length 56Nothing seemed to help; Even running through all sysctls I found to be even remotely attached to RAs, and setting up iptables rules, the packets seemed to still be 'there'.
At least AMS-IX seemed to no longer see them after the iptables rules were put in place. Shortly after, I got tipped of by someone in the community, that there is an open FRR PR. Essentially, FRR decided that configuring 'extended nexthop' as a capability MUST be a clear sign of doing unnumbered BGP (even though if you're not).
As such, it happily opened a raw socket and started sending RAs (or rather: instructed Zebra to do so). It turns out this was not really a priority, seemingly because the number of people running 'extended nexthop' on IXP connected FRRs seems to be somewhat... low.
Long story short: This is why V4LESS-AS exists: To run into such things before someone puts it into 'real' production. ;-)
Sponsoring an IXP connection and conclusion
So, in summary: V4LESS(-AS) is there! Try it out and free up all those addresses currently 'wasted' on transfer and loopbacks. If you want to bring AS215250 to an IXP near you (and we are happy to come :-)), the following would be needed:
- Virtual or physical machine where we/you can install a custom VyOS build
- 1 Core
- 4GB Memory
- Backhaul VLAN or interface with a publicly routed IPv6 address
- Port to the IX
Comments 0