RFC8950: IPv4-routes aankondigen met een IPv6 next-hop

Interessante gebruiksscenario's

  • IPv6-only core: Een groot netwerk kan overal in de kern IPv6-only draaien en IPv4 alleen op de edge-apparatuur behouden. Dit kan werken zonder dat klanten aan hun kant aanpassingen hoeven te doen; zij blijven IPv4 gebruiken, terwijl de backbone in de kern volledig op IPv6 draait.
  • IP-transit backbone: Een transit-backbone kan IPv6-only zijn, terwijl IPv4-routes met klanten, peers of upstreams worden uitgewisseld via IPv6-sessies. IPv4 blijft hiermee een "functie", maar het netwerk zelf is IPv6-only, zonder de overhead van IPv4-interfaceconfiguraties, BGP-sessieconfiguraties, firewall-configuraties, enzovoort.
  • Internet Exchange Points (IXP): Een IXP kan diensten aanbieden zonder IPv4 door een uniek IPv6-adres op het IX-LAN te gebruiken en een route server te draaien die zowel IPv4- als IPv6-routes uitwisselt over een IPv6-only sessie.

Kortom: wat 464XLAT heeft gedaan voor mobiele netwerken, heeft deze technologie de potentie om te doen voor backbone-netwerken.

Hoe werkt het?

Multi-protocol BGP (MP-BGP) ondersteunt al het aankondigen van IPv4-routes over IPv6-sessies met IPv4 next-hops, en IPv6-routes over IPv4-sessies met IPv6 next-hops. RFC8950 breidt deze functionaliteit voor IPv4 uit, zodat er IPv6 next-hops kunnen worden gebruikt.

Bij deze methode is de next-hop voor een IPv4-adres een IPv6-adres. De IPv6-bereikbaarheid werkt via de gebruikelijke Neighbor Discovery Protocol (NDP), en het IPv4-verkeer wordt verzonden in ethernet-frames naar hetzelfde MAC-adres als ontdekt door NDP. Technisch gezien beïnvloedt RFC8950 alleen de beslissingen in het control plane door IPv6 te gebruiken, terwijl het data plane ongewijzigd blijft. IPv4 blijft IPv4 en wordt als zodanig over de lijn verzonden, in tegenstelling tot bijvoorbeeld tunnels of 464XLAT.

Hardware-ondersteuning

Op dit moment wordt RFC8950 breed ondersteund door veel routing-platformen, waaronder Juniper JunOS, Cisco IOS XR, Nokia SR OS, Mikrotik, Huawei, BIRD en FRR. Het is dan ook zeer waarschijnlijk dat het ondersteund wordt als u een recente versie van het besturingssysteem gebruikt.

Demo-lab

Hieronder volgt een testopstelling in Container Lab met twee klantrouters (C1 & C2) verbonden via provider-routers R1, R2 en R3. Alle routers in deze opstelling draaien de open-source software FRR.

Configuratie:

  • C1 is aan de WAN-zijde (richting R1) IPv6-only. C1 kondigt 10.0.0.0/24 aan naar R1 via een IPv6-sessie.
  • R1 & R2 zijn IPv6-only; er is nergens op hun interfaces IPv4 geconfigureerd (hoewel ze wel IPv4-routes in hun tabel bijhouden).
  • R3 heeft IPv6-verbinding met R2, maar alleen een IPv4-verbinding met C2. Hiermee simuleert C2 een typische zakelijke gebruiker die geen IPv6-implementatie heeft en afhankelijk is van IPv4.
  • R3 heeft het netwerk 100.64.0.0/24 en kondigt dit aan in de IPv4-tabel (naar de IPv6-adjacency van R2).
  • C2 bevindt zich op 100.64.0.2/30 (toegekend door R3) en communiceert uitsluitend via IPv4.

In deze opstelling kunnen C1 en C2 elkaar bereiken, terwijl delen van het netwerk IPv6-only zijn, zonder dat er tunnels worden gebruikt.

Topologie (topology.yml)

name: rfc8950
topology:
  nodes:
    R1:
      kind: linux
      image: frr-bgpd
      binds:
        - configs/R1.conf:/etc/frr/frr.conf
    R2:
      kind: linux
      image: frr-bgpd
      binds:
        - configs/R2.conf:/etc/frr/frr.conf
    R3:
      kind: linux
      image: frr-bgpd
      binds:
        - configs/R3.conf:/etc/frr/frr.conf
    C1:
      kind: linux
      image: frr-bgpd
      binds:
        - configs/C1.conf:/etc/frr/frr.conf
    C2:
      kind: linux
      image: frr-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"]

Deployment log

> 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 │
╰─────────────────┴───────────────┴─────────┴───────────────────╯

Verificatie van routes op C1 naar C2

C1# 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#

Traceroute van C1 naar C2

C1# 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#

Opmerking: De IPv4-adressen in de trace zijn afkomstig van de eth0 management-interfaces die door Container Lab zijn geïmplementeerd voor 'TTL exceeded'.

Controle van R1 (IPv6-sessies)

R1 heeft alleen IPv6-sessies, maar geen IPv6-prefixen:

R1# 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#

Controle van IPv4-routes op R1

R1# 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#