Skip to main content

RFC 9012 - The BGP Tunnel Encapsulation Attribute

Document Information

  • RFC Number: 9012
  • Title: The BGP Tunnel Encapsulation Attribute
  • Authors: K. Patel, G. Van de Velde, S. Sangli, J. Scudder
  • Date: April 2021
  • Category: Standards Track
  • ISSN: 2070-1721
  • Obsoletes: RFC 5512, RFC 5566
  • Updates: RFC 5640

Abstract

This document defines a BGP path attribute known as the "Tunnel Encapsulation attribute", which can be used with BGP UPDATEs of various Subsequent Address Family Identifiers (SAFIs) to provide information needed to create tunnels and their corresponding encapsulation headers. It provides encodings for a number of tunnel types, along with procedures for choosing between alternate tunnels and routing packets into tunnels.

This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation attribute. RFC 5512 was never deployed in production. Since RFC 5566 relies on RFC 5512, it is likewise obsoleted. This document updates RFC 5640 by indicating that the Load-Balancing Block sub-TLV may be included in any Tunnel Encapsulation attribute where load balancing is desired.

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9012.

Copyright (c) 2021 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. 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

  1. Introduction
  2. The Tunnel Encapsulation Attribute
  3. Tunnel Encapsulation Attribute Sub-TLVs
  4. Extended Communities Related to the Tunnel Encapsulation Attribute
  5. Special Considerations for IP-in-IP Tunnels
  6. Semantics and Usage of the Tunnel Encapsulation Attribute
  7. Routing Considerations
  8. Recursive Next-Hop Resolution
  9. Use of Virtual Network Identifiers and Embedded Labels When Imposing a Tunnel Encapsulation
  10. Applicability Restrictions
  11. Scoping
  12. Operational Considerations
  13. Validation and Error Handling
  14. IANA Considerations
  15. Security Considerations
  16. References

1. Introduction

This document defines a BGP path attribute known as the "Tunnel Encapsulation attribute", which can be used with BGP UPDATEs of various Subsequent Address Family Identifiers (SAFIs) to provide information needed to create tunnels and their corresponding encapsulation headers. It provides encodings for a number of tunnel types, along with procedures for choosing between alternate tunnels and routing packets into tunnels.

This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation attribute. RFC 5512 was never deployed in production. Since RFC 5566 relies on RFC 5512, it is likewise obsoleted. This document updates RFC 5640 by indicating that the Load-Balancing Block sub-TLV may be included in any Tunnel Encapsulation attribute where load balancing is desired.

2. The Tunnel Encapsulation Attribute

The Tunnel Encapsulation attribute is an optional transitive BGP path attribute. IANA has assigned the value 23 as the type code of the attribute.

The Tunnel Encapsulation attribute is composed of a set of Type-Length-Value (TLV) encodings. Each TLV contains information corresponding to a particular tunnel type.

3. Tunnel Encapsulation Attribute Sub-TLVs

The Value field of a TLV in the Tunnel Encapsulation attribute consists of a sequence of sub-TLVs.

3.1. The Tunnel Egress Endpoint Sub-TLV (Type Code 6)

3.2. Encapsulation Sub-TLVs for Particular Tunnel Types (Type Code 1)

3.2.1. VXLAN (Tunnel Type 8)

3.2.2. NVGRE (Tunnel Type 9)

3.2.3. L2TPv3 (Tunnel Type 1)

3.2.4. GRE (Tunnel Type 2)

3.2.5. MPLS-in-GRE (Tunnel Type 11)

3.3. Outer Encapsulation Sub-TLVs

3.3.1. DS Field (Type Code 7)

3.3.2. UDP Destination Port (Type Code 8)

3.4. Sub-TLVs for Aiding Tunnel Selection

3.4.1. Protocol Type Sub-TLV (Type Code 2)

3.4.2. Color Sub-TLV (Type Code 4)

3.5. Embedded Label Handling Sub-TLV (Type Code 9)

3.6. MPLS Label Stack Sub-TLV (Type Code 10)

3.7. Prefix-SID Sub-TLV (Type Code 11)

4.1. Encapsulation Extended Community

4.2. Router's MAC Extended Community

4.3. Color Extended Community

5. Special Considerations for IP-in-IP Tunnels

6. Semantics and Usage of the Tunnel Encapsulation Attribute

7. Routing Considerations

7.1. Impact on the BGP Decision Process

7.2. Looping, Mutual Recursion, Etc.

8. Recursive Next-Hop Resolution

9. Use of Virtual Network Identifiers and Embedded Labels When Imposing a Tunnel Encapsulation

9.1. Tunnel Types without a Virtual Network Identifier Field

9.2. Tunnel Types with a Virtual Network Identifier Field

9.2.1. Unlabeled Address Families

9.2.2. Labeled Address Families

10. Applicability Restrictions

11. Scoping

12. Operational Considerations

13. Validation and Error Handling

14. IANA Considerations

15. Security Considerations

16. References

16.1. Normative References

16.2. Informative References

Appendix A. Impact on RFC 8365

Acknowledgments

Authors' Addresses

Keyur Patel Arrcus, Inc. Email: [email protected]

Gunter Van de Velde Nokia Email: [email protected]

Srihari R. Sangli Juniper Networks Email: [email protected]

John Scudder Juniper Networks Email: [email protected]