Extended next hop

Our recommended peering mode carries both IPv4 and IPv6 over a single IPv6 BGP session, using extended next hop (RFC 8950). The tunnel has no IPv4 address at all, so your IPv4 routes must arrive with an IPv6 next hop.

What goes wrong

If your router does not negotiate the extended next hop capability, the session still establishes and your IPv6 routes work fine — but your IPv4 routes arrive carrying an IPv4 next hop. That address is not reachable over the tunnel, so our router would have to resolve it recursively through some unrelated route. When that route changes, every prefix you send us flaps, and the churn spreads to everyone we peer with.

We reject those routes at ingress instead. Your IPv4 prefixes will be missing while this is the case; your IPv6 prefixes are unaffected.

Enabling it

BIRD 2.x — set this on the ipv4 channel, not the protocol:

protocol bgp routedbits {
    local as YOUR_ASN;
    neighbor OUR_LINK_LOCAL % 'YOUR_INTERFACE' as 4242420207;
    ipv4 {
        import filter dn42_import;
        export filter dn42_export;
        extended next hop on;
    };
    ipv6 {
        import filter dn42_import;
        export filter dn42_export;
    };
}

FRR:

router bgp YOUR_ASN
 neighbor OUR_LINK_LOCAL remote-as 4242420207
 neighbor OUR_LINK_LOCAL capability extended-nexthop
 address-family ipv4 unicast
  neighbor OUR_LINK_LOCAL activate
 exit-address-family

Checking it worked

The capability has to be negotiated by both sides. Open your peering page, scroll to Live router output at the bottom, and expand BGP IPv6 session. That runs show bgp neighbors for this session on our router and shows you the result unedited.

Look for the capability line. When it is working you will see:

    Extended nexthop: advertised and received
      Address families by peer:
        IPv4 Unicast

Both words matter. advertised is us offering the capability; received is your router offering it back. The Address families by peer: list immediately under it has to include IPv4 Unicast — that is the family the next hops apply to.

When it is not working you will see our half only:

    Extended nexthop: advertised

That is the state we flag. Note the reading is from our side: on your own router the same session shows the mirror image, where our offer arrives as received and the missing word is your own advertised. Reading it from our output avoids having to reason about which side each word refers to.

You do not have to check by hand. If we detect the problem, a warning appears on your peering page with a Recheck now button, and it clears itself once the capability negotiates.

If you cannot enable it

Switch the peering to Dual-stack (two sessions) or Multiprotocol over IPv6 in the peering editor. Both carry IPv4 with an IPv4 next hop, and both require an IPv4 tunnel address.