Pangram verdict · v3.3
We believe that this entire text is human-written.
AI likelihood · overall
HumanArticle text · 1,059 words · 1 segments analyzed
For the last few days I have been playing with RFC8950 setup, which allows routing of IPv4 on top of IPv6. While logically it’s quite simple, it has a very powerful application towards making “IPv4 an optional” feature riding on top of an IPv6 network (but without any tunnels!)Some of the interesting use cases:A large network can run IPv6 only everywhere on its core and leave IPv4 only on edge devices. This can work without customers doing any tweaking at their end. They still do things the old way but Backbone can run IPv6 only at its core.An IP transit backbone can run IPv6 only while exchanging IPv4 routes with its customers/peers/upstream over IPv6 sessions. So IPv4 as a “feature” stays but the network in itself is IPv6 only without the overhead of IPv4 interface config, BGP session config, firewall config, etc.An IXP can offer services without IPv4 essentually by using a (unique) IPv6 at the IX LAN & running route server to exchange both IPv4 & IPv6 routes over the IPv6 only session.Thus what 464XLAT did to the mobile networks - this has the potential to do that for the backbone networks.How does it work?Multi-protocol BGP (MP-BGP) supports announcement of IPv4 routes over IPv6 sessions with IPv4 next-hops and IPv6 routes over IPv4 sessions with IPv6 next-hops. RFC8950 extends this feature for IPv4 to have IPv6 next-hops. So for IPv4 address, next hop is IPv6, IPv6 reach works via usual NDP and IPv4 rides on ethernet frames to the same MAC as discovered by the NDP. Technically RFC8950 only impacts control plane decisions by using IPv6 as the control plane but keeps the data plane as it is. IPv4 stays IPv4 & goes as IPv4 over the wire unlike say some tunnel or 464xLAT etc.Hardware supportAs of now it’s quite widely supported by a lot of routing platforms like Juniper JunOS, Cisco IOS XR, Nokia SR OS, Mikrotik, Huawei, BIRD, FRR etc. So, it is very likely supported if you are running a recent version of the OS.Demo labHere’s a fun lab with two customer routers: C1 & C2 connected via provider routers R1-R2-R3 in Container Lab. All routers here are running open source FRR.C1 is IPv6 only on the WAN side facing R1. It originates 10.0.0.0/24 to R1 over an IPv6 session.R1 & R2 are IPv6 only with no IPv4 anywhere on their interfaces (but carry IPv4 routes in their table)R3 has IPv6 with R2 but just IPv4 only with C2. So C2 is like a typical enterprise user who lacks IPv6 deployment and still wants IPv4 only to work.R3 has 100.64.0.0/24 and originates it in the IPv4 table (to IPv6 adjacency - R2)C2 sits on 100.64.0.2/30 given by R3 and communicate in IPv4 only.C1 and C2 can reach each other over this network with parts being IPv6 only without any tunnel.topology.ymlname: rfc8950 topology: nodes: R1: kind: linux image: frr-with-bgpd binds: - configs/R1.conf:/etc/frr/frr.conf R2: kind: linux image: frr-with-bgpd binds: - configs/R2.conf:/etc/frr/frr.conf R3: kind: linux image: frr-with-bgpd binds: - configs/R3.conf:/etc/frr/frr.conf C1: kind: linux image: frr-with-bgpd binds: - configs/C1.conf:/etc/frr/frr.conf C2: kind: linux image: frr-with-bgpd binds: - configs/C2.conf:/etc/frr/frr.conf links: - endpoints: ["C1:eth1", "R1:eth1"] - endpoints: ["R1:eth2", "R2:eth1"] - endpoints: ["R2:eth2", "R3:eth1"] - endpoints: ["R3:eth2", "C2:eth1"] > clab deploy -t topology.yml 16:37:08 INFO Containerlab started version=0.76.1 16:37:08 INFO Parsing & checking topology file=topology.yml 16:37:09 INFO Creating lab directory path=~/ipv4-over-ipv6/clab-rfc8950 16:37:09 INFO Creating container name=C2 16:37:09 INFO Creating container name=C1 16:37:09 INFO Creating container name=R1 16:37:09 INFO Creating container name=R2 16:37:09 INFO Creating container name=R3 16:37:09 INFO Created link: R3:eth2 ▪┄┄▪ C2:eth1 16:37:09 INFO Created link: C1:eth1 ▪┄┄▪ R1:eth1 16:37:09 INFO Created link: R1:eth2 ▪┄┄▪ R2:eth1 16:37:09 INFO Created link: R2:eth2 ▪┄┄▪ R3:eth1 16:37:09 INFO Adding host entries path=/etc/hosts 16:37:09 INFO Adding SSH config for nodes path=/etc/ssh/ssh_config.d/clab-rfc8950.conf ╭─────────────────┬───────────────┬─────────┬───────────────────╮ │ Name │ Kind/Image │ State │ IPv4/6 Address │ ├─────────────────┼───────────────┼─────────┼───────────────────┤ │ clab-rfc8950-C1 │ linux │ running │ 172.20.20.6 │ │ │ frr-with-bgpd │ │ 3fff:172:20:20::6 │ ├─────────────────┼───────────────┼─────────┼───────────────────┤ │ clab-rfc8950-C2 │ linux │ running │ 172.20.20.4 │ │ │ frr-with-bgpd │ │ 3fff:172:20:20::4 │ ├─────────────────┼───────────────┼─────────┼───────────────────┤ │ clab-rfc8950-R1 │ linux │ running │ 172.20.20.2 │ │ │ frr-with-bgpd │ │ 3fff:172:20:20::2 │ ├─────────────────┼───────────────┼─────────┼───────────────────┤ │ clab-rfc8950-R2 │ linux │ running │ 172.20.20.8 │ │ │ frr-with-bgpd │ │ 3fff:172:20:20::8 │ ├─────────────────┼───────────────┼─────────┼───────────────────┤ │ clab-rfc8950-R3 │ linux │ running │ 172.20.20.5 │ │ │ frr-with-bgpd │ │ 3fff:172:20:20::5 │ ╰─────────────────┴───────────────┴─────────┴───────────────────╯ Checking C1 for route to C2C1# show ip bgp 100.64.0.2 BGP routing table entry for 100.64.0.0/24, version 2 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: 2001:db8:0:1::1 65501 65502 65503 2001:db8:0:1::1 from 2001:db8:0:1::1 (172.20.20.2) (fe80::a8c1:abff:fe60:5467) (used) Origin IGP, valid, external, best (First path received) Last update: Mon Jun 22 18:57:38 2026 C1# C1 -> C2 traceC1# traceroute 100.64.0.2 traceroute to 100.64.0.2 (100.64.0.2), 30 hops max, 46 byte packets 1 clab-rfc8950-R1.clab (172.20.20.2) 0.004 ms 0.004 ms 0.002 ms 2 clab-rfc8950-R2.clab (172.20.20.8) 0.002 ms 0.003 ms 0.003 ms 3 clab-rfc8950-R3.clab (172.20.20.5) 0.002 ms 0.003 ms 0.003 ms 4 100.64.0.2 (100.64.0.2) 0.002 ms 0.006 ms 0.003 ms C1# Note: It took IPv4 from the eth0 management interfaces as deployed by Container Lab for TTL exceeded used in the trace.If I check R1, it has only IPv6 sessions but no IPv6 prefixesR1# sh bgp ipv6 summary IPv6 Unicast Summary (VRF default): BGP router identifier 172.20.20.2, local AS number 65501 vrf-id 0 BGP table version 0 RIB entries 0, using 0 bytes of memory Peers 2, using 1434 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc 2001:db8:0:1::2 4 64512 151 141 0 0 0 00:39:19 0 0 N/A 2001:db8:0:2::2 4 65502 65 64 0 0 0 00:36:46 0 0 N/A Total number of neighbors 2 R1# Checking for IPv4 routes on R1R1# sh bgp ipv4 BGP table version is 4, local router ID is 172.20.20.2, vrf id 0 Default local pref 100, local AS 65501 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 10.0.0.0/24 fe80::a8c1:abff:fe44:afb8 0 0 64512 i *> 100.64.0.0/24 fe80::a8c1:abff:fed8:5eb5 0 65502 65503 i Displayed 2 routes and 2 total paths R1# Router ConfigsRouterLinkR1Click hereR2Click hereR3Click hereC1Click hereC2Click here