a positive test proves Ze does what the requirement demands and a negative one proves it refuses what the requirement forbids
RFC 1997 - BGP Communities Attribute
Every requirement this repository extracted from RFC 1997, 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
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
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
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 | ok | green at zero, RED above it: a tested clause cannot prove the whole requirement |
| No test at all | ok | 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 | warn | 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 | Supported |
| Enrolment | Enrolled |
| Requirements | 9 |
| Gated MUST-level | 5 |
| Not applicable, so out of scope | 0 |
| Declared gaps | 0 |
| Declared gaps a test demonstrates | 0 |
| Gated with no test | 0 |
| Nightly-only evidence | 0 |
| Test tags | 26 |
| Tagged units | 26 |
| Recorded audit verdicts | 5 |
| Discrimination records | 8 |
| Summary | rfc/short/rfc1997.md |
| Requirement shard | rfc/requirements/rfc1997.md |
| RFC text | rfc/full/rfc1997.txt |
Enrolment
Enrolled: BGP Communities: five MUST-level requirements. RFC1997-Encoding-1 (attribute length a multiple of 4) is enforced on the wire-decode path by ParseCommunities (internal/core/bgp/attribute/community.go:201, wired via wire.go knownAttrParsers); the positive/negative pair proves a valid multiple-of-4 parses into length/4 communities while a non-multiple-of-4 is rejected as malformed (ErrInvalidLength). The three egress MUST-NOTs (Well-1 NO_EXPORT, Well-2 NO_ADVERTISE, Well-3 NO_EXPORT_SUBCONFED) and the Well-4 SHALL are enforced automatically, with no operator policy involved: wireu.ScanWellKnown reads the RECEIVED payload once per UPDATE and WellKnown.AllowsEgressTo (internal/component/bgp/wireu/wellknown.go) decides per destination, asked by both forward rails through Reactor.wellKnownAllowsEgress (internal/component/bgp/reactor/forward_wellknown.go). The word "received" in each clause is load-bearing and bounds the check: a route Ze ORIGINATES carrying NO_EXPORT is using the community for its purpose and is still advertised (test/interop/scenarios/as112-community-frr). The confederation boundary is the AS boundary because Ze configures no confederation, which is what the NO_EXPORT clause itself directs for "a stand-alone autonomous system that is not part of a confederation". Proof runs at three tiers: unit pairs over the decision and both rails, test/plugin/wellknown-no-export-egress.ci and wellknown-no-advertise-egress.ci over a running daemon's wire in the verify tier, and test/interop/scenarios/bgp-wellknown-noexport-frr with FRR (external, must not learn it) and BIRD (internal, must) as independent observers.
What the public ledger says
Status: Supported
What the ledger says is covered
- COMMUNITY attribute parsing (multiple-of-4 length enforced), encoding, JSON, well-known names, operator community-match policy, and the well-known egress operations. A route received carrying NO_EXPORT or NO_EXPORT_SUBCONFED is withheld from every external peer, and one carrying NO_ADVERTISE from every peer. The suppression is automatic and needs no operator policy
- it is counted by
ze_bgp_wellknown_community_suppressed_total. Ze configures no confederation, so the confederation boundary is the AS boundary, which is what RFC 1997 says to do for "a stand-alone autonomous system that is not part of a confederation".
What the ledger says remains:
Gated per requirement inrfc/short/rfc1997.md via ./le rfc check.
Coverage
| Bucket | Count | What it counts |
|---|---|---|
| Positive and negative tests | 5 | one part of the gated population |
| Annotated (including scoped evidence) | 0 | 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) | 0 | 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 (5): RFC1997-Well-1, RFC1997-Well-2, RFC1997-Well-3, RFC1997-Encoding-1, RFC1997-Well-4
Requirements
| Requirement | Level | Section | Tests |
|---|---|---|---|
RFC1997-Well-1 | NO_EXPORT (0xFFFFFF01) All routes received carrying a communities attribute containing this value MUST NOT be advertised outside a BGP confederation boundary (a stand-alone autonomous system that is not part of a confederation should be considered a confederation itself). (§Well-known Communities) | ||
| MUST NOT | Well | ||
RFC1997-Well-2 | NO_ADVERTISE (0xFFFFFF02) All routes received carrying a communities attribute containing this value MUST NOT be advertised to other BGP peers. (§Well-known Communities) | ||
| MUST NOT | Well | ||
RFC1997-Well-3 | NO_EXPORT_SUBCONFED (0xFFFFFF03) All routes received carrying a communities attribute containing this value MUST NOT be advertised to external BGP peers (this includes peers in other members autonomous systems inside a BGP confederation). (§Well-known Communities) | ||
| MUST NOT | Well | ||
RFC1997-Encoding-1 | The attribute consists of a set of four octet values, each of which specify a community. (§COMMUNITIES attribute) | ||
| MUST | COMMUNITIES | ||
RFC1997-Well-4 | The following communities have global significance and their operations shall be implemented in any community-attribute-aware BGP speaker. (§Well-known Communities) | ||
| SHALL | Well | ||
RFC1997-Aggregation-1 | If a range of routes is to be aggregated and the resultant aggregates attribute section does not carry the ATOMIC_AGGREGATE attribute, then the resulting aggregate should have a COMMUNITIES path attribute which contains all communities from all of the aggregated routes. (§Aggregation) | ||
| SHOULD | Aggregation | positive
no testno positive testnegative
no testno negative test |
|
RFC1997-Operation-1 | A BGP speaker may use this attribute to control which routing information it accepts, prefers or distributes to other neighbors. (§Operation) | ||
| MAY | Operation | positive
no testno positive testnegative
no testno negative test |
|
RFC1997-Operation-2 | A BGP speaker receiving a route that does not have the COMMUNITIES path attribute may append this attribute to the route when propagating it to its peers. (§Operation) | ||
| MAY | Operation | positive
no testno positive testnegative
no testno negative test |
|
RFC1997-Operation-3 | A BGP speaker receiving a route with the COMMUNITIES path attribute may modify this attribute according to the local policy. (§Operation) | ||
| MAY | Operation | positive
no testno positive testnegative
no testno negative test |
|
Gaps and untested MUSTs
RFC 1997 declares no gap, and every gated MUST it carries has a test bound to it.
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.
RFC1997-Well-1
NO_EXPORT (0xFFFFFF01) All routes received carrying a communities attribute containing this value MUST NOT be advertised outside a BGP confederation boundary (a stand-alone autonomous system that is not part of a confederation should be considered a confederation itself). (§Well-known Communities)
Audit verdict: enforced (the tests do what the requirement demands), stale-unit: test/plugin/wellknown-no-export-withdraw-egress.ci moved. RFC 1997, Well-known Communities: “All routes received carrying a communities attribute containing this value MUST NOT be advertised outside a BGP confederation boundary (a stand-alone autonomous system that is not part of a confederation should be considered a confederation itself).” Independently re-read all ten tagged covers and both producing egress rails through final ownership admission. Predicate and forwarding pairs distinguish external suppression from internal permission and ordinary-community forwarding. The changed mixed native carrier uses three independent peer processes: all-EOR readiness releases an ordinary source-owned 198.51.100.0/24 seed, both recipients acknowledge its wire receipt, and a source-only marker releases the mixed NO_EXPORT UPDATE. It requires the original withdrawal externally, withdrawal plus permitted announcement internally, the ordinary fence on both, and no external announcement of never-seeded 10.0.0.0/24. The observer checks seeded route-message counts 4/3. The producer retains ordinary ownership for original withdrawals and distinct absent-owner handling for synthesized refused announcements. Scope is the supported stand-alone-AS boundary, not an invented confederation-member implementation or a universal prohibition on all confederation eBGP sessions. Renewed producer-halt records demonstrate reachability, not selective community-decision discrimination.
| Polarity | Test | Kind and tier | Proof state |
|---|---|---|---|
| negative | TestForwardNoExportStillWithdrawsFromExternalPeer |
unit/verify | revert, verified |
| negative | TestForwardWithoutNoExportReachesExternalPeer |
unit/verify | unproven |
| negative | TestWellKnownNoExportAllowsInternalPeer |
unit/verify | unproven |
| negative | checkSelfNextHopWithheld |
interop/nightly | unproven |
| negative | wellknown-no-export-egress.ci |
functional/verify | revert, verified |
| negative | wellknown-no-export-withdraw-egress.ci |
functional/verify | revert, verified |
| positive | TestForwardNoExportSkipsExternalPeerOnly |
unit/verify | unproven |
| positive | TestWellKnownNoExportRefusesExternalPeer |
unit/verify | unproven |
| positive | checkSelfNextHopWithheld |
interop/nightly | unproven |
| positive | wellknown-no-export-egress.ci |
functional/verify | revert, verified |
RFC1997-Well-2
NO_ADVERTISE (0xFFFFFF02) All routes received carrying a communities attribute containing this value MUST NOT be advertised to other BGP peers. (§Well-known Communities)
Audit verdict: enforced (the tests do what the requirement demands), fresh. Independent source rejudgment. RFC 1997, Well-known Communities, NO_ADVERTISE: 'All routes received carrying a communities attribute containing this value MUST NOT be advertised to other BGP peers.' All 3 positive and 2 negative tagged covers were read. Q1: both internal and external announcements are forbidden, not withdrawals. Q2: internal/component/bgp/wireu/rfc1997_wellknown_test.go TestWellKnownNoAdvertiseRefusesEveryPeer checks false for both peer types; TestWellKnownNoAdvertiseAbsentAdvertisesToEveryPeer checks true for both with an ordinary community. internal/component/bgp/reactor/rfc1997_forward_wellknown_test.go TestForwardNoAdvertiseSkipsEveryPeer checks the announced-destination set, not all UPDATE delivery. test/plugin/wellknown-no-advertise-egress.ci requires 180A0100 withdrawn at BOTH destinations and rejects it only in announced fields (lines 46/52 and 60/65); the ordinary-community fence is positively announced on both sessions (50/63). A rule that leaks, loses withdrawals, or forwards nothing cannot satisfy this combination. Q3: the source supplies valid, separate well-known-community routes followed by a fence; distinct prefixes separate NO_ADVERTISE from NO_EXPORT_SUBCONFED. internal/test/fixture/plugin_fixture_16.go plugin16WellknownCounts quiesces and checks exact outgoing counts; counts are synchronization controls, not the normative assertion, which remains in peer field-scoped expectations/rejections. Q4: 'other BGP peers' is unqualified and both peer classes are covered; no confederation exception is invented. Producers: internal/component/bgp/wireu/wellknown.go ScanWellKnown/AllowsEgressTo and internal/component/bgp/reactor/reactor_api_forward.go suppression-to-withdrawal path with forward_build.go buildWithdrawalPayload. internal/test/peer/checker_update_fields.go separates legacy/MP announcement and withdrawal fields; checker_update_fields_test.go includes real inbound and linger negative-consumer regressions. No newly identified semantic gap within the historical capability scope. Source verdict only, not a claim that this worker executed or renewed runtime proof.
| Polarity | Test | Kind and tier | Proof state |
|---|---|---|---|
| negative | TestWellKnownNoAdvertiseAbsentAdvertisesToEveryPeer |
unit/verify | unproven |
| negative | wellknown-no-advertise-egress.ci |
functional/verify | revert, verified |
| positive | TestForwardNoAdvertiseSkipsEveryPeer |
unit/verify | unproven |
| positive | TestWellKnownNoAdvertiseRefusesEveryPeer |
unit/verify | unproven |
| positive | wellknown-no-advertise-egress.ci |
functional/verify | revert, verified |
RFC1997-Well-3
NO_EXPORT_SUBCONFED (0xFFFFFF03) All routes received carrying a communities attribute containing this value MUST NOT be advertised to external BGP peers (this includes peers in other members autonomous systems inside a BGP confederation). (§Well-known Communities)
Audit verdict: enforced (the tests do what the requirement demands), fresh. Independent source rejudgment. RFC 1997, Well-known Communities, NO_EXPORT_SUBCONFED: 'All routes received carrying a communities attribute containing this value MUST NOT be advertised to external BGP peers (this includes peers in other members autonomous systems inside a BGP confederation).' All 3 positive and 2 negative tagged covers were read. Q1: the restriction covers external announcements, with withdrawal delivery still permitted. Q2: internal/component/bgp/wireu/rfc1997_wellknown_test.go TestWellKnownNoExportSubconfedRefusesExternalPeer and TestWellKnownNoExportSubconfedAllowsInternalPeer check opposite predicate outcomes for the same community. internal/component/bgp/reactor/rfc1997_forward_wellknown_test.go TestForwardNoExportSubconfedSkipsExternalPeerOnly requires the internal announced destination and excludes the external one. test/plugin/wellknown-no-advertise-egress.ci requires 180A0200 announced internally (48), requires that prefix withdrawn externally (61), and rejects external announcement (67); the ordinary-community fence must reach both destinations. Missing gate, blanket suppression and withdrawal loss therefore produce different failing assertions rather than interchangeable greens. Q3: the internal allowed-peer control uses the very same received route; separate 180A0100 NO_ADVERTISE input cannot satisfy the 180A0200 assertions. Q4: the parenthesis is retained: a confederation member-AS peer would also be external, but Ze's historical scope has no configurable confederation/member-AS role. No confederation implementation or expanded support is inferred from these tests. Producers: internal/component/bgp/wireu/wellknown.go ScanWellKnown/AllowsEgressTo, internal/component/bgp/reactor/reactor_api_forward.go and forward_build.go buildWithdrawalPayload. The updated peer matcher and its inbound/linger negative-consumer regressions distinguish announcement from withdrawal instead of banning every UPDATE containing the prefix. Source judgment only; parent must supply its actual runtime evidence before stamping.
| Polarity | Test | Kind and tier | Proof state |
|---|---|---|---|
| negative | TestWellKnownNoExportSubconfedAllowsInternalPeer |
unit/verify | unproven |
| negative | wellknown-no-advertise-egress.ci |
functional/verify | revert, verified |
| positive | TestForwardNoExportSubconfedSkipsExternalPeerOnly |
unit/verify | unproven |
| positive | TestWellKnownNoExportSubconfedRefusesExternalPeer |
unit/verify | unproven |
| positive | wellknown-no-advertise-egress.ci |
functional/verify | revert, verified |
RFC1997-Encoding-1
The attribute consists of a set of four octet values, each of which specify a community. (§COMMUNITIES attribute)
Audit verdict: enforced (the tests do what the requirement demands), fresh. (a) a COMMUNITIES value that is not a whole set of four-octet values, e.g. 6 octets, silently truncated to one community; (b) TestCommunitiesParseRejectsNonMultipleOf4 require.ErrorIs ErrInvalidLength on 6 octets goes red. Positive TestCommunitiesParse asserts the exact two four-octet communities decoded from 8 octets.
| Polarity | Test | Kind and tier | Proof state |
|---|---|---|---|
| negative | TestCommunitiesParseRejectsNonMultipleOf4 |
unit/verify | unproven |
| positive | TestCommunitiesParse |
unit/verify | unproven |
RFC1997-Well-4
The following communities have global significance and their operations shall be implemented in any community-attribute-aware BGP speaker. (§Well-known Communities)
Audit verdict: enforced (the tests do what the requirement demands), fresh. First verdict 2026-09-27 (QF-2), row quoted verbatim from the Well-known Communities paragraph. Ze configures no confederation, so the AS boundary is the confederation boundary the sentence's own parenthesis defines. Forbidden: a community-aware speaker that applies the three operations only under operator policy, or not at all. TestWellKnownAllThreeOperationsImplemented asserts all three bits scanned from the wire with no policy and the route refused to both peer kinds; TestForwardWellKnownNeedsNoOperatorPolicy asserts no export filter is configured and the forward set is empty. Negatives: other reserved communities (NOPEER, LLGR_STALE, BLACKHOLE, GRACEFUL_SHUTDOWN) carry no egress prohibition (TestWellKnownIgnoresOtherReservedCommunities, TestForwardOtherReservedCommunitiesReachExternalPeer). Enforced.
| Polarity | Test | Kind and tier | Proof state |
|---|---|---|---|
| negative | TestForwardOtherReservedCommunitiesReachExternalPeer |
unit/verify | unproven |
| negative | TestWellKnownIgnoresOtherReservedCommunities |
unit/verify | unproven |
| positive | TestForwardWellKnownNeedsNoOperatorPolicy |
unit/verify | unproven |
| positive | TestWellKnownAllThreeOperationsImplemented |
unit/verify | unproven |
Extraction sign-off
| Field | Value |
|---|---|
| Reviewer | ze-work agent, spec-rfcgate-6 phase 5, rfc1997 |
| Signed off | 2026-08-31 |
| Register | prose |
| Source | rfc/full/rfc1997.txt |
| Source fingerprint | ea2a9bee2501b9f7 |
| Record | rfc/extraction/rfc1997.json |
| Mapped sentences | 4 |
| Declined as scope | 1 |
| Relocated to a spec, which Ze OWES | 0 |
| Unclassified | 0 |
Sections
| Section | Name | Sites | Disposition | Reason |
|---|---|---|---|---|
front |
The whole document | 5 | walked | The whole document. RFC 1997 carries no numbered section headings, so the derivation returns one section spanning the title block to the References, and a skip of it would hide every gated id behind a skip kind. Walked heading by heading. Status of This Memo, the Abstract and the Introduction are indicative: BGP controls distribution by prefix or AS_PATH today, and this document proposes grouping destinations so a routing decision can also be made on the identity of a group. Terms and Definitions defines a community as a group of destinations sharing a common property and says each autonomous system administrator may define which communities a destination belongs to, which names the role site front:1 binds. Examples is two operational narratives (NSFNET AUP tagging, and filtering the more-specific components of an aggregate) and directs nobody. The COMMUNITIES attribute heading is the wire-format section, written entirely in the indicative: the attribute is optional transitive of variable length, it has Type Code 8, and 'The attribute consists of a set of four octet values, each of which specify a community.' That last sentence is where RFC1997-Encoding-1 is read from, and it is declared unsourced below because no capitalised or lowercase MUST-level keyword states it. The reserved ranges and the AS-in-the-first-two-octets convention follow under 'the following presumptions may be made', and are carried by the Reserved Ranges and Community Value Structure tables of rfc/short/rfc1997.md. Well-known Communities holds four of the five sites and every gated row this summary declares: sites front:2 to front:5, all mapped below. Operation is three lowercase-'may' sentences the site scan does not see, declared unsourced below as RFC1997-Operation-1 to -3. Aggregation is one lowercase-'should' sentence, declared unsourced below as RFC1997-Aggregation-1. Applicability states the attribute may be used with BGP version 2 and all subsequent versions, which is a compatibility fact rather than a directive. Security Considerations is one sentence saying security issues are not discussed in the memo, so it states no countermeasure. Acknowledgments, Authors' Addresses and the References to RFC 1771 and RFC 1965 bind no speaker. |
Excluded sentences
| Site | Excluded kind | Reason | Quote |
|---|---|---|---|
front: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. |
Binds the autonomous system administrator who assigns community values, a role the RFC names itself in Terms and Definitions: 'Each autonomous system administrator may define which communities a destination belongs to.' The sentence sits under 'however for administrative assignment, the following presumptions may be made', and it tells that administrator to draw a value from the range keyed by their own AS number in the first two octets, with the final two octets defined by that AS (the RFC's own example is AS 690 using 0x02B20000 through 0x02B2FFFF). It directs no encoding, decoding or propagation behavior a BGP speaker performs: a speaker carries the 32-bit value the operator configured and never derives it from an AS number, and ParseCommunities in internal/core/bgp/attribute reads each 4-octet value opaquely. The value layout it describes is carried by the Community Value Structure table of rfc/short/rfc1997.md. The lowercase 'shall' is why the site scan sees it only under the prose register. | The rest of the community attribute values shall be encoded using an autonomous system number in the first two octets. |
Superseded
No document obsoletes RFC 1997, so its obligations are stated where they were written.