IDR Working Group J. Tantsura Internet-Draft D. Sharp Intended status: Standards Track V. Venkatraman Expires: 15 May 2026 K. Muppalla Nvidia 11 November 2025 BGP Unreachability Information SAFI draft-tantsura-idr-unreachability-safi-00 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 15 May 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Tantsura, et al. Expires 15 May 2026 [Page 1] Internet-Draft BGP Unreachability SAFI November 2025 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 3 2.1. Unreachability Information SAFI . . . . . . . . . . . . . 3 2.2. Capability Advertisement . . . . . . . . . . . . . . . . 4 3. NLRI Format . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. IPv4 Unreachability NLRI (AFI=1, SAFI=86) . . . . . . . . 5 3.2. IPv6 Unreachability NLRI (AFI=2, SAFI=86) . . . . . . . . 5 3.3. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 5 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. NLRI Processing . . . . . . . . . . . . . . . . . . . . . 6 4.2. Interaction with Route Reflection . . . . . . . . . . . . 7 4.3. Communities and Attributes . . . . . . . . . . . . . . . 7 4.4. Preventing State Explosion . . . . . . . . . . . . . . . 7 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 7 5.1. Incremental Deployment . . . . . . . . . . . . . . . . . 7 5.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Implementation Considerations . . . . . . . . . . . 10 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 10 B.1. Example UPDATE Message . . . . . . . . . . . . . . . . . 10 B.2. Configuration Example . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction BGP-4 [RFC4271] 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: Tantsura, et al. Expires 15 May 2026 [Page 2] Internet-Draft BGP Unreachability SAFI November 2025 * 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. 1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Terminology UI-RIB: Unreachability Information RIB NLRI: Network Layer Reachability Information AFI: Address Family Identifier SAFI: Subsequent Address Family Identifier TLV: Type-Length-Value 2. Protocol Extensions 2.1. Unreachability Information SAFI This document defines a new SAFI: * Value: 86 (to be assigned by IANA) * Name: Unreachability Information (UNREACH) Tantsura, et al. Expires 15 May 2026 [Page 3] Internet-Draft BGP Unreachability SAFI November 2025 * Applicable to AFI: 1 (IPv4) and 2 (IPv6) 2.2. Capability Advertisement A BGP speaker that wishes to exchange Unreachability Information MUST advertise the corresponding AFI/SAFI capability as defined in [RFC5492]. The Capability Code for Multiprotocol Extensions is 1. The Capability Value field contains: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI | Reserved | SAFI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |T|R| Reserved | +-+-+-+-+-+-+-+-+ 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 Tantsura, et al. Expires 15 May 2026 [Page 4] Internet-Draft BGP Unreachability SAFI November 2025 3. 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. 3.1. IPv4 Unreachability NLRI (AFI=1, SAFI=86) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | IPv4 Prefix (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLVs (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2. IPv6 Unreachability NLRI (AFI=2, SAFI=86) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | IPv6 Prefix (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLVs (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.3. TLV Format TLVs provide additional context about the unreachability information: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Value (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Defined TLV Types: Type 1: Original Reporter * Length:4 octets * Value: BGP Identifier of the original reporting speaker Tantsura, et al. Expires 15 May 2026 [Page 5] Internet-Draft BGP Unreachability SAFI November 2025 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 4. Operation 4.1. 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 Tantsura, et al. Expires 15 May 2026 [Page 6] Internet-Draft BGP Unreachability SAFI November 2025 5. It MUST NOT mix Unreachability Information NLRI with other SAFIs in the same UPDATE message 4.2. 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. 4.3. 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 [RFC8092] 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 4.4. 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) 5. Deployment Considerations 5.1. Incremental Deployment The Unreachability Information SAFI can be deployed incrementally: * Speakers that don't support it simply don't negotiate the capability Tantsura, et al. Expires 15 May 2026 [Page 7] Internet-Draft BGP Unreachability SAFI November 2025 * Mixed environments work correctly with normal BGP capability negotiation * Can be enabled on specific sessions for testing 5.2. 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 6. 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 Section 4.4. 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 [RFC5925] or MD5 for session protection * Implement prefix filtering for unreachability information * Monitor UI-RIB size and growth rate Tantsura, et al. Expires 15 May 2026 [Page 8] Internet-Draft BGP Unreachability SAFI November 2025 * Enable this SAFI only with explicitly trusted peers 7. 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 Section 3.3. 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. 8. Acknowledgements The author would like to thank the IDR working group for their valuable feedback and suggestions on this proposal. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, . Tantsura, et al. Expires 15 May 2026 [Page 9] Internet-Draft BGP Unreachability SAFI November 2025 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, . [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, June 2016, . [RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas, I., and N. Hilliard, "BGP Large Communities Attribute", RFC 8092, DOI 10.17487/RFC8092, February 2017, . Appendix A. 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 [RFC7854] should be extended to support this SAFI Appendix B. Examples B.1. 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 Tantsura, et al. Expires 15 May 2026 [Page 10] Internet-Draft BGP Unreachability SAFI November 2025 * 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.) B.2. Configuration Example Example BGP configuration (vendor-neutral): router bgp 65001 neighbor 192.0.2.1 remote-as 65002 ! address-family ipv4 unreachability neighbor 192.0.2.1 activate neighbor 192.0.2.1 maximum-prefix 50000 neighbor 192.0.2.1 route-map UNREACH-IN in neighbor 192.0.2.1 route-map UNREACH-OUT out exit-address-family ! address-family ipv6 unreachability neighbor 2001:db8::1 activate exit-address-family ! route-map UNREACH-IN permit 10 match community NO-EXPORT-UNREACH set local-preference 50 ! Authors' Addresses Jeff Tantsura Nvidia Email: jefftant.ietf@gmail.com Donald Sharp Nvidia Email: sharpd@nvidia.com Vivek Venkatraman Nvidia Email: vivek@nvidia.com Tantsura, et al. Expires 15 May 2026 [Page 11] Internet-Draft BGP Unreachability SAFI November 2025 Karthikeya Venkat Muppalla Nvidia Email: kmuppalla@nvidia.com Tantsura, et al. Expires 15 May 2026 [Page 12]