Summary

  • BGP's optional-transitive class lets new information cross speakers that do not implement its semantics. If an unaware speaker accepts and re-advertises the path, it must retain the attribute and set Partial. The mark survives later recognition; it cannot be cleared by a subsequent AS.
  • Partial is an epistemic scar, not an integrity control. It does not identify the ignorant hop, authenticate the origin, validate the opaque value, prove universal support or record whether local policy consented to the attribute's meaning.
  • Revised UPDATE error handling can preserve a BGP session while discarding an attribute or treating its routes as withdrawn. Operations must therefore monitor exact received and advertised bytes, error action, RIB outcome and packets—not merely peer state or prefix totals.

At 02:10, a network team tests a new policy attribute between two controlled sites. The originating edge runs the new release. The middle transit router does not recognize the type code. The receiving edge has just been upgraded and does recognize it.

The first UPDATE is syntactically ordinary: flags, type, length, value and an IPv4 prefix. The transit router can frame the attribute but cannot interpret the value. Because the Optional and Transitive bits are set, it accepts the path, preserves the attribute, sets Partial and sends the UPDATE to the receiving edge.

The receiver knows the type. Its decoder finds a value that violates the attribute specification. Following the revised error action for that attribute, it treats the route as withdrawn. The TCP connection remains open. KEEPALIVEs continue. The transit router still holds the route, and its prefix count is unchanged. Only the downstream customer path disappears.

The incident is synthetic; the authority boundary is not. BGP was built to carry some future information through speakers that had never heard of it. That property makes incremental deployment possible. It also means that a router may lawfully transport semantics it cannot validate, and that an upgrade can make a previously harmless opaque object actionable—and rejectable—without any change to the sender or the intermediate network.

Four bits describe four different promises

The Attribute Flags octet begins with four meaningful bits. Optional distinguishes an extension from a well-known attribute that every implementation must recognize. Transitive says whether an unrecognized optional attribute is eligible to cross a BGP boundary. Partial says whether the information in an optional transitive attribute is incomplete. Extended Length chooses a one- or two-octet length field. The remaining low four bits are sent as zero and ignored when received.

Those bits are not interchangeable adjectives. A well-known attribute must be recognized; its Transitive bit is set, but Partial must be zero. An optional non-transitive attribute may be meaningful between selected speakers, yet an unaware receiver quietly ignores it and does not pass it onward. Partial must also be zero in that class.

The special case is optional transitive. RFC 4271 does not require every implementation to understand every such attribute. A path carrying an unrecognized optional-transitive attribute should be accepted. If the path is accepted and advertised onward, the speaker must pass the attribute with it and set Partial to one.

This is a narrow compatibility promise. The router promises byte custody, not semantic understanding. It knows where the attribute begins and ends. It knows the type code and the flags. It can preserve the value as an opaque object. It does not thereby know whether the value is commercially authorized, cryptographically authentic, internally consistent or safe for a future decoder.

Extended Length is equally modest. It says whether the length itself occupies one octet or two. It does not attest that a value of that length satisfies the attribute's internal grammar. A legacy node can preserve a perfectly framed but semantically malformed value because it lacks the decoder that would discover the fault.

Partial is not a trust score

The name invites over-interpretation. Operators sometimes read Partial as if it meant “damaged,” “unverified” or “low confidence.” The protocol definition is more precise and less comforting.

If an unaware speaker propagates an unknown optional-transitive attribute, it sets Partial. If a later speaker recognizes the attribute and receives it with Partial already set, that speaker must not clear the bit. A non-originating speaker that attaches a new optional-transitive attribute also sets Partial. The mark therefore records that complete origin-to-current-hop semantic custody cannot be assumed.

It does not say which AS lacked support. It does not provide an ordered history of recognition. It does not say whether an intermediate speaker changed the value when such updating was permitted. It does not prove that the originating AS was authorized to attach it. It does not reveal whether a route server, confederation member or policy process saw the same bytes.

Most importantly, Partial is not authenticated. A flag inside an UPDATE inherits the trust boundary of the BGP session and the operational chain that delivered it. It is no substitute for origin validation, relationship policy, transport protection, configuration provenance or packet evidence.

The mark is valuable precisely because it refuses a larger claim. It says, in effect, “this object survived a boundary where complete semantic ownership was absent.” That should prompt investigation and scoped policy, not automatic distrust or automatic acceptance.

Recognition can change the result after an upgrade

Unknown is not an eternal property of a type code. It is relative to one implementation, release, address family and active feature set at one moment. The same byte sequence can be opaque on Tuesday and parsed on Wednesday after a software upgrade.

That temporal change matters. While the attribute is unknown, the node may preserve it without examining its internal value. Once recognized, the node applies the attribute specification: allowed flags, length, substructures, semantics and error action. A value that crossed the network for months can suddenly cause attribute discard or treat-as-withdraw when it reaches the first decoder—or when an existing node gains that decoder.

This is not necessarily a regression. The new implementation may be the first component capable of detecting a real malformed object. Nor is it proof that the transit router failed. The unaware router may have met the base protocol exactly. The incident lies in the interaction between incremental deployment, opaque propagation and a newly active semantic boundary.

Upgrade testing must therefore include received routes that carry unknown attributes, not just negotiated capabilities and configuration diffs. The pre-upgrade inventory needs code point, flags, length, value hash, peer, AFI/SAFI, affected NLRI and Partial state. The post-upgrade comparison asks whether the code point became recognized, which validation now runs, what error action follows and which routes changed.

Without that inventory, a route loss after upgrade is misdiagnosed as a generic software failure. With it, the operator can distinguish a decoder defect, a correctly rejected malformed value, an inappropriate containment policy and a sender that violated the attribute contract.

Error handling preserves sessions by narrowing damage

The original BGP-4 error model often reset a session for a malformed UPDATE attribute. That action removed every route learned on the session, including routes unrelated to the offending object. Optional-transitive attributes made the blast radius especially awkward: an unaware speaker could fan an unchecked value toward many downstream routers that did recognize it.

RFC 7606 narrows many failures into three relevant actions. A session reset remains the strongest response. Treat-as-withdraw processes the routes in the offending UPDATE as if they had been withdrawn, removing them from Adj-RIB-In while preserving the session. Attribute discard removes the malformed attribute and continues processing the UPDATE.

These actions are not a simple severity ladder. Attribute discard can be operationally more deceptive than withdrawal. The route remains reachable, but the information that was meant to influence selection or installation is gone. RFC 7606 restricts discard to attributes that do not affect those decisions unless a careful attribute-specific analysis justifies it.

Treat-as-withdraw makes the semantic failure visible as reachability loss, yet conventional monitoring may miss it. The peer remains Established. Hold timers do not expire. Route-refresh capability and KEEPALIVEs say nothing about the absent NLRI. A session dashboard can be entirely green while a customer prefix vanishes.

Flag conflicts also matter. When the Optional or Transitive bits of a recognized attribute contradict its specification, revised handling generally uses treat-as-withdraw unless the attribute's own specification mandates something else. Duplicate MP_REACH_NLRI or MP_UNREACH_NLRI triggers treat-as-withdraw for all routes in the UPDATE while preserving the session. For most other duplicate attributes, later occurrences are discarded and processing continues. When several errors coexist, the strongest applicable action wins.

This is why “supports RFC 7606” is not a complete control. The operator needs the actual error classification, the attribute-specific rule and the resulting route set. A platform can correctly preserve the session and still produce a serious service outage.

The local network still owns containment

The protocol's propagation rule supports extensibility, but deployment is not permissionless inside an operator's network. A production boundary can decide that certain unknown attributes should not cross until their provenance, resource cost and downstream effect are understood.

Current Juniper documentation exposes two materially different controls for unknown optional-transitive attributes. One can drop the attribute while retaining the route. Another can withdraw routes that carry it. Exceptions can preserve selected type codes, and the policy can be scoped globally, by group or by neighbor. The same documentation adds neighbor readback for attributes dropped or causing withdrawal.

Those controls are not universal BGP law, and they should not be copied as a generic hardening switch. Dropping an opaque attribute may keep packets moving while erasing semantics a downstream service requires. Withdrawing every route that carries an unfamiliar code point can turn an incremental deployment into avoidable reachability loss. An overly broad exception can recreate the original exposure.

The correct question is not “allow unknown attributes: yes or no?” It is “which code points may cross which relationship, for which AFI/SAFI, after which evidence, with what action on uncertainty?” The answer can differ for a customer, a route server, an internal reflector, a settlement-free peer and a controlled trial.

Cisco NX-OS documentation illustrates the evidence surface rather than only the policy surface. It can list prefixes carrying unknown or discarded attributes and show the raw flag, type, length and value on a route. That is the granularity an operator needs. A counter saying “unknown attributes seen” cannot distinguish one benign experimental code point from a malformed object attached to hundreds of thousands of routes.

Propagation is custody, not consent

An unaware router that preserves an optional-transitive attribute has not agreed with its semantics. It has honored a forwarding contract for protocol information. Confusing those two acts creates bad commercial and security claims.

Suppose an attribute is intended to express a service class. A transit AS that does not recognize it cannot be assumed to enforce the service, validate the customer entitlement or accept liability for the encoded request. Partial does not turn carriage into assent. The downstream network still applies its own contract and policy.

The same applies to security. Unknown data is not automatically hostile, and assigned data is not automatically safe. An IANA code point gives the object a stable registry identity. It does not prove that every sender followed the defining RFC or that every deployed decoder is free of resource, parsing or logic faults.

Practical data sovereignty appears at this humble layer. A network may not understand the private meaning of the bytes, but it controls whether they enter logs, cross tenants, leave the domain, trigger a route action or remain available for incident review. Opaque is not ownerless.

The custody record should include received and advertised hashes, not only rendered CLI text. Some displays normalize flags, abbreviate values or omit attributes on summary views. A packet capture or loss-aware control-plane collector can preserve the original UPDATE, while pre-policy and post-policy Adj-RIB views show whether the local system retained, altered or removed the object.

A canary must make ignorance observable

Do not test this mechanism by inventing a random attribute in the public routing table. Use a lab, a controlled bilateral environment or the allocation and procedure defined for the actual extension. The canary should be deliberately boring: one peer pair, a small prefix set, known code point, reversible policy and independent packet reachability.

Record four stages. First, the originating UPDATE: exact flags, type, length, value and NLRI. Second, the unaware hop: received bytes, Partial before and after, accepted path and re-advertised bytes. Third, the recognizing hop: decoder version, validation result, error action and resulting Adj-RIB-In. Fourth, the data plane: selected route, FIB next hop and successful or failed probes.

Test at least three values. A valid attribute should survive and produce its documented effect. A syntactically framed but semantically invalid value should trigger the attribute's specified error action. A non-transitive unknown control should be ignored and should not cross the unaware speaker. These cases prove that the test observes classification rather than merely presence.

Then change time. Upgrade the unaware hop so it recognizes the type and repeat the same UPDATE. The result may legitimately change. That transition is the essential rehearsal for production: recognition moves the validation boundary, and the operational contract must move with it.

Rollback needs two independent levers. One removes or corrects the attribute at the sender. The other contains the type at the receiver or boundary without resetting unrelated sessions. If either lever requires emergency code deployment, the trial is not ready.

The difference between written mechanism and deployed evidence is unusually concrete here. The standard supplies the extension mechanism; the deployed chain decides whether the bytes survive and the route remains usable. The proof is not the sentence “optional transitive attributes propagate.” It is the captured UPDATE, the durable Partial transition, the actual local error action, the RIB result and the delivered packet.