a positive test proves Ze does what the requirement demands and a negative one proves it refuses what the requirement forbids
Partial
RFC 2545 - Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing
Every requirement this repository extracted from RFC 2545, the tests bound to it, and what a reader has verified about them. This summary is enrolled and gated by ./le rfc check.
Overview
Positive
what Ze has
the requirement admits no counter-case, so one polarity plus a recorded reason is the whole proof available for it
one direction is tested, the other is neither tested nor excused, and nothing states which
a red was observed once under a recorded procedure, and the unit, the claim and the producer it rested on still hash to what was recorded. The break is not re-run. A test pair is not a proof until one has been observed
Neutral
measures that are neither good news nor bad
MUST-level requirements the gate HOLDS. A population, not a result: the shares beside it are what says how Ze stands
an obligation that does not bind Ze. A {not-applicable} annotation says it never bound; a {feature-declined} annotation says its condition is an optional feature Ze does not offer, and quotes the RFC sentence that makes it optional. Scope, not coverage: it stays in the denominator every share on this page is taken over
a {not-applicable} annotation says the obligation does not bind Ze, so no test is owed for it. It stays in the denominator every share here is taken over
a {lower-layer} annotation says a layer under Ze performs the behavior, on state Ze installs into that layer, and names the producer that installs it. The obligation binds Ze and is met; Ze proves none of it, because its own boundary carries no value the behavior reads
a {feature-declined} annotation says the obligation is conditional on a feature the RFC makes optional and Ze does not offer, and it quotes the sentence that makes it optional. The condition is false, so nothing is owed and nothing is missing. It stays in the denominator every share here is taken over
Negative
what Ze owes
scoped tests exist; the remaining obligation is unmet or unproven, with zero whole-requirement credit
no test carries the requirement id, whether or not a gap states why
2 weak, wrong or unimplemented, 4 no longer current. Each is named below under its own requirement id
The 8 shares marked as a part above are the whole of the 5 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.
How to read the colors
A color names what the measure MEANS, not how well Ze scores on it. Green is a good outcome at any value, red is a bad one, and neither a population nor a scope count is an outcome, so both take no color. The number under the label is what says how far Ze has got.
| Card | Tone here | Why that color |
|---|---|---|
| Gated MUSTs | neutral | no color: a population is a scale, and a larger one is neither good news nor bad. It is the accounting total |
| Out of scope | neutral | no color: an obligation that never bound Ze is neither an achievement nor a failure, and counting it either way would be a claim |
| Tested both ways | ok | green at every value: a test pair is the outcome this gate exists to produce, and the share under the label is what says how far Ze has got |
| One polarity plus reason | ok | green at every value: where no counter-case exists, one polarity IS the complete answer, and a recorded reason is what the gate demands beside it |
| One polarity, unexcused | ok | green at zero, RED above it: half a proof with no reason for the other half |
| Partial proof; remaining gap | bad | green at zero, RED above it: a tested clause cannot prove the whole requirement |
| No test at all | bad | green at zero, RED above it: a binding obligation nothing exercises is a claim with nothing behind it, whether or not a reason is stated |
| Not applicable | neutral | no color: an obligation that never bound Ze is neither an achievement nor a failure, and counting it either way would be a claim |
| Met below Ze | neutral | no color: an obligation met below Ze is neither a test Ze wrote nor work Ze owes, and the two green shares above are what says how much Ze proves itself |
| Optional feature declined | neutral | no color: an obligation whose condition Ze never meets is neither an achievement nor a failure. The absent FEATURE is disclosed on the RFC's own status row, as an implementation gap a later scope decision can revisit |
| Proven by a recorded break | ok | green at every value: an observed break is the outcome the discrimination gate exists to produce. The denominator is TAGGED UNITS, not obligations, so this share is not one of the parts above |
| Audit verdicts | bad | RED on the first weak, wrong or unimplemented verdict, amber while a verdict is no longer current or a gated MUST is unjudged, green when every one is judged sound and current |
At a glance
| Field | Value |
|---|---|
| Public status | Partial |
| Enrolment | Enrolled |
| Requirements | 7 |
| Gated MUST-level | 5 |
| Not applicable, so out of scope | 0 |
| Declared gaps | 1 |
| Declared gaps a test demonstrates | 0 |
| Gated with no test | 0 |
| Nightly-only evidence | 0 |
| Test tags | 99 |
| Tagged units | 99 |
| Recorded audit verdicts | 5 |
| Discrimination records | 96 |
| Summary | rfc/short/rfc2545.md |
| Requirement shard | rfc/requirements/rfc2545.md |
| RFC text | rfc/full/rfc2545.txt |
Enrolment
Enrolled: Section 3 specifies the address order, length and shared-subnet conditions for the MP_REACH_NLRI next-hop field. Section 2 scope definitions and Section 4 BGP Identifier references are classified in rfc/extraction/rfc2545.json. Enrolled 2026-08-07.
What the public ledger says
Status: Partial
What the ledger says is covered
Default/static, API-batch, queued-RIB and named-commit paths enforce next-hop address roles and final ordinary policy admission. Forwarding and stored replay judge the effective field after policy against one connected prefix containing the recipient and global next hop. Exact recipient-wire tests, distinct-endpoint topology, restored FRR captures and public SDK workflows cover supported own-address and received-pair cases. The earlier Supported claim counted tagged coverage, not proof of every condition.What the ledger says remains
Partial: the wholeRFC2545-3-3 sentence remains unmet where only another router's global address is supplied on the common subnet. linkScope.linkLocalNextHop has no source for that router's Link-Local; the separate RFC2545-3-6 gap does not narrow the identical whole sentence. Configured speaker-owned Link-Local inclusion and the otherwise-global-only branch are implemented and exercised, including post-policy forwarding. No new Neighbor Discovery or liveness service is implied. Capability77 and VPN exceptions retain their separate draft/RFC4659 contracts.
Coverage
| Bucket | Count | What it counts |
|---|---|---|
| Positive and negative tests | 3 | one part of the gated population |
| Annotated (including scoped evidence) | 2 | one part of the gated population |
| One polarity only | 0 | one part of the gated population |
| No test and no annotation | 0 | one part of the gated population |
| Partial proof; remaining gap (subset of annotated; zero whole-requirement credit) | 1 | an overlay: each of these is also counted by the part it falls in |
| Evidence that runs nightly only | 0 | an overlay: each of these is also counted by the part it falls in |
| Derived from other rows | 0 | outside the gated population: each asserts nothing and derives its state from the rows it names, which the parts above already count |
| Gated MUST-level requirements | 5 | every gated MUST falls in exactly one bucket above |
Positive and negative tests (3): RFC2545-3-1, RFC2545-3-2, RFC2545-3-4
Annotated (including scoped evidence) (2): RFC2545-3-3, RFC2545-3-6
Partial proof; remaining gap (subset of annotated; zero whole-requirement credit) (1): RFC2545-3-3
Requirements
| Requirement | Level | Section | Tests |
|---|---|---|---|
RFC2545-3-1 | A BGP speaker shall advertise to its peer in the Network Address of Next Hop field the global IPv6 address of the next hop, potentially followed by the link-local IPv6 address of the next hop. (§3) | ||
| SHALL | 3 - Constructing the Next Hop field | ||
RFC2545-3-2 | The value of the Length of Next Hop Network Address field on a MP_REACH_NLRI attribute shall be set to 16, when only a global address is present, or 32 if a link-local address is also included in the Next Hop field. (§3) | ||
| SHALL | 3 - Constructing the Next Hop field | ||
RFC2545-3-3 | The link-local address shall be included in the Next Hop field if and only if the BGP speaker shares a common subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to. (§3) | ||
| SHALL | 3 - Constructing the Next Hop field | {partial}: tested "only if the BGP speaker shares a common subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to."; gap "The link-local address shall be included in the Next Hop field if"; internal/component/bgp/reactor/link_scope.go::linkLocalNextHop is the missing-address boundary: Tested covers exclusion outside one common subnet, with conforming inclusion controls where the effective next-hop entity's link-local is already available from a supplied pair or configured speaker-owned address; current configured/default/direct/static, ordinary API/queued/commit and post-policy forwarding paths implement those cases, and stored replay retains supplied pairs; Gap is the remaining sufficient-condition obligation for an externally advertised third-party next hop on the common subnet when only its global address is supplied, because classify identifies another router and this producer has no source for that router's link-local; the speaker's own link-local must not be substituted; conforming controls and the separate RFC2545-3-6 disclosure do not discharge that missing include case, and no discovery or liveness feature is implied Scoped evidence: Tests and tag-claim records apply only to Tested; zero whole-requirement credit. partial (the tests enforce only the declared tested scope; the whole requirement remains unmet), stale-unit: internal/component/bgp/reactor/link_scope.go::linkLocalNextHop moved. Re-judged 2026-10-15 (subagent, after 34fc08f0d4). RFC 2545 Section 3: "The link-local address shall be included in the Next Hop field if and only if the BGP speaker shares a common subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to." checkRFC2545NextHops changed in one line: rfc2545LinkLocal(check.Network) became linkLocalAt(check.Network, zeHostNumber), and zeHostNumber is 2, the host octet the deleted builder hard-coded, so the expected fe80:: address and every fail(N) assertion are unchanged. Tested/Gap/Producer scope untouched. The prior judgement stands: Re-judged 2026-10-12 (independent auditor) after owner-approved lint-only edits in 96ec49327b and 4e731b2d96; the row text is unchanged and each changed unit was re-read diff by diff. TestRFC2545JointSubnetWriter builds the global+fe80::9 pair with slices.Concat instead of a capped append (same 32 octets); the default-originate units take the same local and link-local addresses from constants. No assertion changed, and the Tested/Gap/Producer scope is untouched; the four 3-3 discrimination records were re-observed in 4e731b2d96. Verdict stands. Tested is 'only if the BGP speaker shares a common subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to.'; Gap is 'The link-local address shall be included in the Next Hop field if'; these locators distinguish the necessary-condition exclusion side from the incompletely implemented sufficient-condition inclusion side, with actual scope bounded by the annotation's explanation; omission outside one joint connected prefix and conforming inclusion where the next-hop entity's link-local is supplied or configured are enforced by the inspected default/direct, received-pair, joint-subnet, ordinary batch/queued/commit, compatibility, native-topology and independent FRR carriers; TestRFC2545ForwardPolicyOwnGlobalJointSubnet adds the repaired effective speaker-owned global case on cached/RS, Auto/Unchanged and operation/raw-policy fallback, with exact fields, unchanged sibling and one policy call; the actual public SDK old/final receipt records old failure and final success without substituting an internal seam for the daemon workflow; Producer internal/component/bgp/reactor/link_scope.go::linkLocalNextHop still returns no second address for ThirdParty because no source for that entity's link-local exists when only its global is supplied on the common subnet, so the whole sentence earns no enforced credit; retained positive and negative native producer-break records cover the declared implemented population, and the missing third-party source is not silently implemented or excused by RFC2545-3-6 Rejudged 2026-10-12 after commit ce62c78c3b moved peer_initial_sync_test.go around these units: the tagged functions there were re-read and are byte-identical, their assertions and fixtures still carry the evidence this note cites, and the other cited units did not change, so the verdict stands. Rejudged 2026-10-12 after 7a637d6df5 renamed SendUpdateHeld to sendUpdateHeld in two comments of peer_initial_sync_test.go: every tagged unit cited here is byte-identical (gate-verified), the comment edits sit outside them, and the assertions and fixtures still carry the evidence this note cites, so the verdict stands. |
|
RFC2545-3-6 | The link-local address shall be included in the Next Hop field if and only if the BGP speaker shares a common subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to. (§3) | ||
| SHALL | 3 - Constructing the Next Hop field | positive
no testno positive testnegative
no testno negative test{gap}: the include half for another router on the common subnet lacks a source for that router's Link-Local when configured/static/API origination or an explicit rewrite supplies only its global address. Section 3 names "the link-local IPv6 address of the next hop"; link_scope.go::linkLocalNextHop therefore never substitutes the speaker's own address after a global that nextHopOwners.classify identifies as ThirdParty. A received complete pair supplies that missing address itself: applyEgressNextHopScope preserves a valid effective pair only when one connected prefix contains both recipient and global entity, and otherwise trims its Link-Local half. It also appends an available configured own Link-Local after a speaker-owned effective global on the common subnet. Those implemented cases do not implement third-party discovery or discharge the complete RFC2545-3-3 sentence |
|
RFC2545-3-4 | In all other cases a BGP speaker shall advertise to its peer in the Network Address field only the global IPv6 address of the next hop (the value of the Length of Network Address of Next Hop field shall be set to 16). (§3) | ||
| SHALL | 3 - Constructing the Next Hop field | ||
RFC2545-4-1 | should be derived from an IPv4 address regardless of the network protocol(s) a particular BGP-4 instance is configured to convey at a given moment. (§4) | ||
| SHOULD | 4 - Transport | positive
no testno positive testnegative
no testno negative test |
|
RFC2545-3-5 | a BGP speaker that advertises a route to an internal peer may modify the Network Address of Next Hop field by removing the link-local IPv6 address of the next hop. (§3) | ||
| MAY | 3 - Constructing the Next Hop field | positive
no testno positive testnegative
no testno negative test |
|
Gaps and untested MUSTs
| Requirement | State | Reason |
|---|---|---|
RFC2545-3-3 The link-local address shall be included in the Next Hop field if and only if the BGP speaker shares a common subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to. (§3) |
{partial}, Partial proof; remaining gap | tested "only if the BGP speaker shares a common subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to."; gap "The link-local address shall be included in the Next Hop field if"; internal/component/bgp/reactor/link_scope.go::linkLocalNextHop is the missing-address boundary: Tested covers exclusion outside one common subnet, with conforming inclusion controls where the effective next-hop entity's link-local is already available from a supplied pair or configured speaker-owned address; current configured/default/direct/static, ordinary API/queued/commit and post-policy forwarding paths implement those cases, and stored replay retains supplied pairs; Gap is the remaining sufficient-condition obligation for an externally advertised third-party next hop on the common subnet when only its global address is supplied, because classify identifies another router and this producer has no source for that router's link-local; the speaker's own link-local must not be substituted; conforming controls and the separate RFC2545-3-6 disclosure do not discharge that missing include case, and no discovery or liveness feature is implied |
RFC2545-3-6 The link-local address shall be included in the Next Hop field if and only if the BGP speaker shares a common subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to. (§3) |
{gap}, no test | the include half for another router on the common subnet lacks a source for that router's Link-Local when configured/static/API origination or an explicit rewrite supplies only its global address. Section 3 names "the link-local IPv6 address of the next hop"; link_scope.go::linkLocalNextHop therefore never substitutes the speaker's own address after a global that nextHopOwners.classify identifies as ThirdParty. A received complete pair supplies that missing address itself: applyEgressNextHopScope preserves a valid effective pair only when one connected prefix contains both recipient and global entity, and otherwise trims its Link-Local half. It also appends an available configured own Link-Local after a speaker-owned effective global on the common subnet. Those implemented cases do not implement third-party discovery or discharge the complete RFC2545-3-3 sentence |
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.
RFC2545-3-1
A BGP speaker shall advertise to its peer in the Network Address of Next Hop field the global IPv6 address of the next hop, potentially followed by the link-local IPv6 address of the next hop. (§3)
Audit verdict: enforced (the tests do what the requirement demands), stale-unit: internal/component/bgp/reactor/rfc2545_forward_subnet_test.go::TestRFC2545EffectivePairPolicyAndMixedSibling, internal/component/bgp/reactor/rfc2545_forward_subnet_test.go::TestRFC2545EffectivePairPolicyAndMixedSibling#2, internal/component/bgp/reactor/rfc2545_forward_subnet_test.go::TestRFC2545ReceivedPairFirstAddressValidated, internal/component/bgp/reactor/rfc2545_forward_subnet_test.go::TestRFC2545ReceivedPairFirstAddressValidated#2, internal/component/bgp/reactor/rfc2545_forward_subnet_test.go::TestRFC2545ReceivedPairSecondAddressValidated, internal/component/bgp/reactor/rfc2545_forward_subnet_test.go::TestRFC2545ReceivedPairSecondAddressValidated#2 moved. Re-judged 2026-10-12 (independent auditor) after owner-approved lint-only edits in 96ec49327b and 4e731b2d96; the row text is unchanged and each changed unit was re-read diff by diff. srpolicy subtests gained t.Parallel (each subtest builds its own UPDATE from per-iteration loop values, no shared state); reactor units drop redundant capability.AFI/SAFI conversions and newDefaultOriginatePeer takes its local endpoint 2001:db8:1::1 and link-local fe80::1 from constants with the same values. No input byte, address or assertion changed. Verdict stands. Independently rejudged against RFC2545 Section 3's global-first, optional next-hop-entity link-local-second sentence and the current changed carriers; TestRFC2545ReceivedUnusableGlobalRefused requires exact native withdrawals for unspecified/multicast first addresses and exact announcements for usable controls, while TestRFC2545ReceivedPairSecondAddressValidated crosses Session receipt and both forwarding consumers and refuses invalid second slots before scope trimming can conceal them; capability-77 negotiation combinations retain a separate standalone-link-local control, not permission for malformed pairs; announceNextHopOctets, ValidateMPNextHop/ValidateIPv6NextHop and egressNextHopWithheld continue to enforce their applicable address roles, including final effective policy fields and family-specific mapped/VPN exceptions; the repaired compatibility fixture pins fd00::2 followed by its assigned fe80::1, and the distinct-namespace stored replay fixture requires two complete ordered-pair UPDATEs with separately owned live and explicit replay arrivals; existing configured/API/queued/commit/SR-Policy carriers remain part of the previously read composition; these assertions prove address roles/order, not the missing conditional third-party address source covered separately by 3-3/3-6; native producer halts establish binding only, not a substitute for these assertions Rejudged 2026-10-12 after commit ce62c78c3b moved peer_initial_sync_test.go around these units: the tagged functions there were re-read and are byte-identical, their assertions and fixtures still carry the evidence this note cites, and the other cited units did not change, so the verdict stands. Rejudged 2026-10-12 after 7a637d6df5 renamed SendUpdateHeld to sendUpdateHeld in two comments of peer_initial_sync_test.go: every tagged unit cited here is byte-identical (gate-verified), the comment edits sit outside them, and the assertions and fixtures still carry the evidence this note cites, so the verdict stands. Rejudged 2026-10-16 (independent reader) after the owner-approved 2026-10-16 change ("5 RFC") to TestFamilyNextHopForwardAdmission: the one edit is in the refused-next-hop branch, where the expected MP_UNREACH_NLRI now has its 3 label octets (want[4:7], after AFI, SAFI and the NLRI length octet) replaced by 0x800000 for SAFI 4 and 128 (the two ipv4/ipv6-labeled cases here; the producer setWithdrawalCompatibility selects families through the nlrisplit.CarriesCompatibility registry). RFC 8277 Section 2.4: "Upon transmission, the Compatibility field SHOULD be set to 0x800000. Upon reception, the value of the Compatibility field MUST be ignored." The next-hop field the row is about is asserted only in the valid branch, which is byte-identical: global and global+link-local replacements still arrive as an exact MP_REACH with the global first and the pair trimmed to 16 octets on this rail, and loopback, scope-confused VPN-shaped and family-invalid replacements still arrive as an exact withdrawal with no MP_REACH, so the polarity pair still discriminates the address role; the label substitution narrows nothing about next-hop admission. RFC 2545 Section 3: "A BGP speaker shall advertise to its peer in the Network Address of Next Hop field the global IPv6 address of the next hop, potentially followed by the link-local IPv6 address of the next hop." Verdict stands. Rejudged 2026-10-16 (independent reader) after the owner-approved 2026-10-16 change ("5 RFC") to TestRFC4659LinkLocalPeeringPreservesUnspecifiedGlobalPair: the one edit is in the forbidden-next-hop branch, where for the VPN (non-unicast) cases the expected MP_UNREACH_NLRI value now has its Compatibility octets want[4:7] (after AFI, SAFI and NLRI length 0x98) set to 80 00 00 in place of the received label octets 00 01 01. RFC 8277 Section 2.4: "Upon transmission, the Compatibility field SHOULD be set to 0x800000. Upon reception, the value of the Compatibility field MUST be ignored." The withdrawal still names the same RD and prefix and still requires no MP_REACH. This unit's RFC2545-3-1 negative is the "unicast" case (IPv6 unicast, :: global with fe80::1 second): its expected withdrawal is unchanged because the edit is gated on !tc.unicast, so the proof that the VPN exception does not license an unspecified global in IPv6 unicast is untouched. RFC 2545 Section 3: "A BGP speaker shall advertise to its peer in the Network Address of Next Hop field the global IPv6 address of the next hop, potentially followed by the link-local IPv6 address of the next hop." Verdict stands. Rejudged 2026-10-16 (independent reader) after a comment-only edit to TestRFC4659LinkLocalPeeringPreservesUnspecifiedGlobalPair: the comment above the Compatibility substitution now reads "in place of the route's label octets 000101." (correcting "label 010100"); no input byte, expectation or assertion changed, so the judgement above stands. The unit's discrimination record was re-recorded the same day (revert of forward_next_hop.go::egressNextHopWithheld, observed red). Verdict stands. Rejudged 2026-10-17 (independent reader, not the author of 3f6bb1965e) after the owner-approved command-text change in 3f6bb1965e (injection grammar: nlri <family> became mp <family> for MP families and bare nlri for IPv4 unicast): the only changed carrier is test/encode/new-v6.ci, whose three cmd=api lines now read mp ipv6/unicast add|eor in place of nlri ipv6/unicast; every expect=bgp hex and expect=json line is byte-identical, so MP_REACH_NLRI still carries length 0x10 and the global 2a02:b80:0:2::1 first, and the test still fails if the next-hop field changes. Re-run green 2026-10-17 (./le test bgp encode new-v6). RFC 2545 Section 3: "A BGP speaker shall advertise to its peer in the Network Address of Next Hop field the global IPv6 address of the next hop, potentially followed by the link-local IPv6 address of the next hop." Every other tagged unit is unchanged. Verdict stands.
RFC2545-3-2
The value of the Length of Next Hop Network Address field on a MP_REACH_NLRI attribute shall be set to 16, when only a global address is present, or 32 if a link-local address is also included in the Next Hop field. (§3)
Audit verdict: enforced (the tests do what the requirement demands), stale-unit: internal/component/bgp/reactor/rfc2545_forward_subnet_test.go::TestRFC2545EffectivePairPolicyAndMixedSibling, internal/component/bgp/reactor/rfc2545_forward_subnet_test.go::TestRFC2545EffectivePairPolicyAndMixedSibling#2 moved. Re-judged 2026-10-12 (independent auditor) after owner-approved lint-only edits in 96ec49327b and 4e731b2d96; the row text is unchanged and each changed unit was re-read diff by diff. srpolicy subtests gained t.Parallel (each subtest builds its own UPDATE, no shared state); reactor units drop redundant AFI/SAFI conversions and newDefaultOriginatePeer takes the same local and link-local addresses from constants. No input byte, address or assertion changed. Verdict stands. Independently rejudged against RFC2545 Section 3's length 16 for a global alone and 32 when the link-local is included; direct construction writes the selected 16/32 length and corresponding ordered bytes, and replay reconstructs the entire NextHopHex field rather than reducing it to one address; current compatibility and live/stored replay fixtures assert literal complete wire encodings including length 0x20, while global-only and invalid-width controls in the existing writer/policy composition prevent an arbitrary legal-looking address or malformed width from satisfying the rule; the changed checkRFC2545NextHops uses the actual selected IPv6 session and topology-owned Ze global/link-local, requires exact decoded one-versus-two address shapes for off-link/on-link routes, and separately reads route installation, not dataplane forwarding; the strengthened topology does not weaken any width assertion; mapped single fields, standalone negotiated link-local and RD-bearing VPN fields remain explicitly separate family/draft contracts; current native bindings and Main-observed functional evidence complement the source judgment rather than deriving it from passing names Rejudged 2026-10-12 after commit ce62c78c3b moved peer_initial_sync_test.go around these units: the tagged functions there were re-read and are byte-identical, their assertions and fixtures still carry the evidence this note cites, and the other cited units did not change, so the verdict stands. Rejudged 2026-10-12 after 7a637d6df5 renamed SendUpdateHeld to sendUpdateHeld in two comments of peer_initial_sync_test.go: every tagged unit cited here is byte-identical (gate-verified), the comment edits sit outside them, and the assertions and fixtures still carry the evidence this note cites, so the verdict stands. Rejudged 2026-10-15 after 34fc08f0d4 changed checkRFC2545NextHops: the one edit replaces rfc2545LinkLocal(check.Network) with linkLocalAt(check.Network, zeHostNumber); both build fe80:: plus the scenario prefix with last octet 2 (zeHostNumber = 2, prepare.go), so the expected link-local, every decoded one-versus-two address shape and every assertion are unchanged, and TestRFC2545ScenarioPreparesAsBefore pins the rendered scenario. RFC 2545 Section 3: "The value of the Length of Next Hop Network Address field on a MP_REACH_NLRI attribute shall be set to 16, when only a global address is present, or 32 if a link-local address is also included in the Next Hop field." and "The link-local address shall be included in the Next Hop field if and only if the BGP speaker shares a common subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to." Verdict stands. Rejudged 2026-10-16 (independent reader) after the owner-approved 2026-10-16 change ("5 RFC") to TestFamilyNextHopForwardAdmission: the one edit is in the refused-next-hop branch, where the expected MP_UNREACH_NLRI now carries the Compatibility 0x800000 in its 3 label octets for SAFI 4 and 128. RFC 8277 Section 2.4: "Upon transmission, the Compatibility field SHOULD be set to 0x800000. Upon reception, the value of the Compatibility field MUST be ignored." The valid branch, which asserts the Length of Next Hop Network Address octet (byte(len(wantHop))) and the exact next-hop bytes in MP_REACH, is byte-identical, and the refused branch still requires no MP_REACH at all, so the width evidence this unit contributes is unchanged. RFC 2545 Section 3: "The value of the Length of Next Hop Network Address field on a MP_REACH_NLRI attribute shall be set to 16, when only a global address is present, or 32 if a link-local address is also included in the Next Hop field." Verdict stands. Rejudged 2026-10-17 (independent reader, not the author of 3f6bb1965e) after the owner-approved command-text change in 3f6bb1965e (injection grammar: nlri <family> became mp <family> for MP families and bare nlri for IPv4 unicast): the only changed carrier is test/encode/new-v6.ci, whose cmd=api lines changed spelling only; the expected UPDATE hex is byte-identical and still pins the Length of Next Hop Network Address octet 0x10 for a global-only next hop. Re-run green 2026-10-17. RFC 2545 Section 3: "The value of the Length of Next Hop Network Address field on a MP_REACH_NLRI attribute shall be set to 16, when only a global address is present, or 32 if a link-local address is also included in the Next Hop field." Every other tagged unit is unchanged. Verdict stands.
| Polarity | Test | Kind and tier | Proof state |
|---|---|---|---|
| negative | TestFamilyNextHopForwardAdmission |
unit/verify | revert, verified |
| negative | TestFamilyNextHopOriginationAdmission |
unit/verify | revert, verified |
| negative | TestSessionSendAnnounceRefusesNonLinkLocalSecondAddress |
unit/verify | revert, verified |
| negative | TestAPIBatchRefusesUnusableIPv6NextHop |
unit/verify | revert, verified |
| negative | TestNamedCommitRefusesUnusableIPv6NextHop |
unit/verify | revert, verified |
| negative | TestOriginatedIPv6NextHopAdmissionAfterExportPolicy |
unit/verify | revert, verified |
| negative | TestQueuedOriginateRefusesUnusableIPv6NextHop |
unit/verify | revert, verified |
| negative | TestRFC2545EffectivePairPolicyAndMixedSibling |
unit/verify | revert, verified |
| negative | new-v6.ci |
functional/verify | unproven |
| positive | TestSRPolicyConfigNextHopWire |
unit/verify | revert, verified |
| positive | TestSRPolicyEncodeNextHopWire |
unit/verify | revert, verified |
| positive | TestFamilyNextHopForwardAdmission |
unit/verify | revert, verified |
| positive | TestFamilyNextHopOriginationAdmission |
unit/verify | revert, verified |
| positive | TestDefaultOriginateAppendsLinkLocalWhenSection3Holds |
unit/verify | revert, verified |
| positive | TestStaticGroupedResolvedNextHopWire |
unit/verify | revert, verified |
| positive | TestSessionSendAnnounceAcceptsLinkLocalSecondAddress |
unit/verify | revert, verified |
| positive | TestAPIBatchRefusesUnusableIPv6NextHop |
unit/verify | revert, verified |
| positive | TestNamedCommitRefusesUnusableIPv6NextHop |
unit/verify | revert, verified |
| positive | TestOriginatedIPv6NextHopAdmissionAfterExportPolicy |
unit/verify | revert, verified |
| positive | TestQueuedOriginateRefusesUnusableIPv6NextHop |
unit/verify | revert, verified |
| positive | TestRFC2545EffectivePairPolicyAndMixedSibling |
unit/verify | revert, verified |
| positive | TestSendAnnounceAppendsLinkLocalWhenSection3Holds |
unit/verify | revert, verified |
| positive | checkRFC2545NextHops |
interop/nightly | revert, verified |
| positive | conf-llnh-update.ci |
functional/verify | revert, verified |
| positive | adj-rib-in-replay-rfc2545-next-hop.ci |
functional/verify | revert, verified |
RFC2545-3-3
The link-local address shall be included in the Next Hop field if and only if the BGP speaker shares a common subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to. (§3)
Scoped tag-claim records only: tested "only if the BGP speaker shares a common subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to."; gap "The link-local address shall be included in the Next Hop field if"; internal/component/bgp/reactor/link_scope.go::linkLocalNextHop is the missing-address boundary: Tested covers exclusion outside one common subnet, with conforming inclusion controls where the effective next-hop entity's link-local is already available from a supplied pair or configured speaker-owned address; current configured/default/direct/static, ordinary API/queued/commit and post-policy forwarding paths implement those cases, and stored replay retains supplied pairs; Gap is the remaining sufficient-condition obligation for an externally advertised third-party next hop on the common subnet when only its global address is supplied, because classify identifies another router and this producer has no source for that router's link-local; the speaker's own link-local must not be substituted; conforming controls and the separate RFC2545-3-6 disclosure do not discharge that missing include case, and no discovery or liveness feature is implied; zero whole-requirement credit.
Audit verdict: partial (the tests enforce only the declared tested scope; the whole requirement remains unmet), stale-unit: internal/component/bgp/reactor/link_scope.go::linkLocalNextHop moved. Re-judged 2026-10-15 (subagent, after 34fc08f0d4). RFC 2545 Section 3: "The link-local address shall be included in the Next Hop field if and only if the BGP speaker shares a common subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to." checkRFC2545NextHops changed in one line: rfc2545LinkLocal(check.Network) became linkLocalAt(check.Network, zeHostNumber), and zeHostNumber is 2, the host octet the deleted builder hard-coded, so the expected fe80:: address and every fail(N) assertion are unchanged. Tested/Gap/Producer scope untouched. The prior judgement stands: Re-judged 2026-10-12 (independent auditor) after owner-approved lint-only edits in 96ec49327b and 4e731b2d96; the row text is unchanged and each changed unit was re-read diff by diff. TestRFC2545JointSubnetWriter builds the global+fe80::9 pair with slices.Concat instead of a capped append (same 32 octets); the default-originate units take the same local and link-local addresses from constants. No assertion changed, and the Tested/Gap/Producer scope is untouched; the four 3-3 discrimination records were re-observed in 4e731b2d96. Verdict stands. Tested is 'only if the BGP speaker shares a common subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to.'; Gap is 'The link-local address shall be included in the Next Hop field if'; these locators distinguish the necessary-condition exclusion side from the incompletely implemented sufficient-condition inclusion side, with actual scope bounded by the annotation's explanation; omission outside one joint connected prefix and conforming inclusion where the next-hop entity's link-local is supplied or configured are enforced by the inspected default/direct, received-pair, joint-subnet, ordinary batch/queued/commit, compatibility, native-topology and independent FRR carriers; TestRFC2545ForwardPolicyOwnGlobalJointSubnet adds the repaired effective speaker-owned global case on cached/RS, Auto/Unchanged and operation/raw-policy fallback, with exact fields, unchanged sibling and one policy call; the actual public SDK old/final receipt records old failure and final success without substituting an internal seam for the daemon workflow; Producer internal/component/bgp/reactor/link_scope.go::linkLocalNextHop still returns no second address for ThirdParty because no source for that entity's link-local exists when only its global is supplied on the common subnet, so the whole sentence earns no enforced credit; retained positive and negative native producer-break records cover the declared implemented population, and the missing third-party source is not silently implemented or excused by RFC2545-3-6 Rejudged 2026-10-12 after commit ce62c78c3b moved peer_initial_sync_test.go around these units: the tagged functions there were re-read and are byte-identical, their assertions and fixtures still carry the evidence this note cites, and the other cited units did not change, so the verdict stands. Rejudged 2026-10-12 after 7a637d6df5 renamed SendUpdateHeld to sendUpdateHeld in two comments of peer_initial_sync_test.go: every tagged unit cited here is byte-identical (gate-verified), the comment edits sit outside them, and the assertions and fixtures still carry the evidence this note cites, so the verdict stands.
| Polarity | Test | Kind and tier | Proof state |
|---|---|---|---|
| negative | TestDefaultOriginateOmitsLinkLocalWhenPeerOffLink |
unit/verify | revert, verified |
| negative | TestRFC2545ReceivedPairSubnetConditions |
unit/verify | revert, verified |
| negative | TestRFC2545JointSubnetWriter |
unit/verify | revert, verified |
| negative | TestOrdinaryIPv6PolicyPairJointSubnet |
unit/verify | revert, verified |
| negative | TestSendAnnounceOmitsLinkLocalWhenPeerOffLink |
unit/verify | revert, verified |
| negative | TestRFC2545StaticLabeledIPv6LinkLocalCommonSubnet |
unit/verify | revert, verified |
| negative | checkRFC2545NextHops |
interop/nightly | revert, verified |
| negative | conf-llnh-lla-only.ci |
functional/verify | revert, verified |
| negative | rfc2545-joint-subnet.ci |
functional/verify | revert, verified |
| positive | TestDefaultOriginateAppendsLinkLocalWhenSection3Holds |
unit/verify | revert, verified |
| positive | TestRFC2545ForwardPolicyOwnGlobalJointSubnet |
unit/verify | revert, verified |
| positive | TestRFC2545ReceivedPairSubnetConditions |
unit/verify | revert, verified |
| positive | TestRFC2545JointSubnetWriter |
unit/verify | revert, verified |
| positive | TestOrdinaryIPv6OwnGlobalJointSubnet |
unit/verify | revert, verified |
| positive | TestSendAnnounceAppendsLinkLocalWhenSection3Holds |
unit/verify | revert, verified |
| positive | TestRFC2545StaticLabeledIPv6LinkLocalCommonSubnet |
unit/verify | revert, verified |
| positive | checkRFC2545NextHops |
interop/nightly | revert, verified |
| positive | conf-llnh-update.ci |
functional/verify | revert, verified |
| positive | rfc2545-joint-subnet.ci |
functional/verify | revert, verified |
RFC2545-3-6
The link-local address shall be included in the Next Hop field if and only if the BGP speaker shares a common subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to. (§3)
Audit verdict: unimplemented (no code path enforces the requirement), stale-unit: internal/component/bgp/reactor/link_scope.go::linkLocalNextHop moved. Independently rejudged against the complete RFC2545 Section 3 inclusion sentence and its requirement that the second address belong to the next-hop entity; the changed linkLocalNextHop comment correctly distinguishes an unavailable address from proof that the common-subnet condition is false, and its current body still returns no address for nextHopRouterThirdParty; classify recognizes only connected/configured/held speaker addresses as Speaker and otherwise identifies ThirdParty; therefore configured/static/API origination or an explicit rewrite naming another on-link router solely by its global address cannot supply that router's required link-local, and substituting the speaker's own would be wrong; received complete pairs and the repaired post-policy speaker-owned-global inclusion have real address sources and remain outside this absent-source gap; their successful tests and SDK workflow do not implement third-party discovery; retain the explicit no-test gap and Partial public support
No test carries RFC2545-3-6, so no unit is bound to it.
RFC2545-3-4
In all other cases a BGP speaker shall advertise to its peer in the Network Address field only the global IPv6 address of the next hop (the value of the Length of Network Address of Next Hop field shall be set to 16). (§3)
Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-12 (independent auditor) after owner-approved lint-only edits in 96ec49327b and 4e731b2d96; the row text is unchanged and each changed unit was re-read diff by diff. TestRFC2545JointSubnetWriter builds the same 32-octet pair with slices.Concat; TestDefaultOriginateOmitsLinkLocalWhenPeerOffLink takes the same local and link-local addresses from constants. No assertion changed. Verdict stands. RFC2545 Section 3 requires only the global IPv6 address, with next-hop length 16, in all other cases; sharesNextHopSubnet now requires one connected prefix containing recipient and effective global, so separate memberships in different local prefixes cannot license a pair; configured/default/direct/static writers, ordinary batch/queued/commit normalization, and applyEgressNextHopScope on cached and RS forwarding preserve the global and native NLRI while excluding the link-local outside that joint condition, and stored replay carries the complete supplied field into the same forwarding core; the inspected carriers assert exact address fields and unchanged reachability, with common-link positives retaining the pair and split-link/entity-off-link/recipient-off-link controls producing global-only output; TestRFC2545ForwardPolicyOwnGlobalJointSubnet additionally drives both forwarding rails, Auto/Unchanged and operation/raw-policy fallback, checking required own-pair inclusion on the common link, global-only output off-link, an unchanged independent legacy sibling and one policy invocation; Main's observed broad and final-guard race20 runs and real public raw-export SDK old/final workflow establish this current carrier, complementing the previously accepted distinct-namespace matrix80, replay80, restored FRR same/split complete captures and repaired Docker/compatibility evidence; the missing third-party link-local source belongs to the inclusion branch, not this otherwise obligation; capability-77 standalone link-local and RFC4659 VPN forms retain their separate contracts; no new run or canonical-record freshness is claimed by the reviewer Rejudged 2026-10-12 after commit ce62c78c3b moved peer_initial_sync_test.go around these units: the tagged functions there were re-read and are byte-identical, their assertions and fixtures still carry the evidence this note cites, and the other cited units did not change, so the verdict stands. Rejudged 2026-10-12 after 7a637d6df5 renamed SendUpdateHeld to sendUpdateHeld in two comments of peer_initial_sync_test.go: every tagged unit cited here is byte-identical (gate-verified), the comment edits sit outside them, and the assertions and fixtures still carry the evidence this note cites, so the verdict stands. Rejudged 2026-10-17 (independent reader, not the author of 3f6bb1965e) after the owner-approved command-text change in 3f6bb1965e (injection grammar: nlri <family> became mp <family> for MP families and bare nlri for IPv4 unicast): the only changed carrier is test/encode/new-v6.ci, whose cmd=api lines changed spelling only; the expected UPDATE hex is byte-identical and still requires the global address alone with length 16 toward a peer that shares no subnet with the next hop. Re-run green 2026-10-17. RFC 2545 Section 3: "In all other cases a BGP speaker shall advertise to its peer in the Network Address field only the global IPv6 address of the next hop (the value of the Length of Network Address of Next Hop field shall be set to 16)." Every other tagged unit is unchanged. Verdict stands.
| Polarity | Test | Kind and tier | Proof state |
|---|---|---|---|
| negative | TestRFC2545ForwardPolicyOwnGlobalJointSubnet |
unit/verify | revert, verified |
| negative | TestRFC2545JointSubnetWriter |
unit/verify | revert, verified |
| negative | TestOrdinaryIPv6OwnGlobalJointSubnet |
unit/verify | revert, verified |
| negative | conf-llnh-update.ci |
functional/verify | revert, verified |
| negative | rfc2545-joint-subnet.ci |
functional/verify | revert, verified |
| positive | TestDefaultOriginateOmitsLinkLocalWhenPeerOffLink |
unit/verify | revert, verified |
| positive | TestRFC2545JointSubnetWriter |
unit/verify | revert, verified |
| positive | TestOrdinaryIPv6PolicyPairJointSubnet |
unit/verify | revert, verified |
| positive | TestSendAnnounceOmitsLinkLocalWhenPeerOffLink |
unit/verify | revert, verified |
| positive | new-v6.ci |
functional/verify | unproven |
| positive | rfc2545-joint-subnet.ci |
functional/verify | revert, verified |
Extraction sign-off
| Field | Value |
|---|---|
| Reviewer | ze-rfc phase agent, deferral fixit-stored-route-relay-hardening (rfc2545 enrolment) |
| Signed off | 2026-08-07 |
| Register | prose |
| Source | rfc/full/rfc2545.txt |
| Source fingerprint | 80e7f63fb7ad995a |
| Record | rfc/extraction/rfc2545.json |
| Mapped sentences | 5 |
| Declined as scope | 5 |
| Relocated to a spec, which Ze OWES | 0 |
| Unclassified | 0 |
Sections
| Section | Name | Sites | Disposition | Reason |
|---|---|---|---|---|
front |
not stated | 0 | skipped (front-matter) | Title block, Status of this Memo, copyright notice and Abstract. The Abstract states what the document defines and binds no speaker. |
1 |
Introduction | 1 | walked | Introduction. States that the BGP-4 procedures apply unchanged unless this document says otherwise, and that the document concerns itself with IPv6 address scope. Its one site describes what the IPv6 addressing architecture defines and is excluded below. |
2 |
IPv6 Address Scopes | 2 | walked | IPv6 Address Scopes. Defines the terms 'global' and 'non-link-local' for this document, and explains why a Next Hop field sometimes carries two addresses. It states no rule for building that field; every such rule is in section 3. Its two sites bind a network administrator and an IPv6 router's neighbour-discovery behaviour, and both are excluded below. |
3 |
Constructing the Next Hop field | 4 | walked | Constructing the Next Hop field. The only section that binds a BGP speaker. All four sites are mapped, one per requirement, to RFC2545-3-1 through RFC2545-3-4. The section's fifth sentence is the MAY captured as RFC2545-3-5; 'may' is not a derived site under either scan, which is why the site count is four rather than five. RFC2545-3-6 (2026-10-01, rfc/corrections/rfc2545.md) is split from RFC2545-3-3 and quotes the same sentence as site 3:3: it carries the third-party include half as a recorded gap, so it is listed here as unsourced rather than given a second site. |
4 |
Transport | 2 | walked | Transport. Explains that BGP-4 runs over IPv4 or IPv6 and reads implicit configuration from the session address, then separates that address from the BGP Identifier. Site 4:1 binds the operator who configures the session. Site 4:2 is the source of RFC2545-4-1 and is mapped to it. |
5 |
Security Considerations | 0 | walked | Security Considerations. One sentence: carrying IPv6 reachability raises no new security issue beyond those of BGP-4 with IPv4. No countermeasure is directed at a speaker. |
6 |
Acknowledgments | 0 | skipped (acknowledgements) | Acknowledgments. Credits the authors of the BGP-4 Multiprotocol Extensions work. |
7 |
not stated | 0 | skipped (references) | References: RFC 2373, RFC 1771, RFC 2283, RFC 2460, RFC 2461, RFC 2080. |
8 |
Author Information | 0 | walked | Author Information. Postal addresses, telephone numbers and e-mail addresses for the two authors. No obligation. |
9 |
Full Copyright Statement | 1 | walked | Full Copyright Statement. The Internet Society boilerplate governing copying and translation of the document. Its one site is a condition on republishing the text and is excluded below. |
Excluded sentences
| Site | Excluded kind | Reason | Quote |
|---|---|---|---|
1:1 |
not-a-requirementnever bound Ze the sentence states a fact or describes another document, and directs no implementation |
A description of another document, in the Introduction. The subject of 'must' is IPv6 itself: the sentence reports that the IPv6 addressing architecture [ADDR-ARCH] defines situations calling for a given scope. It directs no BGP speaker and states no rule this document adds. The rules this document does add begin at section 3. | In terms of routing information, the most significant difference between IPv6 and IPv4 (for which BGP was originally designed) is the fact that IPv6 introduces scoped unicast addresses and defines particular situations when a particular address scope must be used. |
2:1 |
binds-another-rolenever bound Ze the obligation is addressed to a role Ze never acts as Presumed wrong until justified: Ze rarely implements one side of a protocol, so the reason beside this row must name the role, show Ze never acts as it, and cite the producer that would. |
The role is the network administrator, named as the subject of the sentence. The obligation is to respect address scope restrictions when planning a deployment, and the awareness clause is about how a person reasons about routing domains against sites. Neither is an act a BGP implementation performs; the sentence exists because section 2 has just declared that the document itself makes no distinction between global and site-local addresses, and it hands the distinction back to the operator. The role is the AS operator, so no producer could act as it. Ze CONSUMES the operator's decision: the capability is negotiated per session in the reactor (`internal/component/bgp/reactor`), which advertises what it is configured to and decides no AS-wide policy. | Network administrators must however respect address scope restrictions and should be aware that the concepts of a BGP-4 routing domain and "site" are orthogonal notions and that they may or may not coincide in a given situation. |
2:2 |
cross-documentnever bound Ze the obligation belongs to another document that this one only cites |
The sentence opens with 'This restrictions does imply', referring to the restrictions of the two documents cited immediately above it: [ND] (RFC 2461), which permits only a link-local address when generating ICMP Redirect messages, and [RIP] (RFC 2080), which permits only a link-local address as a RIPng next hop. The obligation to hold a link-local next hop for a directly connected route is theirs, and it binds the IPv6 neighbour-discovery and interior-routing layers rather than the BGP-4 Next Hop field. RFC 2545 draws the consequence to motivate section 3, and adds no obligation of its own here. | This restrictions does imply that an IPv6 router must have a link- local next hop address for all directly connected routes (routes for which the given router and the next hop router share a common subnet prefix). |
4:1 |
binds-another-rolenever bound Ze the obligation is addressed to a role Ze never acts as Presumed wrong until justified: Ze rarely implements one side of a protocol, so the reason beside this row must name the role, show Ze never acts as it, and cite the producer that would. |
The role is the operator who configures the session. The sentence draws a consequence of the two before it: BGP-4 reads the peer's network address implicitly from the address that established the session, and the route dissemination procedure uses it, so an IPv4 transport carrying IPv6 reachability leaves that address undetermined and somebody has to supply it. What is required is a configuration act, not a wire behaviour or a decision procedure, and the sentence names no message, field or timer for a speaker to get right. The role is the AS operator, so no producer could act as it. Ze CONSUMES the operator's decision: the capability is negotiated per session in the reactor (`internal/component/bgp/reactor`), which advertises what it is configured to and decides no AS-wide policy. | Thus, when using TCP over IPv4 as a transport for IPv6 reachability information, additional explicit configuration of the peer's network address is required. |
9:1 |
not-a-requirementnever bound Ze the sentence states a fact or describes another document, and directs no implementation |
Internet Society copyright boilerplate that the site scanner did not strip. The 'must' governs the procedures for republishing or translating the document text, and binds a publisher of the document rather than an implementation of the protocol it specifies. | However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. |
Superseded
No document obsoletes RFC 2545, so its obligations are stated where they were written.