Summary

  • RFC 8950 lets BGP carry IPv4 and VPN-IPv4 reachability with an IPv6 next hop. Capability code 5 states support for a specific tuple of NLRI AFI, NLRI SAFI and next-hop AFI; it neither enables the address family nor proves that the next hop is reachable.
  • The receiver derives the next-hop family from the encoded length. A route reflector must preserve an inherited encoding, and it cannot distribute the NLRI to a client that did not advertise support for it.
  • A safe migration proves a chain: both OPEN capabilities, exact MP_REACH_NLRI bytes, import result, IPv6 recursive resolution, selected route, FIB programming, encapsulation or adjacency, and real IPv4 packets. A green session is only the first rung.

At 01:40, an operator moves an aggregation site toward one IPv6 transport fabric. IPv4 customers still exist, and their prefixes remain IPv4. The core no longer needs an IPv4 address on every transport link; BGP can advertise those IPv4 destinations with IPv6 next hops.

Two route reflectors and most clients support the design. A newly replaced client announces Multiprotocol IPv4 unicast and Extended Next Hop Encoding. A second, older client announces IPv4 unicast but no extended-next-hop tuple. Both sessions reach Established.

The first client receives the IPv4 routes, selects them and displays their IPv6 next hop. Traffic nevertheless fails because the resolver looks in a management VRF whose route to that address ends at a different interface. The second client receives no such routes because the reflector is not allowed to translate the next-hop encoding for it. One dashboard reports two healthy peers, another reports a complete IPv4 table at the reflectors, and neither describes the service outcome.

The scene is synthetic, but every boundary is real. RFC 8950 does not merge IPv4 and IPv6 into one address family. It lets one route contain two correctly typed claims: the destination is IPv4; the instruction for reaching the advertising point is IPv6. Operations fail when those claims, and the evidence behind them, are collapsed.

Destination and next hop answer different questions

An NLRI names reachable destinations. A next hop names the address toward which a receiving system should resolve and forward to use that reachability. The two normally share an address family often enough that tools and people begin to treat the pairing as a law. It is only a convention encoded by each AFI/SAFI definition.

Multiprotocol BGP makes that structure visible. MP_REACH_NLRI carries an AFI, a SAFI, a next-hop length, the next-hop bytes and the NLRI. RFC 4760 defined the container. Earlier IPv4 and VPN-IPv4 family definitions expected an IPv4-shaped next hop. That became awkward for a network retaining IPv4 services over an IPv6-only core.

RFC 8950 expands the permitted combination. AFI 1 still says that the NLRI is IPv4. The next-hop AFI may now be 2, IPv6, for the specified SAFIs. No conversion turns an IPv4 customer address into IPv6. No registry transfers authority between protocol families. The route simply points through a different network-layer address family.

That distinction keeps the design narrow. A provider may simplify its underlay while preserving IPv4 at the service edge. It may also use the mechanism only inside one domain, for selected peers or for selected service families. Publication does not impose the architecture, and non-adopters are not invalid. They remain in a different compatibility set.

The economic language must be equally narrow. An IPv6 underlay can reduce duplicated addressing, IGP and operational state in the transport core. It does not eliminate IPv4 demand, customer contracts, address-resource value, support work, translation boundaries or service risk. Calling the core “IPv6-only” describes one layer, not the entire product.

Six octets describe a bounded compatibility promise

Extended Next Hop Encoding is capability code 5. Its value is built from six-octet triples: two octets for the NLRI AFI, two for the NLRI SAFI and two for the next-hop AFI. For this standard, the relevant form is AFI 1, one of SAFI 1, 2, 4, 128 or 129, and next-hop AFI 2.

The tuple matters. Support for IPv4 unicast with an IPv6 next hop does not demonstrate support for labeled unicast, multicast or VPN-IPv4. A product family, line card or release may implement different subsets. A dashboard that reduces the set to extended-nexthop=true throws away the object being negotiated.

The capability is also not the Multiprotocol capability. RFC 8950 is explicit: code 5 supplies information about permissible next-hop encoding for a family that is otherwise allowed. The Multiprotocol Extensions capability independently determines whether the peers may exchange that AFI/SAFI at all.

The minimum proof at OPEN therefore has two columns. Did both peers advertise the relevant MP-BGP family? Did the receiver advertise the exact extended-next-hop triple? A sender may use an IPv6 next hop for IPv4 NLRI only after establishing the second fact. The session can be Established while either family-level permission is absent.

This is a strong example of minimum initial specification. The common protocol does not appoint a controller to decide a migration. It gives independent speakers a stable code, a deterministic tuple and a local decision. If the tuple is absent, the sender withholds that encoding from that peer. Compatibility is selected at the edge where the risk is carried.

The restraint should survive into management systems. An inventory record needs the BGP instance, local and remote addresses, software and hardware version, session epoch, each negotiated AFI/SAFI and every received and advertised extended-next-hop triple. “Device supports RFC 8950” is procurement evidence. It is not a session fact.

Length gives the next hop its type

For IPv4 unicast, multicast and labeled families—AFI 1 with SAFI 1, 2 or 4—an IPv6 next hop occupies 16 or 32 octets. Sixteen carries one IPv6 address. Thirty-two can carry a global IPv6 address followed by a link-local address, using the construction inherited from RFC 2545.

For VPN-IPv4 unicast or multicast—SAFI 128 or 129—the IPv6 form occupies 24 or 48 octets. Each address is represented as a VPN-IPv6 next hop with an eight-octet Route Distinguisher set to zero. RFC 8950 changed the older RFC 5549 VPN encoding to match deployed interoperable behavior and address a recorded erratum.

The receiver must interpret the next-hop family from the length permitted by that AFI/SAFI. Length is not presentation metadata. It is part of the type system. A parser, telemetry exporter or policy engine that normalizes the bytes into one untyped string loses information needed for validation.

Global and link-local addresses also carry different authority. A global address can be recursively resolved through a routing table. A link-local address has meaning only with an interface and local link scope. fe80::1 on two interfaces is not one global routing identity. Evidence that records the address but omits the peer, interface and VRF can join unrelated next hops.

This becomes operationally sharp at unnumbered or link-local eBGP edges. The BGP transport may be valid and the capability may be automatically enabled by an implementation, yet the FIB still needs an interface-scoped adjacency. Reboot, interface replacement or peer-group inheritance can preserve the text of the address while changing the context that made it usable.

The VPN form adds another scope. The zero RD belongs to the encoding rule, while the NLRI still carries its service route distinguisher and route targets under the relevant VPN architecture. Operators must not use one displayed zero to conclude that tenant context disappeared. The next-hop address field and the VPN route identity are different objects.

A route reflector is a witness, not a translator

Route reflection exposes the hardest compatibility boundary. When a reflector passes a next hop unchanged, RFC 8950 says its encoding must not be changed. If a client cannot handle the encoding, the NLRI cannot be distributed to that client.

That rule prevents a reflector from quietly inventing a new forwarding point. Replacing an IPv6 next hop with an IPv4 address would not be neutral formatting. It would transfer recursive and forwarding authority to a different address, potentially requiring a new data path, policy and failure domain.

The consequence is topological. If any client can originate an encoding that others may need to receive through a common reflector, all relevant clients may need compatible support. One upgraded edge can therefore expose a missing capability elsewhere without any defect in the reflector.

The resulting absence is easy to misdiagnose. The client can remain Established. It can receive other IPv4 routes whose next hops use an older encoding. The reflector can retain the withheld route and show it as valid. A table-count alarm may report a discrepancy without explaining that distribution was prohibited by the client's own capability declaration.

The correct evidence joins four views for one session epoch: the originating client's UPDATE, the reflector's accepted route, the receiving client's OPEN capabilities and the reflector's Adj-RIB-Out. If the route is absent, the record should say encoding unsupported for client, not prefix missing or peer unhealthy.

A route server, confederation or next-hop-self policy creates different behavior and must be tested separately. The article's point is not that a next hop can never change. It is that unchanged reflection cannot masquerade as translation, and an intentional rewrite creates a new accountable routing decision.

Recursion is where syntax meets operation

Once a receiver accepts the UPDATE, it must resolve the IPv6 next hop. That is a separate computation from recognizing the encoding. The resolver selects a routing table or VRF, finds a route toward the IPv6 address, follows any recursion, binds a usable adjacency or tunnel and supplies state that the FIB can program.

Each step can fail independently. The IPv6 next hop may be absent from the IGP. It may exist in the global table while the BGP process resolves against a service table. It may recurse through a route whose next hop is unresolved. Neighbor discovery may fail. A label, SID or tunnel required by the architecture may be missing. An MTU may pass small control packets but drop encapsulated service traffic. A line card may lag behind the control plane.

This produces a ladder of claims:

  1. The peer advertised the MP-BGP family.
  2. The peer advertised the extended-next-hop tuple.
  3. The sender emitted the expected MP_REACH_NLRI encoding.
  4. The receiver parsed the next-hop type correctly.
  5. Import policy accepted the route.
  6. The decision process selected or retained it.
  7. The IPv6 next hop resolved in the intended context.
  8. The FIB programmed the IPv4 destination toward the expected adjacency or tunnel.
  9. IPv4 packets reached the intended endpoint and returned.

No rung proves the next. A monitoring system may combine them, but it must preserve which observation supplied each transition. The sentence “BGP has the route” is too coarse for a cross-family design.

The rollback path needs the same precision. Reverting to an IPv4 next hop may require restoring IPv4 underlay reachability, previous next-hop-self policy, legacy peer capabilities and route advertisements in a controlled order. Removing code 5 from configuration without restoring the old resolver path can turn a syntactic rollback into a longer outage.

Security policy acquires an IPv6 control surface

RFC 8950 does not authenticate routes. It extends a representation already subject to BGP's security model. A protected TCP session can still carry an unauthorized or malicious route. RPKI origin validation can assess whether an origin AS is authorized for an IPv4 prefix, but it does not prove that the IPv6 next hop is safe or reachable.

Cross-family operation can also bypass incomplete assumptions in tooling. A policy that inventories only IPv4 next-hop addresses for IPv4 routes will not see the new object. An ACL or telemetry schema may admit the BGP session but omit the IPv6 underlay. A threat detector may classify diversion only when destination and next hop share an address family.

RFC 8950 notes that an IPv6 next hop creates another way to divert traffic across an intervening IPv6 infrastructure. The consequences can include hijacking or denial of service. The document also notes the unusual but possible IPv4-mapped IPv6 next hop, which security checks must not mishandle as an ordinary global IPv6 address.

The appropriate response is not to treat every cross-family route as hostile. It is to expand the authorization object. For each permitted service family, record which peers may advertise IPv6 next hops, which IPv6 prefixes or scopes are acceptable, which resolver tables and tunnels may satisfy them, and which destinations may depend on that path.

Transport authentication, GTSM, prefix policy, RPKI, next-hop authorization, underlay security and packet validation remain separate controls. Combining their results is useful; collapsing their meaning is not.

The canary has to cross both families

A safe canary begins before the capability is enabled. Choose one bounded IPv4 prefix and one intended IPv6 next hop. Record the current route, FIB and packet path, plus the precise peer and resolver contexts. Inventory the expected capability triples for every speaker on the propagation path.

After establishing a new BGP session epoch, capture both OPEN messages. Verify the Multiprotocol tuple and code 5 tuple separately. Do not infer remote receipt from the local configuration; inspect remote or wire evidence.

Next capture the UPDATE. Confirm AFI 1, the intended SAFI, the expected 16/32 or 24/48 length, exact IPv6 bytes and unchanged NLRI. If a route reflector is involved, prove whether it preserved the next hop and whether each target client advertised support.

On every receiving node, preserve pre-policy and post-policy route state, selected path, recursive lookup, output table, adjacency or tunnel and FIB entry. The IPv4 prefix must point to the predicted IPv6 path rather than merely to some reachable default.

Then send real IPv4 traffic. Use controlled source and destination addresses, record direction and return path, test representative size and fragmentation conditions, and correlate packet timestamps with the route epoch. A ping can be one signal; it is not a substitute for the service packet shape when encapsulation or MTU matters.

Finally withdraw the canary and prove cleanup in downstream Adj-RIB-Out, RIB, recursion and FIB. Reintroduce the prior encoding if rollback is part of the exercise. A migration is not reversible because the old configuration exists in version control; it is reversible when the old path can again carry packets under current conditions.

The evidence model is deliberately concrete. The RFC defines a deterministic common language, vendors implement it, operators select where it belongs, and observed network behavior decides whether it works.

The destination did not become IPv6 because its route crossed an IPv6 core. The capability did not become forwarding authority because two OPEN messages carried the same number. The route becomes operationally credible only when the negotiated type, local policy, recursive underlay, programmed hardware and measured packets agree.