Summary

  • NO_EXPORT is a standardized community instruction: a community-aware receiver must not advertise the marked route beyond a confederation boundary. It does not authenticate the sender, validate the prefix or remotely control the receiver.
  • The value lives inside an optional transitive attribute that local policy may modify. RFC 8642 documented that similar community-rewrite commands historically erased or preserved well-known values differently across platforms.
  • Trust therefore comes from an evidence chain, not the label: inspect the route sent, received, transformed, selected and advertised at every material boundary, while retaining independent prefix and relationship filters.

Imagine a network originates a more-specific route for traffic engineering at two private interconnections. It wants the neighbor to use that detail locally but not repeat it to the wider Internet. The network attaches NO_EXPORT. The UPDATE crosses the session. The word has left the sender's router, but the intended boundary has not yet become fact.

The receiving router must recognize the community. Its import policy must not erase it accidentally. Internal distribution must preserve the information needed by the eventual egress decision. Every border that could advertise the route must apply the required behavior. If any of those stages differs from the design, the route can escape even though the sender's Adj-RIB-Out shows the correct token.

RFC 1997 created the BGP COMMUNITIES attribute to simplify policy administration. Instead of maintaining every decision only as lists of prefixes and AS paths, an operator could group destinations by a shared property and make routing policy refer to that group. The attribute is optional, transitive and variable in length; each member is a four-octet value.

“Transitive” describes how an unrecognized optional attribute can be carried through BGP. It does not grant permission to export every route carrying it. NO_EXPORT is a well-known value inside that attribute. RFC 1997 says a route containing it must not be advertised outside a BGP confederation boundary. A stand-alone AS counts as its own confederation for this purpose.

The neighboring values draw different boundaries. NO_ADVERTISE means the route must not be advertised to any other BGP peer. NO_EXPORT_SUBCONFED also blocks advertisement to external peers, including peers in other member ASes inside a confederation. These are not poetic names. The IANA registry binds the names to exact values, while RFC 1997 defines the required behavior.

That common vocabulary is the protocol's achievement. The sender does not need to know the receiver's vendor syntax. The receiver does not need a separate email for every marked prefix. Both can refer to one interoperable signal. Yet the signal remains data processed by autonomous systems, not a capability that reaches across the session and disables an export function remotely.

RFC 1997 makes the local boundary explicit. A speaker may use communities to decide what it accepts, prefers or distributes. It may append communities to a route that arrived without them. It may modify received communities according to local policy. The standard says what a well-known value means while preserving the receiver's control of its own routing state.

There is a productive tension here. A community-aware implementation must honor NO_EXPORT, but an autonomous operator can still write a policy that deletes attributes, mishandles a route family or bypasses the expected processing path. A deliberate violation remains possible. More commonly, the failure is ordinary: a generic “set community” action replaces more than the engineer believed it replaced.

RFC 8642 exists because that belief was not portable. On some platforms, a command that set a new community removed all existing communities, including well-known ones. On others it preserved selected well-known values. OpenBGPD's documented behavior did not remove existing communities at all. Configurations that looked equivalent could therefore produce materially different exports.

The lesson is larger than vendor trivia. A configuration statement is a representation of intent interpreted by a particular running implementation. If a route map adds a commercial tag and silently removes NO_EXPORT, the saved configuration can appear reasonable while the route's practical scope changes. Syntax review cannot settle a behavioral dispute that only the resulting advertised route can answer.

RFC 8642 updates the standards contract by requiring future implementations not to create additional divergence and by documenting the existing differences operators must survive. That reduces new ambiguity; it does not retroactively normalize every deployed release, inherited configuration or upgrade path. Migration still needs before-and-after route evidence.

RFC 7454 supplies an operational rule for that evidence. It recommends scrubbing inbound communities in one's own namespace unless the relationship authorizes the sender to use them. It generally advises retaining other received communities and specifically advises against removing NO_EXPORT without reason. Both halves matter.

Blind preservation would allow a customer to invoke private actions merely by guessing a provider's community values. Blind deletion would destroy legitimate scope instructions and downstream signalling. The receiver needs a documented trust boundary: which well-known values retain standardized meaning, which private namespaces a neighbor may set, which values are removed, and which local actions each accepted value can trigger.

NO_EXPORT carries no proof about who first attached it. A downstream network can receive a route that already has the value, add the value itself, or remove it under policy. The community does not sign its history. It does not prove that the origin AS authorized the prefix, that the AS path is truthful or that the relationship owner approved the requested scope.

It also does not solve route leaks as a class. RFC 7908 defines a leak as propagation beyond intended scope, often in violation of policies distributed across several ASes and their pairwise provider, customer or peer relationships. One NO_EXPORT value can state a particular boundary, but many relationship rules are implicit in which learned routes may be sent to which neighbor classes.

A customer that accidentally advertises provider-learned routes to another provider may leak an enormous table without any of those routes carrying NO_EXPORT. A route with correct origin authorization may still leak because origin validity and propagation policy answer different questions. A tag designed for one route's scope cannot replace prefix filters, customer-cone controls or relationship-aware export policy.

RFC 9234 makes the distinction unusually clear. It describes existing leak-prevention practice as operator configuration that marks routes without checking whether both eBGP speakers agree about the relationship. BGP Role capability lets the two ends announce paired roles in OPEN. The optional transitive Only to Customer attribute then records relationship-relevant propagation state so compliant speakers can prevent or detect defined leaks.

That mechanism moves more of the contract into the protocol, but it does not create centralized authority. Roles are configured locally. Compatibility mode can continue when a peer does not advertise the capability. Strict mode can require a matching role and reject a session, but the RFC warns that making this default could keep a session down after a software update. Each operator still decides the acceptable adoption boundary.

OTC also has an honesty limit. RFC 9234 says an on-path AS can remove or change the attribute, just as it can interfere with other unprotected BGP attributes. A stronger machine-readable relationship contract improves prevention and detection among compliant systems; it does not make deliberate mutation cryptographically impossible.

This comparison protects NO_EXPORT from two exaggerations. It is neither useless because compliance is local nor sufficient because its meaning is standardized. Its value is the low cost of expressing a narrow scope. Its limit is that the party receiving the request owns the machinery that turns it into behavior.

The proof should follow that machinery. Begin at the sender with the exact NLRI and address family. Record the intended peer, the route before export policy, the route after export policy and the advertised attribute set. A configuration containing NO_EXPORT is insufficient if a later route-map term removes it or a different policy chain serves the live session.

At the receiver, capture both raw receipt and post-policy state. Confirm that the well-known value is present, that the accepted path belongs to the expected route family and that internal distribution preserves the required metadata. When route reflection, aggregation or redistribution changes the representation, identify which object reaches each egress policy.

Then inspect every relevant Adj-RIB-Out or equivalent advertised-route view. The decisive question is negative but must not be answered from silence at one public collector. A collector sees only the sessions feeding it. Absence at that vantage point may mean correct filtering, route-selection differences, collector policy or no observation at all.

A controlled test uses a bounded prefix and known boundaries. Announce it with and without NO_EXPORT; observe the direct neighbor's received route; inspect candidate egress peers; verify that the route remains usable where intended and absent where prohibited; then withdraw it and confirm cleanup. Repeat across software versions, policy compilers and address families that matter.

Automation should compare route outcomes, not only configuration text. A release check can fail if a protected well-known community disappears after a policy rewrite. A canary can ask route servers or bilateral looking glasses whether the controlled prefix crossed an external boundary. A drift monitor can compare expected and actual outbound attributes. These tests preserve local authority because they measure the operator's own contract instead of outsourcing the decision.

Incident handling needs a bounded local lever. If a route is escaping, the receiving network can apply an explicit outbound prefix filter, restore the community, withdraw the route from selected peers or remove it altogether. Waiting for the original sender to change a tag may leave the damaging border under the wrong party's timetable. The system bearing the propagation risk must keep the immediate ability to stop it.

The sender also has duties. It should attach the value on the actual advertised route, not merely in a planned policy; distinguish NO_EXPORT from NO_ADVERTISE; document whether confederation members are inside the intended scope; and avoid assuming that every peer offers the same private community contract. If containment is essential, it should obtain bilateral confirmation and external observations rather than treat the token as a warranty.

Relationship owners should write the exception path before an outage. Who may request community preservation? Which team may remove a disputed tag? What evidence proves an accidental leak? Does emergency containment favor loss of reachability or continued limited propagation? Which address families and route types are covered? Without those answers, the first serious disagreement becomes an improvised constitutional debate inside a route map.

Heng Lu's minimum-specification principle fits this mechanism. The shared layer supplies a small vocabulary and a precise default boundary. It need not prescribe every network's internal hierarchy, customer contract or change process. Future decisions remain with the operators who bear the cost, while interoperability depends on a clearly stated minimum that each can test.

Running-code primacy supplies the acceptance criterion. The RFC, policy repository and configuration commit all describe the intended system. The route that entered the speaker, the attributes that survived policy and the UPDATE emitted at the border are the system. Where those records disagree, practical authority belongs to the running path.

Data sovereignty in this setting is neither isolation nor freedom to make hidden promises. The sender governs the information it offers. The receiver governs its routing process and is accountable for the exports it emits. Standards make the two decisions legible to each other without pretending that one AS owns the other's router.

The most reliable way to read NO_EXPORT is therefore literal but modest. It is a request with a standardized response expected from compliant speakers. It can reduce coordination cost and prevent unnecessary propagation. It cannot reach into a neighbor and restrain a route by force. The boundary becomes real only when every autonomous control point that matters chooses, implements and proves it.

Sources