DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY - Link-Local Next Hop Capability for BGP

Overview

Positive

what Ze has

Neutral

measures that are neither good news nor bad

Negative

what Ze owes

The 8 shares marked as a part above are the whole of the 15 gated MUSTs: they add to 100%. Proven by a recorded break is a share of TAGGED UNITS, a different population, so it is not one of them.

At a glance

Enrolment

Enrolled: Link-Local Next Hop capability for BGP (code 77): fifteen MUST-level requirements; those of Sections 3 to 6 are conditioned by Section 2 on the capability being negotiated. Ze advertises the capability (extractLLNHCapabilities, internal/component/bgp/plugins/llnh/llnh.go), parses it back as a typed capability (parseCapability, internal/core/bgp/capability/capability.go) and records what it negotiated to (Negotiate, internal/core/bgp/capability/negotiated.go), which is the Section 2 condition every other procedure reads. 3-1 and 5-1 are met on the send side: Peer.linkLocalOnlyNextHopPermitted (internal/component/bgp/reactor/peer.go) admits a link-local next hop only where the session may carry the 16-octet form, and buildMPReach (internal/component/bgp/message/update_build.go) writes that address alone in 16 octets, or the global-then-link-local pair in 32. 4-5 and 4-6 are met on the reflection path: egressNextHopIsLinkLocalOnly (internal/component/bgp/reactor/forward_next_hop.go) classifies the field about to be written and sameLinkLayerSegment (internal/component/bgp/reactor/link_scope.go) answers the segment half, so forwardUpdateCore either sends the rewrite applyFactsNextHop recorded or withholds the announcement. 3-2 is met by the RFC 2545 32-octet path; 4-2 and 4-8 are met because a link-local is appended only when the peer shares a connected subnet. 4-1, 4-4, 4-7 and 4-9 are met because a route whose next hop has no wire form is refused rather than encoded, and 4-3 because a route reachable through the speaker carries the speaker's own link-local toward a one-hop peer. 6-1 is met on the receive side: on a session that negotiated the capability, validateLinkLocalNextHopPair (internal/component/bgp/message/rfc7606_linklocal.go), called from the RFC 7606 attribute walk, makes a 32-octet Next Hop field that is not a Global (or ::) followed by a Link-Local, nor two Link-Locals, treat-as-withdraw. One MUST-level requirement stays outstanding and carries a `{gap}` on its checklist line: 1-2, the Section 1 interface association (row added 2026-10-01, rfc/corrections/draft-ietf-idr-linklocal-capability.md). 4-15, the second condition of the 4-3 sentence (split 2026-10-01, rfc/corrections/draft-ietf-idr-linklocal-capability.md), is `{not-applicable}`: RFC 4271 Section 5.1.3 forbids the route it would apply to.

What the public ledger says

Status: Partial

What the ledger says remains:

Coverage

Positive and negative tests (13): DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-3-1, DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-3-2, DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-4-1, DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-4-2, DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-4-3, DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-4-4, DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-4-5, DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-4-6, DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-4-7, DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-4-8, DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-4-9, DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-5-1, DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-6-1

Annotated (including scoped evidence) (2): DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-1-2, DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-4-15

Requirements

Gaps and untested MUSTs

Proof state

A tagged unit reads unproven where no discrimination record exists for it: nothing in this tree has been observed to break it, so the claim its tag makes is unproven.

DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-1-2

Since IPv6 Link-Local addresses are not required to be globally unique, implementations must ensure that they are strictly associated with a specific interface. (§1)

Audit verdict: unimplemented (no code path enforces the requirement), fresh. Judged 2026-10-01 (BGP c20 judge, R58(c)). Row text is a verbatim span of draft -06 Section 1 (lowercase must, ruled to bind the implementation). Gap confirmed at the producers: mpNextHopAddr (rib_bestchange.go) turns the received Next Hop octets into a bare netip.Addr with no zone and no interface, and nothing in the BGP best-change path sets one (no WithZone on that path); on the send side applyLinkLocal (config_nexthop_form.go) parses session link-local as a plain address with no tie to the session's interface. The {gap} annotation states both halves.

No test carries DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-1-2, so no unit is bound to it.

DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-3-1

If an implementation intends to send a single IPv6 Link-Local forwarding address in the Next Hop field of the MP_REACH_NLRI, it MUST set the length of the Next Hop field to 16 and include only the IPv6 Link-Local address in the Next Hop field. (§3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Forbidden: a sender meaning to send one Link-Local address writes a field other than 16 octets, or adds another address. TestLinkLocalOnlyNextHopFieldIsSixteenOctets builds the UPDATE through resolveNextHop and BuildUnicast and asserts assert.Len(field, 16) and that the field equals fe80::1 alone; either defect turns it red. The negative TestLinkLocalNextHopWithAGlobalIsNotSentAlone shows the 16-octet form is keyed on one address (32 octets when a Global is also sent).

DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-3-2

If an implementation intends to send both a IPv6 Global and Link- Local forwarding address in the Next Hop field of the MP_REACH_NLRI, it MUST set the length of the Next Hop field to 32 and include both the IPv6 Global and Link-Local addresses in the Next Hop field. (§3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-01 (BGP c21 judge). The c19 finding is closed: TestLinkLocalBothAddressesSetTheWireLengthOctetToThirtyTwo reads the MP_REACH_NLRI Length of Next Hop octet off the bytes sendStaticRoutes wrote to the one-hop internal peer's connection and asserts 0x20 followed by exactly 2001:db8:1::1 then fe80::1 (both clauses: length 32, both addresses); TestLinkLocalSingleAddressSetsTheWireLengthOctetToSixteen asserts 0x10 and the lone global for a route through another router, so the 32-octet length is tied to sending both. mpReachNextHopField slices exactly the octets the length announces and fails when none is written. Records observed red on mpnlri.go::nextHopLen. The older facts-level units stay tagged; their assert.Len over a [32]byte array is vacuous and carries no weight in this verdict.

DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-4-1

If, after completing these procedures, there are no IPv6 next hop addresses included in the next hop, the BGP route MUST not be advertised to its peer. (§4)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Rejudged against draft -06 Sections 2 and 4. Section 4 says: 'If, after completing these procedures, there are no IPv6 next hop addresses included in the next hop, the BGP route MUST not be advertised to its peer. Instead, treat-as-withdraw (Section 2 of [RFC7606]) is used.' TestLinkLocalOnlyRouteWithdrawnFromMultihopPeer exercises forwardUpdateCore with received fe80::1, NextHopUnchanged, internal and external destinations outside the connected subnet; it requires dispatch to each distant destination, no announced next hop, and exact MP_UNREACH for 2001:db8:7::/64. The same fan-out requires an attached destination to receive exactly fe80::1. llnhExternalPeer now sets negotiated.LinkLocalNextHop=true, making that control conforming and preventing the capability refusal from masking the off-link gate. egressNextHopWithheld calls egressNextHopLinkLocalOnlyOffLink, and forwardUpdateCore turns the refusal into SetWithdraw. The two tagged buildRIBRouteUpdate tests additionally distinguish absent next hop (nil UPDATE for internal/external) from a Global address (exact 16-octet next hop), but alone are not the treat-as-withdraw proof. This is source-level judgment of semantic assertions, not a new execution or interop-pass claim.

DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-4-2

If the internal peer is more than one IP hop away, the BGP speaker MUST NOT include a Link-Local IPv6 next hop. (§4)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-04 after f93a30fbfc. Forbidden: including a Link-Local next hop toward an internal peer more than one hop away. The third-party case the earlier weak verdict named is now driven: TestLinkLocalReceivedPairStrippedForMultihopInternalPeer relays the received 32-octet 2001:db8:1::1 + fe80::9 pair through forwardUpdateCore under next hop unchanged and under auto to an internal (AS 65000) peer off every connected subnet and asserts the exact 16-octet Global alone; the control in the same fan-out, an internal peer on the advertiser's subnet, keeps the exact 32-octet pair, which RFC 2545 Section 3 permits without the capability. Restoring the pass-through turns the positive red. The facts-level units still cover the next-hop-self half.

DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-4-3

If the route is directly connected to the speaker, or if the interface address of the router through which the announced network is reachable for the speaker is the internal peer's address, the next hop MUST include its own Link- Local IPv6 address. (§4)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-01 (BGP c20 judge, R58(a)). The c19 hole is closed at its producer: refuseLinkLocalCapabilityWithoutAddress (llnh.go), run by both OnConfigVerify (commit) and OnConfigure (startup, FatalOnConfigError in register.go), refuses a peer, a group member or a dynamic-group template whose capability 77 is enabled (llnhEnabledFor, the same answer extractLLNHCapabilities advertises from) with no session link-local on the peer or its group; ResolveBGPTree merges the group's session leaves into the peer, so the group case matches what the reactor's applyLinkLocal reads. So every configuration that can negotiate 77 carries the address linkScope.linkLocalNextHop appends. New units, both through the real LoadConfig + ToPluginMap lowering: negative TestLinkLocalCapabilityRefusedWithoutLinkLocalAddress (standalone and group-inherited capability refused, error names peer1 and session link-local, the section entry refuses too); positive TestLinkLocalCapabilityAcceptedWithLinkLocalAddress (leaf on peer, group, member: accepted and the capability still declared). Both recorded red under the producer break. The wire half stays proven both polarities on the announce rail (directly connected originated route: [global, fe80::1]; route through another router: 16-octet global) and on the forward facts (next-hop self, local ip auto, unchanged), each with an observed-red record. Functional: test/plugin/llnh-refuses-without-link-local.ci (ze boot exits 1 with the refusal) passes. Residual note: the wire units do not negotiate capability 77 itself; linkLocalNextHop does not read the capability, so the same producer answers with and without it.

DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-4-4

If, after evaluating the above procedures, there are no IPv6 next hops included with the route, the route MUST NOT be announced to the remote BGP speaker. (§4)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-04 after f93a30fbfc. Forbidden: announcing to an internal peer a route the internal-peer procedures leave with no IPv6 next hop, rather than treat-as-withdraw. TestLinkLocalOnlyRouteWithdrawnFromMultihopPeer (internal=true branch) relays a Link-Local-only fe80::1 to an internal peer more than one hop away, where the Link-Local MUST NOT be included and nothing remains, and asserts no MP_REACH next hop and the exact MP_UNREACH_NLRI for the prefix, so 'after evaluating the above procedures' is an input and the withdrawal is asserted. Control: TestLinkLocalRouteWithANextHopIsAnnouncedToAnInternalPeer announces the same route with a Global next hop and LOCAL_PREF (RIB rail, cross-rail but conformant). The RIB-rail positive alone is still only a zero-address builder check.

DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-4-5

A Route Reflector (RR) reflecting a route with a link-local-only next hop MUST NOT advertise that route to a client unless the client shares the same link-layer segment as the original advertiser. (§4)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Rejudged against draft -06 Section 4: 'A Route Reflector (RR) reflecting a route with a link-local-only next hop MUST NOT advertise that route to a client unless the client shares the same link-layer segment as the original advertiser.' llnhClient now sets negotiated.LinkLocalNextHop=true. More importantly, the tagged TestReflectedLinkLocalOnlyRouteIsWithheldFromAClientOffTheSegment now includes directly-attached-other-segment: both clients are on connected /64s, only one shares the advertiser's /64, and both use NextHopUnchanged. On forwardUpdateCore's reflected path the off-segment client must be dispatched the exact MP_UNREACH for 2001:db8:7::/64, with no MP_REACH attribute and no next hop; the same-segment client must receive MP_REACH with exactly fe80::1 and no MP_UNREACH. These are distinct conforming/refused outcomes despite sharing one tagged function. Reading egressNextHopWithheld, sameLinkLayerSegment and destOnLink establishes isolation: removing only the reflection segment refusal leaves both clients on-link and capability-authorized, so the off-segment announcement violates the explicit no-MP_REACH and exact-withdrawal assertions. The older outer off-segment case alone was confounded by the independent multihop refusal; the new attached-other-segment subtest closes that proof gap. No remaining 4-5 source/test fix is established by this focused review. This is semantic source evidence, not an observed mutation run or an interop-pass claim.

DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-4-6

For all other clients, the RR MUST either rewrite the next hop to its own address (next-hop-self) or consider the route ineligible for advertisement to that specific peer. (§4)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-04 after f93a30fbfc. Forbidden: for an off-segment client, sending the Link-Local-only route neither rewritten nor ineligible. TestReflectedLinkLocalOnlyRouteIsRewrittenOrIneligibleForOtherClients asserts the next-hop-self client receives exactly 2001:db8:1::254 and not a Link-Local-only field, and the client without rewrite is written no MP_REACH next hop (now the withdrawal under the owner's decision; assert.Empty does not distinguish withdrawal from nothing, which the sentence does not require). Negative TestReflectedGlobalNextHopRouteIsNeitherRewrittenNorWithheld: a Global next hop reaches the same off-segment client unchanged. No assertion delivers a Link-Local-only next hop, so the capability-77 fixture gap does not touch this pair.

DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-4-7

If no next hops are included, the route MUST NOT be announced (treat-as- withdraw). (§4)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-04 after f93a30fbfc. Forbidden: announcing to a one-hop external peer a route with no next hop included, rather than treat-as-withdraw. TestNextHopSelfWithheldRouteServerWithdraws requires the fixture reached nhSelfWithheld (next-hop self configured, no address of this speaker, so third-party is disabled and nothing remains) and asserts on the route-server rail no MP_REACH next hop and the exact MP_UNREACH_NLRI for the prefix; the client is on-link, so no other gate explains the refusal. Both rails share egressNextHopWithheld and each calls mods.SetWithdraw on any refusal, and the general-rail withdrawal is proven by the 4-1 unit. Control: TestLinkLocalRouteWithANextHopIsAnnouncedToAnExternalPeer (RIB rail, cross-rail, conformant). The RIB-rail positive alone is a zero-address builder check.

DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-4-8

When sending a message to an external peer X, and the peer is multiple IP hops away from the speaker (aka "multihop EBGP"): * Link-Local IPv6 next hops MUST NOT be included. (§4)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-02 (BGP c22 judge). The route-server rail the c21 judge named is now driven: TestLinkLocalRouteServerStripsReceivedPairForMultihopClient relays the received 32-octet 2001:db8:1::1+fe80::9 through reactorForwardRS to an off-link external client under next hop unchanged and auto and asserts the 16-octet Global alone; TestLinkLocalRouteServerKeepsReceivedPairForAttachedClient keeps the pair for a client on the connected /64. The author's overlay disabling only the forward_rs.go call (strip && false, job-c22-nocut log, read by the judge) turns the RS positive red, so the RS call is pinned on its own. General rail unchanged from c21 (forwardUpdateCore units, both polarities). Revert records on egressNextHopGlobalHalf observed red for all four units.

DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-4-9

If a Global IPv6 next hop is not included, the route MUST NOT be advertised to the external peer (treat-as-withdraw). (§4)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Rejudged against draft -06 Section 4's multihop EBGP procedure: 'If a Global IPv6 next hop is not included, the route MUST NOT be advertised to the external peer (treat-as-withdraw).' TestLinkLocalOnlyRouteWithdrawnFromMultihopPeer (external branch, general rail) and TestLinkLocalOnlyRouteServerWithdrawnFromMultihopClient (route-server rail) relay received fe80::1 unchanged to an external destination outside every connected subnet and require dispatch, no announced next hop, and exact MP_UNREACH for 2001:db8:7::/64. Their attached controls receive exactly fe80::1; llnhExternalPeer now supplies negotiated.LinkLocalNextHop=true, so those controls are conforming and capability refusal cannot explain the distant-peer result. Both production rails invoke egressNextHopWithheld and materialize a withdrawal when egressNextHopLinkLocalOnlyOffLink refuses the no-Global route. The two additional tagged advertise tests distinguish no Global (nil RIB-built UPDATE) from an exact 16-octet Global next hop, alongside multihop next-hop-self facts; they supplement rather than replace the forwarding withdrawal proof. This is source-level judgment of semantic assertions, not a new execution or interop-pass claim.

DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-4-15

if the interface address of the router through which the announced network is reachable for the speaker is the internal peer's address, the next hop MUST include its own Link- Local IPv6 address. (§4)

Audit verdict: not-applicable (the requirement has no reachable code path in Ze), fresh. Judged 2026-10-01 (BGP c19 judge). Split from 4-3 under R3/R57(a); row text is a verbatim span of the Section 4 sentence's second clause. Read both producers: egressNextHopIsPeerOwn compares the (modified) next hop to f.addr, originatedNextHopIsPeerOwn reads the built body. The untagged TestLinkLocalSecondConditionNeverReachesTheWire (static route, explicit next hop = the internal peer's 2001:db8:1::2) asserts nothing is written, while the sibling ::99 route on the same fixture is written, so the empty wire is the withholding, not a dead fixture. Untagged because the gate refuses a tag beside {not-applicable}; that reading is accepted.

No test carries DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-4-15, so no unit is bound to it.

DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-5-1

When this combination has not been negotiated, a sender MUST follow the rules in Section 3 of [RFC8950] and encode the Next Hop as 32 octets. (§5)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Forbidden: sending the 16-octet Link-Local-only field for IPv4 NLRI when capability 77 plus RFC 8950 were not both negotiated. TestIPv4NLRINextHopIsThirtyTwoOctetsWithoutTheCombination asserts require.ErrorIs(err, ErrNextHopLinkLocalOnly) from resolveNextHop and assert.Len(field, 32) with Global then Link-Local; admitting the 16-octet form turns it red. The negative TestIPv4NLRILinkLocalOnlyNextHopNeedsTheCombination shows the 16-octet form is sent once both are negotiated.

DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY-6-1

If the Next Hop field is malformed, the implementation MUST handle the malformed UPDATE message using the approach of "treat-as- withdraw", as described in section 7.3 of [RFC7606]. (§6)

Audit verdict: unimplemented (no code path enforces the requirement), stale-unit. Re-judged 2026-10-02 (BGP c22 judge). Gap unchanged; the {gap} annotation is now aimed at the content half as the c21 judge required: on a capability-77 session no receive producer inspects the addresses of an admitted 32-octet Next Hop field, so a field that is not Global followed by Link-Local is never treated as withdrawn. A wrong Length stays an RFC 7606 Section 7.11 session reset in validateMPReachNextHop, which is correct and named here as the producer that admits the field without inspecting it. Dated correction in rfc/corrections.

Extraction sign-off

Sections

Excluded sentences

Superseded

No document obsoletes DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY, so its obligations are stated where they were written.