Summary

  • At APNIC 62 on 9 September, Maria Matejka warned that BIRD rejects OTC-invalid routes too harshly and named 2.20.0 and 3.4.0 as expected fix versions. That was a prospective statement, not a release receipt.
  • The inspected BIRD 2.19.2 source turns certain role-dependent OTC violations into withdrawals before constructing the ordinary route object. A log can survive while the object a filtered-route view would need does not.
  • RFC 9234 excludes an ineligible route from active selection. Keeping a separate diagnostic record must not make it selectable or exportable, and is not permission to retain malformed updates as usable routes.

The gate closes before the explanation gets a shelf. That is the less obvious cost inside a warning delivered at APNIC 62: a router can do the right thing about propagation and still leave its operator with the wrong sort of evidence for explaining a rejection.

In her 9 September presentation, Maria Matejka said BIRD handled OTC-invalid routes too harshly, with a fix expected in versions 2.20.0 and 3.4.0. The surrounding discussion concerned the limits of remote monitoring and the absence of a guarantee that another network will report a problem. The warning did not announce an APNIC deployment rule or establish that the fix had shipped.

The distinction matters because “reject” can describe two different products. One is a route that cannot be used. The other is the information an operator can still inspect about that route. Security requires the first result. Diagnosis needs an account of how it was reached.

Ineligible does not mean entitled to disappear

The May 2022 RFC 9234 defines an ineligible route by its exclusion from Loc-RIB installation and the next phase of route selection. Its OTC procedures use the relationship on the BGP session to stop announcements from crossing a prohibited boundary. OTC is not merely a red badge an operator may ignore.

But exclusion from selection is not an instruction to erase every diagnostic representation. A quarantined record could explain a decision without becoming a candidate route. Conversely, putting an invalid route into an ordinary active routing table and promising not to use it is not something the definition automatically authorizes. The safety property has to survive the choice of representation.

This is a separation of purposes, not a call for weaker leak prevention. A malformed OTC attribute also belongs to a different case from a well-formed attribute whose value or direction reveals a leak.

The looking-glass request is older than the warning

The operational demand was already visible in a June 2025 BCIX correspondent’s request. André Grüneberg wanted OTC-rejected routes represented in a looking glass, with their rejected state identifiable. His proposed storage arrangement was a request for discussion, not proof that such an arrangement complied with every routing-table requirement or had been deployed.

A follow-up that June put a finger on the implementation boundary: the correspondent could not find an interaction between the withdrawal path and BIRD’s filtered-route retention facility. Moving OTC handling into user filters could change the point at which an object was rejected, but the exchange also recognized the loss of session Role checking in a filter-only alternative.

That trade-off should not be smuggled into a troubleshooting recommendation. Losing a relationship check in order to show a more informative error would exchange one control for another. The better design question is how to preserve the error without making that exchange.

The release-tagged code shows the join

The official download page inspected on 14 September listed BIRD 2.19.2 and 3.3.2, dated 30 July, among its releases. It did not list the two promised versions in that capture. That bounds the public release evidence examined; it says nothing conclusive about a private backport, another package channel or a later publication.

The 2.19.2 attribute-processing source provides a narrower, reproducible observation. Where Roles apply to the channel, OTC on a route received by a locally configured Provider or Route Server triggers withdrawal. A Peer also triggers withdrawal when the OTC ASN differs from the remote ASN. The withdrawal macro records a message, sets the withdrawal flag and returns.

The same file distinguishes wire validity: an OTC attribute with a length other than four octets enters a withdrawal path at decoding. That protocol-error check should not be confused with the later role-dependent leak decision.

In the matching packet-processing source, attribute finishing is followed by a check of the withdrawal flag. If it is set, the attribute pointer becomes null. Applying the route with that null pointer sends a withdrawal into the update routine; the other branch creates a temporary route object.

The ordinary route representation and the reason for rejecting it have therefore parted company. A retention setting for routes rejected by subsequent filtering cannot be assumed to recover an object replaced by withdrawal earlier. That is an inference from this tagged code path, not a test of a deployed router or a finding about every BIRD branch.

Nor is the route invisible in every sense. The code logs. This examination did not test packet capture, import tables, BMP feeds or other diagnostic arrangements. A surviving message, however, is not automatically a reconstructable route record with the received attribute, session context and decision attached.