]> Nvidia

jefftant.ietf@gmail.com

Nvidia

sharpd@nvidia.com

Nvidia

vivek@nvidia.com

Nvidia

kmuppalla@nvidia.com

Routing IDR Working Group BGP SAFI Unreachability Monitoring Telemetry This document defines a new BGP Subsequent Address Family Identifier (SAFI) called "Unreachability Information" that allows the propagation of prefix unreachability information through BGP without affecting the installation or removal of routes in the Routing Information Base (RIB) or Forwarding Information Base (FIB). This mechanism enables network operators to share information about unreachable prefixes for monitoring, debugging, and coordination purposes while maintaining complete separation from the active routing plane.

Introduction BGP-4 withdrawals are only propagated for prefixes that have been previously announced. This behavior, while preventing certain attack vectors, limits the ability of operators to share information about prefix unreachability for prefixes that were never announced in the first place. There are several use cases where propagating unreachability information without affecting routing decisions would be valuable:

• Debugging and troubleshooting routing issues across administrative domains
• Sharing information about DDoS targets without null-routing traffic
• Coordinating information about potentially hijacked prefixes
• Monitoring and anomaly detection systems that need visibility into negative routing events
• Providing telemetry about routing system health without affecting production traffic

This document defines a new SAFI that creates a parallel information plane for unreachability data, allowing BGP speakers to share this information while maintaining complete separation from the routing plane.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology

UI-RIB:

Unreachability Information RIB

NLRI:

Network Layer Reachability Information

AFI:

Address Family Identifier

SAFI:

Subsequent Address Family Identifier

TLV:

Type-Length-Value

Protocol Extensions

Unreachability Information SAFI This document defines a new SAFI:

• Value: 86 (to be assigned by IANA)
• Name: Unreachability Information (UNREACH)
• Applicable to AFI: 1 (IPv4) and 2 (IPv6)

Capability Advertisement A BGP speaker that wishes to exchange Unreachability Information MUST advertise the corresponding AFI/SAFI capability as defined in . The Capability Code for Multiprotocol Extensions is 1. The Capability Value field contains: Where:

• AFI = 1 (IPv4) or 2 (IPv6)
• Reserved = 0 (MUST be set to 0 on transmit, ignored on receive)
• SAFI = 86 (Unreachability Information)

Additionally, this document defines a new capability:

• Capability Code: 86 (to be assigned by IANA)
• Capability Name: Enhanced Unreachability Information
• Capability Value: 1 octet flags field

Where:

• T bit: If set, speaker supports Timestamp TLV
• R bit: If set, speaker supports Reason Code TLV
• Reserved: MUST be zero on transmit, ignored on receive

NLRI Format The NLRI is uniquely identified by the combination of Prefix Length and Prefix. TLVs are NOT part of the NLRI key and provide additional context about the unreachability information. The presence of an Unreachability Information NLRI for a prefix signifies that the prefix is unreachable. The withdrawal of such an NLRI indicates normal routing operation for that prefix.

IPv4 Unreachability NLRI (AFI=1, SAFI=86)

IPv6 Unreachability NLRI (AFI=2, SAFI=86)

TLV Format TLVs provide additional context about the unreachability information: Defined TLV Types: Type 1: Original Reporter

• Length:4 octets
• Value: BGP Identifier of the original reporting speaker

Type 2: Unreachability Reason Code

• Length: 2 octets
• Value: Detailed reason code (registry to be established)
• 0: Unspecified
• 1: Policy Blocked
• 2: Security Filtered
• 3: RPKI Invalid
• 4-65535: Reserved for future use

Type 3: Timestamp

• Length: 8 octets
• Value: Unix timestamp (seconds since epoch) in network byte order, indicates when the unreachability event occurred or was detected

All TLV types except Type 1 (Original Reporter) are OPTIONAL. Type 1 MUST be present in all Unreachability Information NLRI. Implementations MUST ignore unknown TLV types to allow for future extensibility. Multiple TLVs of the same type SHOULD NOT be included; if present, only the first occurrence SHOULD be processed

Operation

NLRI Processing When a BGP speaker receives an UPDATE message with Unreachability Information SAFI:

1. It MUST NOT install or remove any routes in the Loc-RIB based on this information
2. It MUST maintain a separate Unreachability Information RIB (UI-RIB) for this SAFI
3. It SHOULD apply standard BGP path selection to UI-RIB entries for consistency
4. It MAY propagate the information according to standard BGP rules and local policy
5. It MUST NOT mix Unreachability Information NLRI with other SAFIs in the same UPDATE message

Interaction with Route Reflection Route Reflectors SHOULD treat Unreachability Information SAFI like any other AFI/SAFI combination, applying standard route reflection rules. The ORIGINATOR_ID and CLUSTER_LIST attributes apply normally.

Communities and Attributes Standard BGP communities and attributes apply to Unreachability Information SAFI:

• NO_EXPORT, NO_ADVERTISE, and NO_EXPORT_SUBCONFED work as defined
• Large Communities MAY be used for policy control
• AS_PATH is constructed normally for loop prevention
• ORIGIN SHOULD be set to IGP for locally generated information, EGP for information received via eBGP

Preventing State Explosion To prevent unbounded growth of the UI-RIB:

1. Implementations SHOULD limit the number of unreachability entries per prefix
2. Implementations SHOULD age out entries based on the Timestamp TLV when present
3. Implementations MUST implement rate limiting for accepting new unreachability information
4. Default maximum UI-RIB size SHOULD be configurable with a reasonable default (e.g., 100,000 entries)

Deployment Considerations

Incremental Deployment The Unreachability Information SAFI can be deployed incrementally:

• Speakers that don't support it simply don't negotiate the capability
• Mixed environments work correctly with normal BGP capability negotiation
• Can be enabled on specific sessions for testing

Use Cases Example deployment scenarios:

Inter-AS Debugging:

Enable between cooperating ASes for troubleshooting

Route Collectors:

Deploy on route collector sessions for enhanced telemetry

DDoS Coordination:

Share attack target information without null-routing

Security Monitoring:

Track suspicious unreachability patterns

Security Considerations The Unreachability Information SAFI introduces new security considerations:

1. Information Leakage: Unreachability information might reveal network topology or operational issues. Operators SHOULD carefully consider peering policies for this SAFI.
2. State Exhaustion: Malicious peers could attempt to exhaust memory by advertising large numbers of unreachable prefixes. Implementations MUST enforce limits as described in .
3. False Information: Peers could advertise false unreachability information. This SAFI SHOULD only be enabled with trusted peers.
4. Prefix Hijacking: The SAFI could be used to claim prefixes are unreachable when they're not. Since this doesn't affect routing, the impact is limited to monitoring systems.

Operators SHOULD:

• Use BGP TCP-AO or MD5 for session protection
• Implement prefix filtering for unreachability information
• Monitor UI-RIB size and growth rate
• Enable this SAFI only with explicitly trusted peers

IANA Considerations IANA is requested to assign:

1. A new SAFI value (suggested: 86) for "Unreachability Information" applicable to AFI 1 and AFI 2 in the "Subsequent Address Family Identifiers (SAFI) Parameters" registry.
2. A new BGP Capability Code (suggested: 86) for "Enhanced Unreachability Information" in the "Capability Codes" registry.
3. Create a new registry called "BGP Unreachability Information TLV Types" under the "Border Gateway Protocol (BGP) Parameters" registry page. The registration procedure is "RFC Required". Initial values are defined in .
4. Create a new registry called "BGP Unreachability Reason Codes" under the "Border Gateway Protocol (BGP) Parameters" registry page. The registration procedure is "RFC Required". Initial values to be defined in a subsequent document.

Acknowledgements The author would like to thank the IDR working group for their valuable feedback and suggestions on this proposal.

References Normative References Informative References

Implementation Considerations Implementers should consider the following aspects when implementing the Unreachability Information SAFI:

1. UI-RIB should be stored separately from regular RIBs
2. Show commands should clearly differentiate unreachability info
3. MIB/YANG models need updating for monitoring
4. BMP should be extended to support this SAFI

Examples

Example UPDATE Message An UPDATE message advertising that 192.0.2.0/24 is unreachable due to RPKI validation failure:

• AFI: 1 (IPv4)
• SAFI: 86 (Unreachability Information)
• NLRI:

• Prefix Length: 24
• Prefix: 192.0.2.0
• TLV Type 1 (Unreachability Type): Value 4 (RPKI Invalid)
• TLV Type 2 (Timestamp): Current Unix timestamp

• Path Attributes: Standard BGP attributes (AS_PATH, ORIGIN, etc.)

Configuration Example Example BGP configuration (vendor-neutral):