RFC 9012
The BGP Tunnel Encapsulation Attribute
The BGP Tunnel Encapsulation Attribute 🎀 (Part 1 of 11)
okay bestie, let's get into it 💖 RFC 9012 is from April 2021 and it's a Standards Track document (ISSN 2070-1721). The authors are K. Patel (Arrcus, Inc), G. Van de Velde (Nokia), and S. Sangli and J. Scudder (Juniper Networks). It obsoletes RFC 5512 and RFC 5566, and it updates RFC 5640. Now let's get into the tea 🫖
Abstract
okay so this doc defines a BGP path attribute called the "Tunnel Encapsulation attribute" 🦋 It can ride along on BGP UPDATEs from lots of different Subsequent Address Family Identifiers (SAFIs), and its whole job is to hand over the info you need to build tunnels and their encapsulation headers. It also has encodings for a bunch of tunnel types, plus procedures for picking between alternate tunnels and routing packets into tunnels. iconic 💅
RFC 5512 was the first version of this attribute, and this doc obsoletes it because it was never deployed in production 💀 RFC 5566 leans on RFC 5512, so it gets obsoleted too. And this doc updates RFC 5640 by saying 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. 🎀
It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841.
For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9012 🔗
Copyright Notice
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) as they stand on the date of publication. Please read these carefully, bestie, because they explain your rights and restrictions for this doc. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 📜
Table of Contents
1. Introduction
1.1. Brief Summary of RFC 5512
1.2. Deficiencies in RFC 5512
1.3. Use Case for the Tunnel Encapsulation Attribute
1.4. Brief Summary of Changes from RFC 5512
1.5. Update to RFC 5640
1.6. Effects of Obsoleting RFC 5566
2. The Tunnel Encapsulation Attribute
3. Tunnel Encapsulation Attribute Sub-TLVs
3.1. The Tunnel Egress Endpoint Sub-TLV (Type Code 6)
3.1.1. Validating the Address Subfield
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. Extended Communities Related to the Tunnel Encapsulation
Attribute
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
14.1. Obsoleting RFC 5512
14.2. Obsoleting Code Points Assigned by RFC 5566
14.3. Border Gateway Protocol (BGP) Tunnel Encapsulation
Grouping
14.4. BGP Tunnel Encapsulation Attribute Tunnel Types
14.5. Subsequent Address Family Identifiers
14.6. BGP Tunnel Encapsulation Attribute Sub-TLVs
14.7. Flags Field of VXLAN Encapsulation Sub-TLV
14.8. Flags Field of NVGRE Encapsulation Sub-TLV
14.9. Embedded Label Handling Sub-TLV
14.10. Color Extended Community Flags
15. Security Considerations
16. References
16.1. Normative References
16.2. Informative References
Appendix A. Impact on RFC 8365
Acknowledgments
Contributors
Authors' Addresses1. Introduction ✨
okay so this doc obsoletes [RFC5512] 🙈 The problems with [RFC5512], and a summary of what changed, are covered in Sections 1.1-1.3. The stuff from [RFC5512] that we're keeping has been folded into this doc. And since [RFC5566] relies on [RFC5512], it gets obsoleted too.
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. 🎀 So if you see those words in caps, they're the official requirement words, and if they're lowercase they're just regular English.
1.1. Brief Summary of RFC 5512
[RFC5512] defines a BGP path attribute called the Tunnel Encapsulation attribute 🦋 This attribute is made of one or more TLVs. Each TLV identifies one particular type of tunnel, and each TLV also has one or more sub-TLVs. Some sub-TLVs, like the Encapsulation sub-TLV, hold info that can be used to build the encapsulation header for that tunnel type. Other sub-TLVs, like the "color sub-TLV" and the "protocol sub-TLV", help decide whether a given packet should be sent through the tunnel that the TLV names 💅
[RFC5512] only lets the Tunnel Encapsulation attribute ride on BGP UPDATE messages of the Encapsulation Address Family. These UPDATEs have an Address Family Identifier (AFI) of 1 or 2, and a SAFI of 7. In an UPDATE of the Encapsulation SAFI, the Network Layer Reachability Information (NLRI) is an address of the BGP speaker that originated the UPDATE. Okay, picture this scenario 👀
- BGP speaker R1 has received and selected UPDATE U for local use;
- UPDATE U's SAFI is the Encapsulation SAFI;
- UPDATE U has the address R2 as its NLRI;
- UPDATE U has a Tunnel Encapsulation attribute.
- R1 has a packet, P, to transmit to destination D; and
- R1's best route to D is a BGP route that has R2 as its next hop.
So in this setup, when R1 sends packet P, it should send it to R2 through one of the tunnels listed in U's Tunnel Encapsulation attribute. The IP address of the tunnel egress endpoint of each of those tunnels is R2. Packet P is called the tunnel's "payload" 🎁
1.2. Deficiencies in RFC 5512
Okay, the ability to specify tunnel info in a BGP UPDATE is honestly really useful 🙌 But the procedures in [RFC5512] have some limitations, and we need to talk about them 🫠
- The requirement to use the Encapsulation SAFI is an unfortunate operational cost, because every BGP session that might need to carry tunnel encapsulation info has to be reconfigured to support the Encapsulation SAFI. The Encapsulation SAFI has never been used, and this requirement has only discouraged people from using the Tunnel Encapsulation attribute 💀
- There's no way to use the Tunnel Encapsulation attribute to specify the tunnel egress endpoint address of a given tunnel. [RFC5512] assumes that the tunnel egress endpoint of each tunnel is specified as the NLRI of an UPDATE of the Encapsulation SAFI.
- If the respective best routes to two different address prefixes have the same next hop, [RFC5512] doesn't give a straightforward way to associate each prefix with a different tunnel 😵💫
- If a particular tunnel type requires an outer IP or UDP encapsulation, there's no way to signal the values of any of the fields in that outer encapsulation.
- In the spec of the sub-TLVs in [RFC5512], each sub-TLV has a one-octet Length field. In some cases, where a sub-TLV might need more than 255 octets to be encoded, a two-octet Length field may be needed.
1.3. Use Case for the Tunnel Encapsulation Attribute
Let's look at a router R1 forwarding an IP packet P. Let D be P's IP destination address. R1 must look up D in its forwarding table. Say the "best match" route for D is route Q, where Q is a BGP-distributed route whose "BGP next hop" is router R2. And say the routers along the path from R1 to R2 have entries for R2 in their forwarding tables but do NOT have entries for D in their forwarding tables. For example, the path from R1 to R2 might be part of a "BGP-free core", where there are no BGP-distributed routes at all in the core. Or, as in [RFC5565], D might be an IPv4 address while the intermediate routers along the path from R1 to R2 only support IPv6 🧚
In cases like this, for R1 to forward packet P properly, it must encapsulate P and send P "through a tunnel" to R2. For example, R1 might encapsulate P using GRE, Layer 2 Tunneling Protocol version 3 (L2TPv3), IP in IP, etc., where the destination IP address of the encapsulation header is the address of R2 🌸
For R1 to encapsulate P for transport to R2, R1 must know which encapsulation protocol to use for sending different sorts of packets to R2. R1 must also know how to fill in the various fields of the encapsulation header. With certain encapsulation types, this knowledge might be picked up by default or through manual configuration. Other encapsulation protocols have fields like session id, key, or cookie that must be filled in. It would not be desirable to require every BGP speaker to be manually configured with the encapsulation info for every one of its BGP next hops. Nobody wants that much config, bestie 😭
This document specifies a way that BGP itself can be used by a given BGP speaker to tell other BGP speakers, "If you need to encapsulate packets to be sent to me, here's the information you need to properly form the encapsulation header". A BGP speaker signals this info to other BGP speakers by using a new BGP attribute type value -- the BGP Tunnel Encapsulation attribute ✨ This attribute specifies the encapsulation protocols that may be used, plus whatever extra info (if any) is needed to properly use those protocols. Other attributes, like communities or extended communities, may also be included 💜
1.4. Brief Summary of Changes from RFC 5512 💖
okay bestie, so this section is basically the "here's everything we fixed" list 🧚 It's addressing the deficiencies from Section 1.2 by doing a few things:
- Deprecating the Encapsulation SAFI. 🥀
- Defining a new "Tunnel Egress Endpoint sub-TLV" (Section 3.1) that can go inside any of the TLVs in the Tunnel Encapsulation attribute. It lets you specify the remote endpoint address of a particular tunnel. 📍
- Letting the Tunnel Encapsulation attribute ride along on BGP UPDATEs for additional AFI/SAFIs. Semantics are provided for that, so it's not just vibes, it's defined 🌈
- Defining a bunch of new sub-TLVs that carry extra info you need when you're building the encapsulation header for a packet going through a specific tunnel. 🎀
- Changing how the Sub-TLV Type field works for length. Types 0 to 127 (inclusive) get a one-octet Length field, and types 128 to 255 (inclusive) get a two-octet Length field. Organized! 💅
So, one of the sub-TLVs from [RFC5512] is the "Encapsulation sub-TLV" 🫶 For a given tunnel, it specifies some of the info needed to build the encapsulation header used when sending packets through that tunnel. This document defines Encapsulation sub-TLVs for tunnel types that [RFC5512] didn't cover: Virtual eXtensible Local Area Network (VXLAN) [RFC7348], Network Virtualization Using Generic Routing Encapsulation (NVGRE) [RFC7637], and MPLS in Generic Routing Encapsulation (MPLS-in-GRE) [RFC4023]. MPLS-in-UDP [RFC7510] is supported too, but it doesn't need an Encapsulation sub-TLV since there are no extra parameters to signal. Lowkey elegant ✨
Some of those encapsulations need to be wrapped further inside UDP and/or IP. [RFC5512] has no way to say "hey, put this info in those outer IP and/or UDP layers." 😭 So this document gives you a framework for including that kind of info in the TLVs of the Tunnel Encapsulation attribute. Finally 🙌
Here's where it gets a little spicy 🌶️ When the Tunnel Encapsulation attribute is attached to a BGP UPDATE whose AFI/SAFI is one of the labeled address families, it's not always obvious whether the label in the NLRI should show up somewhere in the tunnel encapsulation header (and if so, where), whether it belongs in the payload, or whether it can be dropped entirely. It's especially confusing when the tunnel encapsulation header has its own "virtual network identifier" 🙈 This document gives you a mechanism for signaling (using sub-TLVs of the Tunnel Encapsulation attribute) how you want the embedded label used when the tunnel encapsulation has its own Virtual Network Identifier field. Main character energy 👑
[RFC5512] also defines an Encapsulation Extended Community that can be used instead of the Tunnel Encapsulation attribute in certain situations. This document explains how the Encapsulation Extended Community can be used in a backwards-compatible way (see Section 4.1). You're also allowed to combine Encapsulation Extended Communities and Tunnel Encapsulation attributes in the same BGP UPDATE like this 🦋
1.5. Update to RFC 5640 🌸
This document updates [RFC5640]. The change is that the Load-Balancing Block sub-TLV MAY be included in any Tunnel Encapsulation attribute where load balancing is desired. Load balancing, but make it sub-TLV 🍓
1.6. Effects of Obsoleting RFC 5566 🥺
This specification obsoletes RFC 5566. That in turn deprecates a number of code points defined in that document. 💀 In the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry [IANA-BGP-TUNNEL-ENCAP], these code points are now marked as deprecated:
- "Transmit tunnel endpoint" (type code 3)
- "IPsec in Tunnel-mode" (type code 4)
- "IP in IP tunnel with IPsec Transport Mode" (type code 5)
- "MPLS-in-IP tunnel with IPsec Transport Mode" (type code 6)
In the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry [IANA-BGP-TUNNEL-ENCAP], "IPsec Tunnel Authenticator" (type code 3) has been marked as deprecated too. See Section 14.2. Bye bye, old stuff 👋🌈
2. The Tunnel Encapsulation Attribute 🎀
The Tunnel Encapsulation attribute is an optional transitive BGP path attribute. IANA assigned the value 23 as the type code of the attribute in the "BGP Path Attributes" registry [IANA-BGP-PARAMS]. The attribute is made up of a set of Type-Length-Value (TLV) encodings, and each TLV holds info for one particular tunnel type. A Tunnel Encapsulation TLV (aka Tunnel TLV) is structured like this 🧩
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Type (2 octets) | Length (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Tunnel Encapsulation TLVHere's the breakdown:
Tunnel Type (2 octets): identifies a type of tunnel. The field contains values from the IANA registry "BGP Tunnel Encapsulation Attribute Tunnel Types" [IANA-BGP-TUNNEL-ENCAP]. See Section 3.4.1 for how tunnel types named like "X-in-Y" get special treatment. 🔍Length (2 octets): the total number of octets in the Value field. 📏Value (variable): made up of multiple sub-TLVs. 🫧
Each sub-TLV has three fields: a 1-octet type, a 1-octet or 2-octet length (depending on the type), and zero or more octets of value. A sub-TLV looks like this 💜
+--------------------------------+
| Sub-TLV Type (1 octet) |
+--------------------------------+
| Sub-TLV Length (1 or 2 octets) |
+--------------------------------+
| Sub-TLV Value (variable) |
+--------------------------------+
Figure 2: Encapsulation Sub-TLVSub-TLV Type (1 octet): each sub-TLV type defines a certain property about the Tunnel TLV that contains it. The field contains values from the IANA registry "BGP Tunnel Encapsulation Attribute Sub-TLVs" [IANA-BGP-TUNNEL-ENCAP]. 🏷️Sub-TLV Length (1 or 2 octets): the total number of octets in the Sub-TLV Value field. It's 1 octet if the Sub-TLV Type is in the range 0-127, and two octets if the Sub-TLV Type is in the range 128-255. ✂️Sub-TLV Value (variable): the encoding depends on the sub-TLV type. The following subsections define the encoding in detail. 🌷
3. Tunnel Encapsulation Attribute Sub-TLVs 🧁
This section specifies a bunch of sub-TLVs, and they can be included in a TLV of the Tunnel Encapsulation attribute. Let's gooo 🚀
3.1. The Tunnel Egress Endpoint Sub-TLV (Type Code 6) 🎀
okay bestie, this is the sub-TLV that tells everyone where the tunnel ends 🦋 The tunnel egress endpoint is the address of the router that will decapsulate the payload, aka the router that unwraps the packet and takes it from there 💅 Its Value field contains three subfields:
- a Reserved subfield
- a two-octet Address Family subfield
- an Address subfield, whose length depends upon the Address Family.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family (2 octets) | Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (variable) +
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: Tunnel Egress Endpoint Sub-TLV Value Field ✨
The Reserved subfield SHOULD be originated as zero 🫶 It MUST be disregarded on receipt, and it MUST be propagated unchanged. No skipping that part, periodt.
The Address Family subfield contains a value from IANA's "Address Family Numbers" registry [IANA-ADDRESS-FAM]. This document assumes that the Address Family is either IPv4 or IPv6, so other address families are outside the scope of this document 🌸
If the Address Family subfield contains the value for IPv4, the Address subfield MUST contain an IPv4 address (a /32 IPv4 prefix) 🌈
If the Address Family subfield contains the value for IPv6, the Address subfield MUST contain an IPv6 address (a /128 IPv6 prefix) 💜
Now the mixing part, which is kinda iconic. In a given BGP UPDATE, the address family (IPv4 or IPv6) of a Tunnel Egress Endpoint sub-TLV is independent of the address family of the UPDATE itself. For example, an UPDATE whose NLRI is an IPv4 address may have a Tunnel Encapsulation attribute containing Tunnel Egress Endpoint sub-TLVs that contain IPv6 addresses. Also, different tunnels represented in the Tunnel Encapsulation attribute may have tunnel egress endpoints of different address families. Main character energy for sure ✨
There is one special case 👑 The Tunnel Egress Endpoint sub-TLV MAY have a Value field whose Address Family subfield contains 0. This means that the tunnel's egress endpoint is the address of the next hop. If the Address Family subfield contains 0, the Address subfield is omitted. In this case, the Length field of Tunnel Egress Endpoint sub-TLV MUST contain the value 6 (0x06) 🧚
When the Tunnel Encapsulation attribute is carried in an UPDATE message of one of the AFI/SAFIs specified in this document (see the first paragraph of Section 6), each TLV MUST have one, and only one, Tunnel Egress Endpoint sub-TLV. If a TLV does not have a Tunnel Egress Endpoint sub-TLV, that TLV should be treated as if it had a malformed Tunnel Egress Endpoint sub-TLV (see below). 💀
In the context of this specification, if the Address Family subfield has any value other than IPv4, IPv6, or the special value 0, the Tunnel Egress Endpoint sub-TLV is considered "unrecognized" (see Section 13). If any of the following conditions hold, the Tunnel Egress Endpoint sub-TLV is considered to be "malformed":
- The length of the sub-TLV's Value field is other than 6 added to the defined length for the address family given in its Address Family subfield. Therefore, for address family behaviors defined in this document, the permitted values are:
10, if the Address Family subfield contains the value for IPv4.22, if the Address Family subfield contains the value for IPv6.6, if the Address Family subfield contains the value zero.
- The IP address in the sub-TLV's Address subfield lies within a block listed in the relevant Special-Purpose IP Address registry [RFC6890] with either a "destination" attribute value or a "forwardable" attribute value of "false". (Such routes are sometimes colloquially known as "Martians" 👽) This restriction MAY be relaxed by explicit configuration.
- It can be determined that the IP address in the sub-TLV's Address subfield does not belong to the Autonomous System (AS) that originated the route that contains the attribute. Section 3.1.1 describes an optional procedure to make this determination.
Error handling is specified in Section 13.
If the Tunnel Egress Endpoint sub-TLV contains an IPv4 or IPv6 address that is valid but not reachable, the sub-TLV is not considered to be malformed. Reachable is not the same as valid, bestie, so don't mix them up 🙈
3.1.1. Validating the Address Subfield
This section provides a procedure that MAY be applied to validate that the IP address in the sub-TLV's Address subfield belongs to the AS that originated the route that contains the attribute. (The notion of "belonging to" an AS is expanded on below.) Doing this is thought to increase confidence that when traffic is sent to the IP address depicted in the Address subfield, it will go to the same AS as it would go to if the Tunnel Encapsulation attribute were not present, although of course it cannot guarantee it. See Section 15 for discussion of the limitations of this procedure. The principal applicability of this procedure is in deployments that are not strictly scoped. In deployments with strict scope, and especially those scoped to a single AS, these procedures may not add substantial benefit beyond those discussed in Section 11. 🔥
The Route Origin Autonomous System Number (ASN) of a BGP route that includes a Tunnel Encapsulation attribute can be determined by inspection of the AS_PATH attribute, according to the procedure specified in [RFC6811], Section 2. Call this value Route_AS.
In order to determine the Route Origin ASN of the address depicted in the Address subfield of the Tunnel Egress Endpoint sub-TLV, it is necessary to consider the forwarding route, that is, the route that will be used to forward traffic toward that address. This route is determined by a recursive route-lookup operation for that address, as discussed in [RFC4271], Section 5.1.3. The relevant AS path to consider is the last one encountered while performing the recursive lookup; the procedures of [RFC6811], Section 2 are applied to that AS path to determine the Route Origin ASN. If no AS path is encountered at all, for example, if that route's source is a protocol other than BGP, the Route Origin ASN is the BGP speaker's own AS number. Call this value Egress_AS. 🦋
If Route_AS does not equal Egress_AS, then the Tunnel Egress Endpoint sub-TLV is considered not to be valid. In some cases, a network operator who controls a set of ASes might wish to allow a tunnel egress endpoint to reside in an AS other than Route_AS; configuration MAY allow for such a case, in which case the check becomes: if Egress_AS is not within the configured set of permitted AS numbers, then the Tunnel Egress Endpoint sub-TLV is considered to be "malformed".
Note that if the forwarding route changes, this procedure MUST be reapplied. As a result, a sub-TLV that was formerly considered valid might become not valid, or vice versa. Route changes, so re-check, no exceptions 🥺
3.2. Encapsulation Sub-TLVs for Particular Tunnel Types (Type Code 1) 🌷
This section defines Encapsulation sub-TLVs for the following tunnel types: VXLAN [RFC7348], NVGRE [RFC7637], MPLS-in-GRE [RFC4023], L2TPv3 [RFC3931], and GRE [RFC2784]. Five tunnel types, five little encap-sub-TLV glow-ups 💖
Rules for forming the encapsulation based on the information in a given TLV are given in Sections 6 and 9.
Recall that the tunnel type itself is identified by the Tunnel Type field in the attribute header (Section 2); the Encapsulation sub-TLV's structure is inferred from this. Regardless of the tunnel type, the sub-TLV type of the Encapsulation sub-TLV is 1. There are also tunnel types for which it is not necessary to define an Encapsulation sub-TLV, because there are no fields in the encapsulation header whose values need to be signaled from the tunnel egress endpoint. Some tunnels just don't need the extra info, and that's valid ngl 🧁
3.2.1. VXLAN (Tunnel Type 8) 🌸
okay bestie, so this bit defines an Encapsulation sub-TLV for VXLAN [RFC7348] tunnels 🦋 when the tunnel type is VXLAN, the sub-TLV is 12 octets long. the Value field looks like this (Figure 4) ✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V|M|R|R|R|R|R|R| VN-ID (3 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (2 octets) | Reserved (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: VXLAN Encapsulation Sub-TLV Value Field- V: this bit gets set to 1 to say a Virtual Network Identifier (VN-ID) is present in the Encapsulation sub-TLV 💖 if it's set to 0, the VN-ID field gets ignored. Please see Section 9.
- M: this bit gets set to 1 to say a Media Access Control (MAC) Address is present in the Encapsulation sub-TLV 🍓 if it's set to 0, the MAC Address field gets ignored.
- R: the other bits in the 8-bit Flags field are reserved for later use 🔥 the originator of the sub-TLV MUST always set them to 0. Intermediate routers MUST propagate them without modification. Any receiving routers MUST ignore these bits when they arrive.
- VN-ID: if the V bit is set to 1, the VN-ID field holds a 3-octet VN-ID value 🧚 if the V bit is set to 0, the VN-ID field MUST be set to zero when it's sent and gets disregarded when it's received.
- MAC Address: if the M bit is set to 1, this field holds a 6-octet Ethernet MAC address 💜 if the M bit is set to 0, this field MUST be set to all zeroes when sent and gets disregarded when received.
- Reserved: MUST be set to zero when sent and disregarded when received 🫶
When you're forming the VXLAN encapsulation header, here's the tea 🍵
- The values of the V, M, and R bits are NOT copied into the Flags field of the VXLAN header. The Flags field of the VXLAN header is set as per [RFC7348]. 💅
- If the M bit is set to 1, the MAC Address gets copied into the Inner Destination MAC Address field of the Inner Ethernet Header (see Section 5 of [RFC7348]).
- If the M bit is set to 0, and the payload going through the VXLAN tunnel is an Ethernet frame, the Destination MAC Address field of the Inner Ethernet Header is just the Destination MAC Address field of the payload's Ethernet header. 🌈
- If the M bit is set to 0, and the payload going through the VXLAN tunnel is an IP or MPLS packet, the Inner Destination MAC Address field gets set to a configured value. If there's no configured value, the VXLAN tunnel cannot be used. 😭
- If the V bit is set to 0, and the BGP UPDATE message has an AFI/SAFI other than Ethernet VPNs (SAFI 70, "BGP EVPNs"), then the VXLAN tunnel cannot be used. 💀
- Section 9 explains how the VNI (VXLAN Network Identifier) field of the VXLAN encapsulation header gets set. ⭐
Note that to send an IP packet or an MPLS packet through a VXLAN tunnel, the packet has to get encapsulated in an Ethernet header first 🦋 that header becomes the "Inner Ethernet Header" from [RFC7348]. The VXLAN Encapsulation sub-TLV can carry info (like the MAC address) that's used to build this Ethernet header. 🎀
3.2.2. NVGRE (Tunnel Type 9) 🌷
this one defines an Encapsulation sub-TLV for NVGRE [RFC7637] tunnels ✨ when the tunnel type is NVGRE, the sub-TLV is 12 octets long, and the Value field looks like this (Figure 5) 🧚
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V|M|R|R|R|R|R|R| VN-ID (3 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (2 octets) | Reserved (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: NVGRE Encapsulation Sub-TLV Value Field- V: this bit gets set to 1 to say a VN-ID is present in the Encapsulation sub-TLV. If it's set to 0, the VN-ID field gets ignored. Please see Section 9.
- M: this bit gets set to 1 to say a MAC Address is present in the Encapsulation sub-TLV. If it's set to 0, the MAC Address field gets ignored. 🍓
- R: the remaining bits in the 8-bit Flags field are reserved for further use 👑 the originator of the sub-TLV MUST always set them to 0. Intermediate routers MUST propagate them without modification. Any receiving routers MUST ignore these bits upon receipt.
- VN-ID: if the V bit is set to 1, the VN-ID field holds a 3-octet VN-ID value, which gets used to set the NVGRE Virtual Subnet Identifier (VSID; see Section 9) 🌸 if the V bit is set to 0, the VN-ID field MUST be set to zero on transmission and disregarded on receipt.
- MAC Address: if the M bit is set to 1, this field holds a 6-octet Ethernet MAC address. If the M bit is set to 0, this field MUST be set to all zeroes on transmission and disregarded on receipt. 💜
- Reserved: MUST be set to zero on transmission and disregarded on receipt. 🫶
When you're forming the NVGRE encapsulation header:
- The values of the V, M, and R bits are NOT copied into the Flags field of the NVGRE header. The Flags field of the NVGRE header is set as per [RFC7637]. 💅
- If the M bit is set to 1, the MAC Address gets copied into the Inner Destination MAC Address field of the Inner Ethernet Header (see Section 3.2 of [RFC7637]).
- If the M bit is set to 0, and the payload going through the NVGRE tunnel is an Ethernet frame, the Destination MAC Address field of the Inner Ethernet Header is just the Destination MAC Address field of the payload's Ethernet header. 🌈
- If the M bit is set to 0, and the payload going through the NVGRE tunnel is an IP or MPLS packet, the Inner Destination MAC Address field gets set to a configured value. If there's no configured value, the NVGRE tunnel cannot be used. 🙈
- If the V bit is set to 0, and the BGP UPDATE message has an AFI/SAFI other than Ethernet VPNs (EVPNs), then the NVGRE tunnel cannot be used. 😭
- Section 9 explains how the VSID field of the NVGRE encapsulation header gets set. ⭐
3.2.3. L2TPv3 (Tunnel Type 1) 🦋
when the tunnel type is L2TPv3 over IP [RFC3931], the sub-TLV length is between 4 and 12 octets, depending on how long the cookie is 🎀 the Value field of the Encapsulation sub-TLV looks like this (Figure 6):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Cookie (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: L2TPv3 Encapsulation Sub-TLV Value Field- Session ID: a non-zero 4-octet value that the advertising router assigns locally 🧚 it works as a lookup key for the context of the incoming packet.
- Cookie: an optional, variable-length value (encoded in 0 to 8 octets) that L2TPv3 uses to check that a received data message belongs to the session identified by the Session ID 🌈 how the cookie gets generated and used is as specified in [RFC3931].
The length of the cookie isn't encoded explicitly, but you can work it out as (sub-TLV length - 4) 🧮✨
3.2.4. GRE (Tunnel Type 2) 🌸
when the tunnel type is GRE [RFC2784], the sub-TLV is 4 octets long 🍓 the Value field looks like this (Figure 7):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Key (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: GRE Encapsulation Sub-TLV Value Field- GRE Key: a 4-octet field [RFC2890] that the advertising router generates 🔑 the key is optional. Unless a key value is being advertised, the GRE Encapsulation sub-TLV MUST NOT be present. 🙅♀️
3.2.5. MPLS-in-GRE (Tunnel Type 11) 💜
when the tunnel type is MPLS-in-GRE [RFC4023], the sub-TLV is 4 octets long 🦋 the Value field looks like this (Figure 8):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Key (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: MPLS-in-GRE Encapsulation Sub-TLV Value Field- GRE Key: a 4-octet field [RFC2890] that the advertising router generates 🔑 the key is optional. Unless a key value is being advertised, the MPLS-in-GRE Encapsulation sub-TLV MUST NOT be present. 🙅♀️
Note that the GRE tunnel type from Section 3.2.4 can be used instead of the MPLS-in-GRE tunnel type when you need to encapsulate MPLS in GRE 💅 including a TLV of the MPLS-in-GRE tunnel type is equivalent to including a TLV of the GRE tunnel type that also includes a Protocol Type sub-TLV (Section 3.4.1) specifying MPLS as the protocol to be encapsulated.
Although the MPLS-in-GRE tunnel type is just a special case of the GRE tunnel type and so isn't strictly necessary, it's included for reasons of backwards compatibility with, for example, implementations of [RFC8365] 🫶
3.3. Outer Encapsulation Sub-TLVs 🎀
the Encapsulation sub-TLV for a particular tunnel type lets you specify the values that go in certain fields of that tunnel type's encapsulation header 💖 but some tunnel types need an outer IP encapsulation, and some also need an outer UDP encapsulation. The Encapsulation sub-TLV for a given tunnel type usually doesn't give you a way to set values for fields of those outer IP and/or UDP encapsulations. If you need to specify values for fields of the outer encapsulation, you have to use additional sub-TLVs. This document defines two such sub-TLVs 🧚
If an outer Encapsulation sub-TLV shows up in a TLV for a tunnel type that doesn't use the matching outer encapsulation, the sub-TLV MUST be treated as if it were an unrecognized type of sub-TLV. 🚨
3.3.1. DS Field (Type Code 7) 💖
okay so most of the tunnel types in the Tunnel Encapsulation attribute need an outer IP encapsulation 🎀, and the DS Field sub-TLV can ride along in the TLV of any of those tunnel types ✨. It sets the one-octet Differentiated Services field in the outer IPv4 or IPv6 encapsulation (see [RFC2474]) 🦋. Any one-octet value can be carried 🙌. What the DSCP (Differentiated Services Code Point) field actually means is out of scope for this doc, so no drama 💅. The Value field is always a single octet.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| DS value |
+-+-+-+-+-+-+-+-+
Figure 9: DS Field Sub-TLV Value FieldBecause the DSCP reading at the recipient can be different from what the originator had in mind 👀, an implementation MAY provide a facility to use policy to filter or modify the DS field 🧚.
3.3.2. UDP Destination Port (Type Code 8) 🍓
some tunnel types need an outer UDP encapsulation 🌊. Usually each type has a standard UDP destination port, but sometimes you want a nonstandard one, and that's where this sub-TLV comes in 👑. If a tunnel type needs outer UDP and you want a port other than the standard one, you signal it with a UDP Destination Port sub-TLV 🫶. The Value is always two octets holding the port, and anything except zero works 🔢. If the reserved value zero shows up, the sub-TLV MUST be treated as malformed, according to the rules of Section 13 🚫.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Port (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: UDP Destination Port Sub-TLV Value Field3.4. Sub-TLVs for Aiding Tunnel Selection 🧭
3.4.1. Protocol Type Sub-TLV (Type Code 2) 🌈
the Protocol Type sub-TLV MAY be included in a given TLV to say which kinds of payload packets are allowed to be encapsulated with the tunnel parameters signaled in that TLV 💜. Packets with other payload types MUST NOT be encapsulated in that tunnel, no exceptions 🙅. The Value field holds a 2-octet value from IANA's "ETHER TYPES" registry [IANA-ETHERTYPES] 📋. If the reserved value 0xFFFF shows up, the sub-TLV MUST be treated as malformed according to the rules of Section 13 💀.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Protocol Type Sub-TLV Value Fieldokay this example is so good 🥹. Say there are three L2TPv3 sessions: one carrying IPv4 packets, one carrying IPv6 packets, and one carrying MPLS packets. The egress router will include three TLVs of L2TPv3 encapsulation type, each specifying a different Session ID and a different payload type 🎁. Their Protocol Type sub-TLVs will be IPv4 (protocol type = 0x0800), IPv6 (protocol type = 0x86dd), and MPLS (protocol type = 0x8847), respectively ✨. That tells the ingress routers which encapsulation info to use with each protocol type. Inserting the specified Session ID at the ingress routers lets the egress process the incoming packets correctly, according to their protocol type 🫧.
Now for the "X-in-Y" tunnel types, like MPLS-in-GRE 🧩. Only packets of payload type "X" are carried through the tunnel of type "Y". That's the same as specifying tunnel type "Y" and including a Protocol Type sub-TLV (see Section 3.4.1) that names protocol "X" 🎯. If the tunnel type is "X-in-Y", adding a Protocol Type sub-TLV for "X" is unnecessary, though harmless 🤍. Also, for "X-in-Y" tunnels, a Protocol Type sub-TLV naming anything other than "X" MUST be ignored. We'll get into that more in Section 13 👀.
3.4.2. Color Sub-TLV (Type Code 4) 🎨
the Color sub-TLV MAY be used as a way to "color" the corresponding Tunnel TLV 💅. Its Value field is eight octets long and holds a Color Extended Community, as defined in Section 4.3. For how this sub-TLV and extended community get used, check Section 8 🔍.
The format of the Value field is depicted in Figure 15.
If the Length field of a Color sub-TLV has a value other than 8, or the first two octets of its Value field are not 0x030b, the sub-TLV MUST be treated as if it were an unrecognized sub-TLV (see Section 13) 🙈.
3.5. Embedded Label Handling Sub-TLV (Type Code 9) 🏷️
certain BGP address families (corresponding to particular AFI/SAFI pairs, for example, 1/4, 2/4, 1/128, 2/128) have MPLS labels embedded in their NLRIs 🧠. "Embedded label" refers to the MPLS label embedded in an NLRI, and "labeled address family" refers to any AFI/SAFI that has embedded labels 💜.
Some tunnel types (for example, VXLAN and NVGRE) have an encapsulation header containing a virtual network identifier of some sort 🌸. The Encapsulation sub-TLVs for these tunnel types may optionally specify a value for that virtual network identifier ✨.
Here's the scenario 🎬. Say a Tunnel Encapsulation attribute is attached to an UPDATE of a labeled address family, and it's decided to use a particular tunnel (specified in one of the attribute's TLVs) for transmitting a packet that's being forwarded according to that UPDATE. When forming the encapsulation header for that packet, different deployment scenarios need different handling of the embedded label and/or the virtual network identifier 😵💫. The Embedded Label Handling sub-TLV is what controls where the embedded label and/or the virtual network identifier ends up in the encapsulation 🎀.
The Embedded Label Handling sub-TLV may be included in any TLV of the Tunnel Encapsulation attribute. If the Tunnel Encapsulation attribute is attached to an UPDATE of a non-labeled address family, then the sub-TLV MUST be disregarded 🙅♀️. If the sub-TLV sits in a TLV whose tunnel type doesn't have a virtual network identifier in its encapsulation header, the sub-TLV MUST be disregarded too 🙃. In those cases where the sub-TLV is ignored, it MUST NOT be stripped from the TLV before the route is propagated 🫶.
The sub-TLV's Length field always contains the value 1, and its Value field is a single octet. These values are defined:
1: The payload will be an MPLS packet with the embedded label at the top of its label stack.2: The embedded label is not carried in the payload but is either carried in the Virtual Network Identifier field of the encapsulation header or else ignored entirely.
If any value other than 1 or 2 is carried, the sub-TLV MUST be considered malformed, according to the procedures of Section 13 🚨.
Please see Section 9 for the details of how this sub-TLV is used when it is carried by an UPDATE of a labeled address family 📖.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| 1 or 2 |
+-+-+-+-+-+-+-+-+
Figure 12: Embedded Label Handling Sub-TLV Value Field3.6. MPLS Label Stack Sub-TLV (Type Code 10) 🥞
this sub-TLV lets an MPLS label stack [RFC3032] get associated with a particular tunnel 🚇.
The length of the sub-TLV is a multiple of 4 octets, and its Value field is a sequence of MPLS label stack entries 🧱. The first entry in the sequence is the "topmost" label, and the final entry is the "bottommost" label. When this label stack gets pushed onto a packet, this ordering MUST be preserved 🔒.
Each label stack entry has the format shown in Figure 13 👇.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: MPLS Label Stack Sub-TLV Value FieldThe fields are as defined in [RFC3032] and [RFC5462] 📚.
If a packet is headed through the tunnel identified in a particular TLV, and that TLV contains an MPLS Label Stack sub-TLV, then the label stack in the sub-TLV MUST be pushed onto the packet before any other labels get pushed onto it 🥇. (See Section 6 for further discussion.)
In particular, if the Tunnel Encapsulation attribute is attached to a BGP UPDATE of a labeled address family, the contents of the MPLS Label Stack sub-TLV MUST be pushed onto the packet before the label embedded in the NLRI gets pushed onto it 🪜.
If the MPLS Label Stack sub-TLV is included in a TLV identifying a tunnel type that uses virtual network identifiers (see Section 9), the contents of the MPLS Label Stack sub-TLV MUST be pushed onto the packet before the procedures of Section 9 are applied 💫.
The number of label stack entries in the sub-TLV MUST be determined from the Sub-TLV Length field 🔢. So it's not necessary to set the S bit in any of the label stack entries of the sub-TLV, and the setting of the S bit is ignored when parsing the sub-TLV 🙄. When the label stack entries are pushed onto a packet that already has a label stack, the S bits of all the entries being pushed MUST be cleared. When the label stack entries are pushed onto a packet that does not already have a label stack, the S bit of the bottommost label stack entry MUST be set, and the S bit of all the other label stack entries MUST be cleared 🧹.
The Traffic Class (TC) field [RFC3270][RFC5129] of each label stack entry SHOULD be set to 0, unless changed by policy at the originator of the sub-TLV 🚦. When pushing the label stack onto a packet, the TC of each label stack SHOULD be preserved, unless local policy results in a modification 🌈.
The TTL (Time to Live) field of each label stack entry SHOULD be set to 255, unless changed to some other non-zero value by policy at the originator of the sub-TLV ⏳. When pushing the label stack onto a packet, the TTL of each label stack entry SHOULD be preserved, unless local policy results in a modification to some other non-zero value. If any label stack entry in the sub-TLV has a TTL value of zero, the router pushing the stack onto a packet MUST change the value to a non-zero value, either 255 or some other value as determined by policy as discussed above 🚑.
Note that this sub-TLV can appear within a TLV identifying any type of tunnel, not just one identifying an MPLS tunnel 🌍. However, if this sub-TLV appears within a TLV identifying an MPLS tunnel (or an MPLS-in-X tunnel), it plays the same role that an MPLS Encapsulation sub-TLV would play 🎭. That's why an MPLS Encapsulation sub-TLV is not defined 🙌.
Although this specification doesn't supply detailed instructions for validating the received label stack, implementations might impose restrictions on the label stacks they can support 🧐. If an invalid or unsupported label stack is received, the tunnel MAY be treated as not feasible, according to the procedures of Section 6 💔.
3.7. Prefix-SID Sub-TLV (Type Code 11) 🦋
okay so [RFC8669] defines a BGP path attribute called the "BGP Prefix-SID attribute" 💅 and it's basically a bundle of one or more TLVs, where each one is either a Label-Index TLV or an Originator SRGB (Source Routing Global Block) TLV ✨
this document adds a Prefix-SID (Prefix Segment Identifier) sub-TLV 🎀 and its Value field can be set to any permitted value of the Value field of a BGP Prefix-SID attribute [RFC8669]. bestie, that's the whole vibe 🫶
now, [RFC8669] only defines behavior when the BGP Prefix-SID attribute is attached to routes of type IPv4/IPv6 Labeled Unicast [RFC4760][RFC8277], and it only defines the attribute's values for those cases 🙈 so the sub-TLV has similar limits. it SHOULD only be included in a BGP UPDATE message for one of the address families that [RFC8669] has defined behavior for, namely BGP IPv4/IPv6 Labeled Unicast [RFC4760] [RFC8277]. if it shows up in a BGP UPDATE for any other address family, it MUST be ignored 💀
the Prefix-SID sub-TLV can show up in a TLV identifying any type of tunnel 🌈 if an Originator SRGB is specified in the sub-TLV, that SRGB MUST be interpreted as the SRGB used by the tunnel's egress endpoint 👑 the Label-Index, if present, is the Segment Routing SID that the egress endpoint uses to represent the prefix in the NLRI field of the BGP UPDATE that the Tunnel Encapsulation attribute is attached to ✨
if a Label-Index is present in the Prefix-SID sub-TLV, then when a packet goes through the tunnel that TLV identifies, and that tunnel is from a labeled address family, the matching MPLS label MUST be pushed onto the packet's label stack 🔥 that label gets computed from the Label-Index value and the SRGB of the route's originator, as specified in Section 4.1 of [RFC8669] 🧚
the matching MPLS label gets pushed on after the MPLS Label Stack sub-TLV is processed (if there is one), as specified in Section 3.6 🍓 and it goes on before any other labels (for example, a label embedded in an UPDATE's NLRI, or a label figured out by the procedures of Section 9) 💜
last bit, and this one is important 👀 the Prefix-SID sub-TLV has slightly different semantics than the BGP Prefix-SID attribute. when the BGP Prefix-SID attribute is attached to a route, the BGP speaker that attached it is expected to be in the same Segment Routing domain as the BGP speakers that receive the route. the Label-Index tells those receivers what the Prefix-SID is for the advertised prefix in that domain 🦋 but with the Prefix-SID sub-TLV, there is NO implication that the Prefix-SID for the advertised prefix is the same across the Segment Routing domains of the speaker that originated the sub-TLV and the speaker that received it 😭 different domains, different vibes, periodt 💅
4. Extended Communities Related to the Tunnel Encapsulation Attribute 🌸
4.1. Encapsulation Extended Community 🎀
the Encapsulation Extended Community is a Transitive Opaque Extended Community 💖 its encoding is shown in Figure 14 👇
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x03 (1 octet)| 0x0c (1 octet)| Reserved (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (2 octets) | Tunnel Type (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Encapsulation Extended Communitythe high-order octet of the extended Type field is 0x03, which means it's transitive 🦋 and the low-order octet of the extended Type field is 0x0c 💅
the last two octets of the Value field encode a tunnel type ✨
this extended community can be attached to a route of any AFI/SAFI that the Tunnel Encapsulation attribute can be attached to 🌈 each one identifies a particular tunnel type, and its semantics are the same as a Tunnel TLV in a Tunnel Encapsulation attribute, as long as ALL THREE of these are true 👑
- it identifies the same tunnel type 💖
- it has a Tunnel Egress Endpoint sub-TLV where one of these two is true: a. its Address Family subfield contains zero, or b. its Address subfield contains the address of the Next Hop field of the route the Tunnel Encapsulation attribute is attached to 🧚
- it has no other sub-TLVs 🍓
a Tunnel TLV like that is called a "barebones" Tunnel TLV 🫶
the Encapsulation Extended Community was first defined in [RFC5512] 🌸 it only does a small slice of what the Tunnel Encapsulation attribute can do, but it's still used in a bunch of deployed stuff and is needed for backwards compatibility 😭 so in situations where a tunnel could be encoded as a barebones TLV, it MUST be encoded using the matching Encapsulation Extended Community 🔥 that said, an implementation MUST be prepared to process a tunnel received as a barebones TLV 💅
heads up for tunnel types of the form "X-in-Y" (like MPLS-in-GRE) ⚠️ the Encapsulation Extended Community means only packets of the payload type "X" are carried through the tunnel of type "Y". packets with other payload types MUST NOT be carried through those tunnels 💀 see also Section 2 🎀
for the rest of this spec, whenever a route is said to contain a Tunnel Encapsulation attribute with a TLV for a particular tunnel type, it implicitly includes the case where the route contains an Encapsulation Extended Community for that tunnel type 🦋
4.2. Router's MAC Extended Community 🌈
[EVPN-INTER-SUBNET] defines a router's MAC Extended Community 💜 like the name says, it carries the MAC address of the advertising router ✨ the VXLAN and NVGRE Encapsulation sub-TLVs can also optionally carry a router's MAC, so a conflict can happen if BOTH the Router's MAC Extended Community AND one of those Encapsulation sub-TLVs are present at the same time with different values 😬 in that case, the information in the Router's MAC Extended Community MUST be used 👑
4.3. Color Extended Community 💖
the Color Extended Community is a Transitive Opaque Extended Community, with the encoding in Figure 15 🌸
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x03 (1 octet)| 0x0b (1 octet)| Flags (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color Value (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Color Extended Communitythe high-order octet of the extended Type field is 0x03, meaning it's transitive ✨ the low-order octet of the extended Type field for this community is 0x0b 🦋 the color value is user defined and configured locally 🧚
no flags are defined in this document, so this field MUST be set to zero by the originator and ignored by the receiver 🫶 and the value MUST NOT be changed when this extended community is propagated 🔥
the Color Value field is encoded as a 4-octet value by the administrator, and it's outside the scope of this document 🍓 for how to use this extended community, please see Section 8 💅
5. Special Considerations for IP-in-IP Tunnels 🌈
in certain situations with an IP fabric underlay, you could have a tunnel overlay with the tunnel type IP-in-IP 🌸 the egress BGP speaker can advertise the IP-in-IP tunnel endpoint address in the Tunnel Egress Endpoint sub-TLV 💜 when the tunnel type of the TLV is IP-in-IP, it won't have a virtual network identifier ✨ but the tunnel egress endpoint address can still be used to identify the forwarding table to use when making the forwarding decisions for forwarding the payload 👑
6. Semantics and Usage of the Tunnel Encapsulation Attribute ✨
Okay bestie, so the BGP Tunnel Encapsulation attribute MAY be carried in any BGP UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6 Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast), 1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast), or 25/70 (Ethernet VPN, usually known as EVPN). Using the attribute in BGP UPDATE messages of other AFI/SAFIs is outside the scope of this document 🎀
The order of the TLVs inside the Tunnel Encapsulation attribute means absolutely nothing 🙈 You can have multiple TLVs for the same tunnel type, and each one is treated as describing a different tunnel. (This also applies if the Encapsulation Extended Community encoding is used.)
Whether a Tunnel Encapsulation attribute gets attached to a given BGP UPDATE is decided by policy. The set of TLVs and sub-TLVs inside it is also decided by policy 💜
Let's say that:
- a given packet P must be forwarded by router R;
- the path along which P is to be forwarded is determined by BGP UPDATE U;
- UPDATE U has a Tunnel Encapsulation attribute, containing at least one TLV that identifies a "feasible tunnel" for packet P. A tunnel is considered feasible if it has the following four properties:
- The tunnel type is supported (that is, router R knows how to set up tunnels of that type, how to create the encapsulation header for tunnels of that type, etc.).
- The tunnel is of a type that can be used to carry packet P (for example, an MPLS-in-UDP tunnel would not be a feasible tunnel for carrying an IP packet, unless the IP packet can first be encapsulated in a MPLS packet).
- The tunnel is specified in a TLV whose Tunnel Egress Endpoint sub-TLV identifies an IP address that is reachable. The reachability condition is evaluated as per [RFC4271]. If the IP address is reachable via more than one forwarding table, local policy is used to determine which table to use.
- There is no local policy that prevents the use of the tunnel.
Then router R MUST send packet P through one of the feasible tunnels identified in the Tunnel Encapsulation attribute of UPDATE U. This is the big rule, so it's non-negotiable 🔥
If the Tunnel Encapsulation attribute has several TLVs (so several feasible tunnels), router R may choose any one of those tunnels based on local policy. If any Tunnel TLV has one or more Color sub-TLVs (Section 3.4.2) and/or the Protocol Type sub-TLV (Section 3.4.1), those sub-TLVs may influence the choice of tunnel. Lots of other factors, like minimizing encapsulation-header overhead, could also influence the selection 🦋
Reachability to the egress endpoint address of a tunnel can change over time, and that directly affects whether the tunnel is feasible. A tunnel that isn't feasible at one moment may become feasible later, once its egress endpoint address is reachable. The router may start using the newly feasible tunnel instead of an existing one. How that decision gets made is outside the scope of this document 🌸
Once it's decided to send a packet through the tunnel specified in a particular Tunnel TLV of a particular Tunnel Encapsulation attribute, the tunnel's egress endpoint address is the IP address in the Tunnel Egress Endpoint sub-TLV. If that sub-TLV's Value field is all zeroes, then the tunnel's egress endpoint is the address of the next hop of the BGP UPDATE that contains the Tunnel Encapsulation attribute. That means the Network Address of Next Hop field of the MP_REACH_NLRI attribute if the encoding of [RFC4760] is in use, or the NEXT_HOP attribute otherwise. The egress endpoint address usually shows up in a Destination Address field of the encapsulation ✨
The full set of procedures for sending a packet through a particular tunnel type to a particular tunnel egress endpoint depends on the tunnel type and is outside the scope of this document. Some tunnel types may need an explicit tunnel setup protocol before they can carry data. Other tunnel types may not need any tunnel setup protocol at all 🧚
Sending a packet through a tunnel always requires encapsulating it with an encapsulation header that fits the tunnel type. The Encapsulation sub-TLV may influence what goes in that header. If there's no Encapsulation sub-TLV, the router sending the packet through the tunnel must already have a priori knowledge (for example, from provisioning) of how to fill in the various fields of the encapsulation header 🫶
A Tunnel Encapsulation attribute may contain several TLVs that all specify the same tunnel type. Each TLV should be considered as specifying a different tunnel. Two tunnels of the same type can have different Tunnel Egress Endpoint sub-TLVs, different Encapsulation sub-TLVs, and so on. Choosing between two such tunnels is a matter of local policy 💅
Once router R has decided to send packet P through a particular tunnel, it encapsulates packet P appropriately and then forwards it along the route that leads to the tunnel's egress endpoint. That route may itself be a BGP route with a Tunnel Encapsulation attribute. If it is, the encapsulated packet is treated as the payload and gets encapsulated according to the Tunnel Encapsulation attribute of that route. In other words, tunnels can be "stacked" 🥞
Notwithstanding anything said in this document, a BGP speaker MAY have local policy that influences the choice of tunnel and the way the encapsulation is formed. A BGP speaker MAY also have local policy that tells it to ignore the Tunnel Encapsulation attribute entirely or in part. Of course, interoperability issues must be considered when such policies are put into place ⚠️
See also Section 13, which has further specification on validation and exception cases.
7. Routing Considerations 🛣️
7.1. Impact on the BGP Decision Process
The Tunnel Encapsulation attribute affects the BGP best route-selection algorithm. If a route includes the Tunnel Encapsulation attribute, and that attribute includes no feasible tunnel, then that route MUST NOT be considered resolvable for the purposes of the route resolvability condition ([RFC4271], Section 9.1.2.1). Not resolvable means not used, bestie 🙅♀️
7.2. Looping, Mutual Recursion, Etc.
Picture a packet destined for address X. Now suppose a BGP UPDATE for address prefix X carries a Tunnel Encapsulation attribute that specifies a tunnel egress endpoint of Y, and a BGP UPDATE for address prefix Y carries a Tunnel Encapsulation attribute that specifies a tunnel egress endpoint of X. It's easy to see this can't end well 💀 [RFC4271] describes an analogous case as mutually recursive routes.
This could happen because of misconfiguration, whether accidental or intentional. It could also happen if a malicious agent altered the Tunnel Encapsulation attribute. Implementations should be aware that such an attack will result in unresolvable BGP routes due to the mutually recursive relationship. This document does not specify a maximum number of recursions. That's an implementation-specific matter 🔍
Improper setting (or malicious altering) of the Tunnel Encapsulation attribute could also cause data packets to loop. Suppose a BGP UPDATE for address prefix X carries a Tunnel Encapsulation attribute that specifies a tunnel egress endpoint of Y. Suppose router R receives and processes that advertisement. When router R receives a packet destined for X, it applies the encapsulation and sends the encapsulated packet to Y. Y decapsulates the packet and forwards it further. If Y is further away from X than router R is, the path from Y to X may traverse R. That would cause a long-lasting routing loop 😭 The control plane itself cannot detect this situation, though a TTL field in the payload packets would prevent any given packet from looping infinitely.
During the deployment of the techniques described in this document, operators are encouraged to avoid mutually recursive route and/or tunnel dependencies. Such scenarios are more likely to arise when the tunnel egress endpoint for a given prefix differs from the address of the next hop for that prefix 👀
8. Recursive Next-Hop Resolution 🔁
Suppose that:
- a given packet P must be forwarded by router R1;
- the path along which P is to be forwarded is determined by BGP UPDATE U1;
- UPDATE U1 does not have a Tunnel Encapsulation attribute;
- the address of the next hop of UPDATE U1 is router R2;
- the best route to router R2 is a BGP route that was advertised in UPDATE U2; and
- UPDATE U2 has a Tunnel Encapsulation attribute.
Then packet P MUST be sent through one of the tunnels identified in the Tunnel Encapsulation attribute of UPDATE U2. See Section 6 for further details.
But wait, there's a twist ✨ Suppose one of the TLVs in U2's Tunnel Encapsulation attribute contains one or more Color sub-TLVs. In that case, packet P MUST NOT be sent through the tunnel contained in that TLV, unless U1 is carrying a Color Extended Community that is identified in one of U2's Color sub-TLVs 🚫
The procedures in this section presuppose that U1's address of the next hop resolves to a BGP route, and that U2's next hop resolves (perhaps after further recursion) to a non-BGP route.
9. Use of Virtual Network Identifiers and Embedded Labels When Imposing a Tunnel Encapsulation 🏷️
If the TLV specifying a tunnel contains an MPLS Label Stack sub-TLV, then when sending a packet through that tunnel, the procedures of Section 3.6 are applied before the procedures of this section.
If the TLV specifying a tunnel contains a Prefix-SID sub-TLV, the procedures of Section 3.7 are applied before the procedures of this section. If that TLV also contains an MPLS Label Stack sub-TLV, the procedures of Section 3.6 are applied before the procedures of Section 3.7 🧠
9.1. Tunnel Types without a Virtual Network Identifier Field
If a Tunnel Encapsulation attribute is attached to an UPDATE of a labeled address family, there will be one or more labels specified in the UPDATE's NLRI. When a packet is sent through a tunnel specified in one of the attribute's TLVs, and that tunnel type does not contain a Virtual Network Identifier field, the label or labels from the NLRI are pushed on the packet's label stack. The resulting MPLS packet is then further encapsulated, as specified by the TLV 🌈
9.2. Tunnel Types with a Virtual Network Identifier Field 🦋
okay bestie, two of the tunnel types you can name in a Tunnel Encapsulation TLV have Virtual Network Identifier fields sitting in their encapsulation headers 💅. In VXLAN it's the VNI (VXLAN Network Identifier) field, and in NVGRE it's the VSID (Virtual Subnet Identifier) field ✨.
When one of these tunnel encapsulations gets slapped onto a packet, what goes in the Virtual Network Identifier field depends on the Encapsulation sub-TLV (if there is one) 🎀. And if the Tunnel Encapsulation attribute is riding along in a BGP UPDATE for a labeled address family, the Embedded Label Handling sub-TLV (if present) gets a say too 🌸.
This section is where we spell out how to pick the value for that field. These procedures only kick in when the tunnel type is VXLAN or NVGRE, so don't go applying them to anything else 🙈.
9.2.1. Unlabeled Address Families
This subsection applies when:
- the Tunnel Encapsulation attribute is carried in a BGP UPDATE of an unlabeled address family,
- at least one of the attribute's TLVs identifies a tunnel type that uses a virtual network identifier, and
- it has been determined to send a packet through one of those tunnels.
If the TLV identifying the tunnel contains an Encapsulation sub-TLV whose V bit is set to 1, the Virtual Network Identifier field of the encapsulation header is set to the value of the Virtual Network Identifier field of the Encapsulation sub-TLV 💖.
Otherwise, the Virtual Network Identifier field of the encapsulation header is set to a configured value. If there is no configured value, the tunnel cannot be used 😭.
9.2.2. Labeled Address Families
This subsection applies when:
- the Tunnel Encapsulation attribute is carried in a BGP UPDATE of a labeled address family,
- at least one of the attribute's TLVs identifies a tunnel type that uses a virtual network identifier, and
- it has been determined to send a packet through one of those tunnels.
9.2.2.1. When a Valid VNI Has Been Signaled
If the TLV identifying the tunnel contains an Encapsulation sub-TLV whose V bit is set to 1, the Virtual Network Identifier field of the encapsulation header is set to the value of the Virtual Network Identifier field of the Encapsulation sub-TLV. However, the Embedded Label Handling sub-TLV will determine label processing as described below 🧚.
- If the TLV contains an Embedded Label Handling sub-TLV whose value is 1, the embedded label (from the NLRI of the route that is carrying the Tunnel Encapsulation attribute) appears at the top of the MPLS label stack in the encapsulation payload.
- If the TLV does not contain an Embedded Label Handling sub-TLV, or it contains an Embedded Label Handling sub-TLV whose value is 2, the embedded label is ignored entirely.
9.2.2.2. When a Valid VNI Has Not Been Signaled
If the TLV identifying the tunnel does not contain an Encapsulation sub-TLV whose V bit is set to 1, the Virtual Network Identifier field of the encapsulation header is set as follows 🌈:
- If the TLV contains an Embedded Label Handling sub-TLV whose value is 1, then the Virtual Network Identifier field of the encapsulation header is set to a configured value.
If there is no configured value, the tunnel cannot be used.
The embedded label (from the NLRI of the route that is carrying the Tunnel Encapsulation attribute) appears at the top of the MPLS label stack in the encapsulation payload.
- If the TLV does not contain an Embedded Label Handling sub-TLV, or if it contains an Embedded Label Handling sub-TLV whose value is 2, the embedded label is copied into the lower 3 octets of the Virtual Network Identifier field of the encapsulation header.
In this case, the payload may or may not contain an MPLS label stack, depending upon other factors. If the payload does contain an MPLS label stack, the embedded label does not appear in that stack.
10. Applicability Restrictions 🚧
In a given UPDATE of a labeled address family, the label embedded in the NLRI is generally a label that is meaningful only to the router represented by the address of the next hop. Certain of the procedures of Sections 9.2.2.1 or 9.2.2.2 cause the embedded label to be carried by a data packet to the router whose address appears in the Tunnel Egress Endpoint sub-TLV. If the Tunnel Egress Endpoint sub-TLV does not identify the same router represented by the address of the next hop, sending the packet through the tunnel may cause the label to be misinterpreted at the tunnel's egress endpoint. This may cause misdelivery of the packet. Avoiding this unfortunate outcome is a matter of network planning and design and is outside the scope of this document 😬.
Heads up: if the Tunnel Encapsulation attribute is attached to a VPN-IP route [RFC4364], if Inter-AS "option b" (see Section 10 of [RFC4364]) is being used, and if the Tunnel Egress Endpoint sub-TLV contains an IP address that is not in the same AS as the router receiving the route, it is very likely that the embedded label has been changed. Therefore, use of the Tunnel Encapsulation attribute in an "Inter-AS option b" scenario is not recommended 🙅♀️.
Other documents may define other ways to signal tunnel information in BGP. For example, [RFC6514] defines the "P-Multicast Service Interface Tunnel" (PMSI Tunnel) attribute. In this specification, we do not consider the effects of advertising the Tunnel Encapsulation attribute in conjunction with other forms of signaling tunnels. Any document specifying such joint use MUST provide details as to how interactions should be handled 🫶.
11. Scoping 🔒
The Tunnel Encapsulation attribute is defined as a transitive attribute, so that it may be passed along by BGP speakers that do not recognize it. However, the Tunnel Encapsulation attribute MUST be used only within a well-defined scope, for example, within a set of ASes that belong to a single administrative entity. If the attribute is distributed beyond its intended scope, packets may be sent through tunnels in a manner that is not intended 👀.
To prevent the Tunnel Encapsulation attribute from being distributed beyond its intended scope, any BGP speaker that understands the attribute MUST be able to filter the attribute from incoming BGP UPDATE messages. When the attribute is filtered from an incoming UPDATE, the attribute is neither processed nor distributed. This filtering SHOULD be possible on a per-BGP-session basis; finer granularities (for example, per route and/or per attribute TLV) MAY be supported. For each external BGP (EBGP) session, filtering of the attribute on incoming UPDATEs MUST be enabled by default 💅.
In addition, any BGP speaker that understands the attribute MUST be able to filter the attribute from outgoing BGP UPDATE messages. This filtering SHOULD be possible on a per-BGP-session basis. For each EBGP session, filtering of the attribute on outgoing UPDATEs MUST be enabled by default 🌸.
Since the Encapsulation Extended Community provides a subset of the functionality of the Tunnel Encapsulation attribute, these considerations apply equally in its case:
- Any BGP speaker that understands it MUST be able to filter it from incoming BGP UPDATE messages.
- It MUST be possible to filter the Encapsulation Extended Community from outgoing messages.
- In both cases, this filtering MUST be enabled by default for EBGP sessions.
12. Operational Considerations 🛠️
A potential operational difficulty arises when tunnels are used, if the size of packets entering the tunnel exceeds the maximum transmission unit (MTU) the tunnel is capable of supporting. This difficulty can be exacerbated by stacking multiple tunnels, since each stacked tunnel header further reduces the supportable MTU. This issue is long-standing and well-known. The tunnel signaling provided in this specification does nothing to address this issue, nor to aggravate it (except insofar as it may further increase the popularity of tunneling) 🍓.
13. Validation and Error Handling ✨
okay so bestie, the Tunnel Encapsulation attribute is basically a sequence of TLVs, and each TLV is its own sequence of sub-TLVs 🎀 The Length field tells you where a TLV ends, and the same goes for a sub-TLV. A TLV's final octet MUST also be the final octet of its final sub-TLV. If that's not true, the TLV is malformed and the "Treat-as-withdraw" procedure of [RFC7606] gets applied. no cap, that's a hard rule 💅
If the attribute has no valid TLVs at all, or it doesn't have the transitive bit set, the "Treat-as-withdraw" procedure of [RFC7606] gets applied too 🥺
Now the super important part for unrecognized stuff 🦋 Say a BGP speaker parses the attribute just fine but there's a TLV with a tunnel type it doesn't know. That speaker MUST NOT consider the whole attribute malformed. It MUST just interpret the attribute as if that TLV wasn't there at all. And if the route carrying the attribute gets propagated, that unrecognized TLV MUST remain in the attribute. It's giving "I don't know you, but I'm not gonna throw you out" energy 🫶
Next up, duplicates 👑 These sub-TLVs MUST NOT occur more than once in a given Tunnel TLV: Tunnel Egress Endpoint (we'll get to it below), Encapsulation, DS, UDP Destination Port, Embedded Label Handling, MPLS Label Stack, and Prefix-SID. If a Tunnel TLV has more than one of any of them, all but the first occurrence of each sub-TLV type MUST be disregarded. But the Tunnel TLV containing them MUST NOT be considered malformed, and all the sub-TLVs MUST be propagated if the route carrying the Tunnel Encapsulation attribute gets propagated. so they get ignored, not punished 🌸
Some sub-TLVs are allowed to show up zero or more times in a given Tunnel TLV: Protocol Type and Color. Every single occurrence of those counts, so they're meaningful. For example, the Color sub-TLV can appear several times to give a tunnel multiple colors 🌈
If a TLV has a sub-TLV that a BGP speaker doesn't recognize, that speaker MUST process the TLV as if the unrecognized sub-TLV wasn't present. And if the route gets propagated, the unrecognized sub-TLV MUST remain in the attribute 🍓
In general, if a TLV has a sub-TLV that's malformed, that sub-TLV MUST be treated as if it were an unrecognized sub-TLV. BUT there's one exception, and it's a big one 😭 If a TLV contains a malformed Tunnel Egress Endpoint sub-TLV (as defined in Section 3.1), the entire TLV MUST be ignored and MUST be removed from the Tunnel Encapsulation attribute before the route carrying that attribute is distributed. Tunnel Egress Endpoint is the main character, and if it's broken the whole TLV gets yeeted 💀
Also, for any UPDATE whose AFI/SAFI is one of the ones explicitly listed in the first paragraph of Section 6, a TLV that doesn't contain exactly one Tunnel Egress Endpoint sub-TLV MUST be treated as if it had a malformed Tunnel Egress Endpoint sub-TLV. so exactly one is the vibe, anything else is a no-go 🙈
Last one in this bit, and it's kinda subtle 🧚 A TLV for a particular tunnel type can contain a sub-TLV that doesn't make any sense for that tunnel type. Like, maybe there's a UDP Destination Port sub-TLV but the tunnel type doesn't use UDP encapsulation at all. Or an "X-in-Y" tunnel has a Protocol Type sub-TLV that says something other than "X". Those sub-TLVs MUST be disregarded. They MUST NOT affect how the encapsulation header gets created. However, the sub-TLV MUST NOT be considered malformed, and it MUST NOT be removed from the TLV before the route carrying the Tunnel Encapsulation attribute is distributed. An implementation MAY log a message when it runs into one of these, which is a cute little optional flex 🎀
14. IANA Considerations 🌸
ok so IANA has made the updates described in the following subsections 💅 Every registration procedure listed here follows its definition in [RFC8126], so you know where to look.
14.1. Obsoleting RFC 5512
Because this document obsoletes RFC 5512, IANA has updated references to RFC 5512 so they point to this document in the following registries:
- "Border Gateway Protocol (BGP) Extended Communities" registry [IANA-BGP-EXT-COMM]
- "Border Gateway Protocol (BGP) Parameters" registry [IANA-BGP-PARAMS]
- "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry [IANA-BGP-TUNNEL-ENCAP]
- "Subsequent Address Family Identifiers (SAFI) Parameters" registry [IANA-SAFI]
14.2. Obsoleting Code Points Assigned by RFC 5566
Since this document obsoletes RFC 5566, the code points that RFC assigned are obsoleted too 🥀 Specifically, the following code points have been marked as deprecated.
In the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry [IANA-BGP-TUNNEL-ENCAP]:
+=======+==========================================================+
| Value | Name |
+=======+==========================================================+
| 3 | Transmit tunnel endpoint (DEPRECATED) |
+-------+----------------------------------------------------------+
| 4 | IPsec in Tunnel-mode (DEPRECATED) |
+-------+----------------------------------------------------------+
| 5 | IP in IP tunnel with IPsec Transport Mode (DEPRECATED) |
+-------+----------------------------------------------------------+
| 6 | MPLS-in-IP tunnel with IPsec Transport Mode (DEPRECATED) |
+-------+----------------------------------------------------------+
Table 1And in the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry [IANA-BGP-TUNNEL-ENCAP]:
+=======+=========================================+
| Value | Name |
+=======+=========================================+
| 3 | IPsec Tunnel Authenticator (DEPRECATED) |
+-------+-----------------------------------------+
Table 214.3. Border Gateway Protocol (BGP) Tunnel Encapsulation Grouping
IANA has created a brand new registry grouping named "Border Gateway Protocol (BGP) Tunnel Encapsulation" [IANA-BGP-TUNNEL-ENCAP]. A new family, very cute 🎀
14.4. BGP Tunnel Encapsulation Attribute Tunnel Types
IANA has moved the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry so it sits under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" grouping [IANA-BGP-TUNNEL-ENCAP] 🦋
14.5. Subsequent Address Family Identifiers
IANA has modified the "SAFI Values" registry [IANA-SAFI] to show that the Encapsulation SAFI (value 7) is obsoleted 💀 This document is listed as the reference for that change.
14.6. BGP Tunnel Encapsulation Attribute Sub-TLVs
IANA has moved the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry so it lives under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" grouping [IANA-BGP-TUNNEL-ENCAP] 🧚
IANA has also included the following note in the registry:
| If the Sub-TLV Type is in the range from 0 to 127 (inclusive), the
| Sub-TLV Length field contains one octet. If the Sub-TLV Type is
| in the range from 128 to 255 (inclusive), the Sub-TLV Length field
| contains two octets.IANA has updated the registration procedures for this registry too, and they now look like this:
+=========+=========================+
| Range | Registration Procedures |
+=========+=========================+
| 1-63 | Standards Action |
+---------+-------------------------+
| 64-125 | First Come First Served |
+---------+-------------------------+
| 126-127 | Experimental Use |
+---------+-------------------------+
| 128-191 | Standards Action |
+---------+-------------------------+
| 192-252 | First Come First Served |
+---------+-------------------------+
| 253-254 | Experimental Use |
+---------+-------------------------+
Table 3IANA has added the following entries to this registry 🍓
+=======+=========================+===========+
| Value | Description | Reference |
+=======+=========================+===========+
| 0 | Reserved | RFC 9012 |
+-------+-------------------------+-----------+
| 6 | Tunnel Egress Endpoint | RFC 9012 |
+-------+-------------------------+-----------+
| 7 | DS Field | RFC 9012 |
+-------+-------------------------+-----------+
| 8 | UDP Destination Port | RFC 9012 |
+-------+-------------------------+-----------+
| 9 | Embedded Label Handling | RFC 9012 |
+-------+-------------------------+-----------+
| 10 | MPLS Label Stack | RFC 9012 |
+-------+-------------------------+-----------+
| 11 | Prefix-SID | RFC 9012 |
+-------+-------------------------+-----------+
| 255 | Reserved | RFC 9012 |
+-------+-------------------------+-----------+
Table 414.7. Flags Field of VXLAN Encapsulation Sub-TLV
IANA has created a registry named "Flags Field of VXLAN Encapsulation Sub-TLVs" under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" grouping [IANA-BGP-TUNNEL-ENCAP]. The registration policy for this registry is "Standards Action". The minimum possible value is 0, and the maximum is 7 ✨
The initial values for this new registry are shown in Table 5.
+==============+=================+===========+
| Bit Position | Description | Reference |
+==============+=================+===========+
| 0 | V (VN-ID) | RFC 9012 |
+--------------+-----------------+-----------+
| 1 | M (MAC Address) | RFC 9012 |
+--------------+-----------------+-----------+
Table 514.8. Flags Field of NVGRE Encapsulation Sub-TLV
IANA has created a registry named "Flags Field of NVGRE Encapsulation Sub-TLVs" under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" grouping [IANA-BGP-TUNNEL-ENCAP]. The registration policy for this registry is "Standards Action". The minimum possible value is 0, and the maximum is 7 🫶
The initial values for this new registry are shown in Table 6.
+==============+=================+===========+
| Bit Position | Description | Reference |
+==============+=================+===========+
| 0 | V (VN-ID) | RFC 9012 |
+--------------+-----------------+-----------+
| 1 | M (MAC Address) | RFC 9012 |
+--------------+-----------------+-----------+
Table 614.9. Embedded Label Handling Sub-TLV 🎀
okay bestie, IANA made a brand new registry called "Embedded Label Handling Sub-TLVs" 🦋 It lives under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" grouping [IANA-BGP-TUNNEL-ENCAP]. The registration policy is "Standards Action" 💅 and the values can run from 0 all the way up to 255 ✨
The starting values are in Table 7 🌸
+=======+=====================================+===========+
| Value | Description | Reference |
+=======+=====================================+===========+
| 0 | Reserved | RFC 9012 |
+-------+-------------------------------------+-----------+
| 1 | Payload of MPLS with embedded label | RFC 9012 |
+-------+-------------------------------------+-----------+
| 2 | No embedded label in payload | RFC 9012 |
+-------+-------------------------------------+-----------+
Table 714.10. Color Extended Community Flags 🌈
another one, same vibe! IANA made a registry called "Color Extended Community Flags" 💖 It also sits under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" grouping [IANA-BGP-TUNNEL-ENCAP]. The registration policy is "Standards Action" again 👑 and the values go from 0 up to 15 🍓
This registry has three columns: "Bit Position", "Description", and "Reference" 🧚 Nothing has been registered in it yet, so it's a totally empty canvas rn ✨
15. Security Considerations 🔐
okay this section is SERIOUS, so read it with your whole brain 🥺
As Section 11 explains, the Tunnel Encapsulation attribute is meant to be used only inside a well-defined scope 🫶 Think of a set of ASes that all belong to one administrative entity. As long as the filtering mechanisms from that section are applied diligently, an attacker sitting outside the scope couldn't use the Tunnel Encapsulation attribute to attack anyone 🙌 That still leaves two scary questions: attackers inside the scope (like a compromised router 😭) and filtering failures that let an outside attack slip through 💀
As [RFC4272] explains, BGP is vulnerable to traffic-diversion attacks 🙈 The Tunnel Encapsulation attribute gives attackers a brand new way to divert traffic off its normal path 😬 This is especially true when the Tunnel Egress Endpoint sub-TLV is used. It's extra spicy because traffic can be tunneled to a far-away target across the network in between, so an attack could succeed more easily, since less infrastructure would need to be compromised 💅 The possible fallout includes "hijacking" of traffic (an unwanted node getting inserted into the path, which lets someone inspect or modify traffic, or dodge security controls) or denial of service (sending traffic to a node that doesn't want it) 💔
To reduce the risk of traffic being diverted away from its intended destination, Section 3.1.1 offers an optional procedure. It checks that the destination given in a Tunnel Egress Endpoint sub-TLV is inside the AS that originated the route 🚨 If it passes, you get some level of assurance that the tunneled traffic is heading to the same destination AS it would have reached without the Tunnel Encapsulation attribute 🎀
Here's the catch, though: as RFC 4272 explains, an attacker can announce an inaccurate AS_PATH 😤 So an attacker who can inject a Tunnel Egress Endpoint sub-TLV could also craft an AS_PATH that sails right through the Section 3.1.1 checks 🙃 BGP origin validation [RFC6811] and BGPsec [RFC8205] can help increase confidence that the origins being validated haven't been faked 🛡️
Lots of tunnels carry traffic with an embedded destination address that comes from a non-global namespace 🌍 MPLS VPNs are a classic example ✨ If a tunnel crosses from one namespace into another without the necessary translation for the embedded address(es), traffic can be misdelivered 😱 And if that traffic has confidential data that isn't protected some other way (like end-to-end encryption), that confidential info could get exposed 💀 Keeping the Tunnel Encapsulation attribute inside a well-defined scope makes this way less likely to happen 🫶 Check out the discussion of "option b" in Section 10 if you want to dig into one scenario like this 🧚
RFC 8402 specifies that "SR domain boundary routers MUST filter any external traffic" ([RFC8402], Section 8.1) 👑 For these purposes, traffic introduced into an SR domain using the Prefix-SID sub-TLV is treated as lying within the SR domain 🌸 Even if the Prefix-SIDs used by the routers at the two ends of the tunnel are different (as discussed in Section 3.7), it still counts 🙌 That means the duty to filter external traffic stretches to every router taking part in these tunnels 🔥
16. References 📚
16.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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/info/rfc2784>.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, DOI 10.17487/RFC2890, September 2000,
<https://www.rfc-editor.org/info/rfc2890>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, DOI 10.17487/RFC3270, May 2002,
<https://www.rfc-editor.org/info/rfc3270>.
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
"Layer Two Tunneling Protocol - Version 3 (L2TPv3)",
RFC 3931, DOI 10.17487/RFC3931, March 2005,
<https://www.rfc-editor.org/info/rfc3931>.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
"Encapsulating MPLS in IP or Generic Routing Encapsulation
(GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,
<https://www.rfc-editor.org/info/rfc4023>.
[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,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January
2008, <https://www.rfc-editor.org/info/rfc5129>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
2009, <https://www.rfc-editor.org/info/rfc5462>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811,
DOI 10.17487/RFC6811, January 2013,
<https://www.rfc-editor.org/info/rfc6811>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153,
RFC 6890, DOI 10.17487/RFC6890, April 2013,
<https://www.rfc-editor.org/info/rfc6890>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>.
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
Virtualization Using Generic Routing Encapsulation",
RFC 7637, DOI 10.17487/RFC7637, September 2015,
<https://www.rfc-editor.org/info/rfc7637>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah,
A., and H. Gredler, "Segment Routing Prefix Segment
Identifier Extensions for BGP", RFC 8669,
DOI 10.17487/RFC8669, December 2019,
<https://www.rfc-editor.org/info/rfc8669>.16.2. Informative References 📚
okay so these are the informative ones, bestie. you don't have to read them to implement this, but they're the receipts 💅
- [EVPN-INTER-SUBNET] Sajassi, A., Salam, S., Thoria, S., Drake, J. E., and J. Rabadan, "Integrated Routing and Bridging in EVPN", Work in Progress, Internet-Draft, draft-ietf-bess-evpn-inter-subnet-forwarding-13, 10 February 2021,
<https://tools.ietf.org/html/draft-ietf-bess-evpn-inter-subnet-forwarding-13>. 🦋 - [IANA-ADDRESS-FAM] IANA, "Address Family Numbers",
<https://www.iana.org/assignments/address-family-numbers/>. 🌸 - [IANA-BGP-EXT-COMM] IANA, "Border Gateway Protocol (BGP) Extended Communities",
<https://www.iana.org/assignments/bgp-extended-communities/>. 🎀 - [IANA-BGP-PARAMS] IANA, "Border Gateway Protocol (BGP) Parameters",
<https://www.iana.org/assignments/bgp-parameters/>. 🧚 - [IANA-BGP-TUNNEL-ENCAP] IANA, "Border Gateway Protocol (BGP) Tunnel Encapsulation",
<https://www.iana.org/assignments/bgp-tunnel-encapsulation/>. 💜 - [IANA-ETHERTYPES] IANA, "IEEE 802 Numbers: ETHER TYPES",
<https://www.iana.org/assignments/ieee-802-numbers/>. ✨ - [IANA-SAFI] IANA, "Subsequent Address Family Identifiers (SAFI) Parameters",
<https://www.iana.org/assignments/safi-namespace/>. 🍓 - [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006,
<https://www.rfc-editor.org/info/rfc4272>. 🔥 this one's about BGP security, so it's a must-read vibe. - [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006,
<https://www.rfc-editor.org/info/rfc4364>. 👑 - [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC 5512, DOI 10.17487/RFC5512, April 2009,
<https://www.rfc-editor.org/info/rfc5512>. 🌈 - [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009,
<https://www.rfc-editor.org/info/rfc5565>. 🫶 - [RFC5566] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel Encapsulation Attribute", RFC 5566, DOI 10.17487/RFC5566, June 2009,
<https://www.rfc-editor.org/info/rfc5566>. 🔒 - [RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load-Balancing for Mesh Softwires", RFC 5640, DOI 10.17487/RFC5640, August 2009,
<https://www.rfc-editor.org/info/rfc5640>. ⭐ - [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>. 🦋 - [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, "Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/RFC7510, April 2015,
<https://www.rfc-editor.org/info/rfc7510>. 🌸 - [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017,
<https://www.rfc-editor.org/info/rfc8205>. 🔐 - [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
<https://www.rfc-editor.org/info/rfc8277>. 🎀 - [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., Uttaro, J., and W. Henderickx, "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 10.17487/RFC8365, March 2018,
<https://www.rfc-editor.org/info/rfc8365>. 💖 this is the big EVPN one, and it shows up again in Appendix A! - [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018,
<https://www.rfc-editor.org/info/rfc8402>. 🧚
Appendix A. Impact on RFC 8365
okay bestie, this appendix is the "heads up, we changed some stuff that touches RFC 8365" section 🫶
[RFC8365] references RFC 5512 for its definition of the BGP Encapsulation Extended Community. That extended community is now defined in this document, in a way consistent with its previous definition. ✨
Section 6 of [RFC8365] talks about the use of the Encapsulation Extended Community to allow Network Virtualization Edge (NVE) devices to signal their supported encapsulations. We note that with the introduction of this specification, the Tunnel Encapsulation attribute can also be used for this purpose. 🦋 For purposes where RFC 8365 talks about "advertising supported encapsulations" (for example, in the second paragraph of Section 6), encapsulations advertised using the Tunnel Encapsulation attribute should be considered equally with those advertised using the Encapsulation Extended Community. 💜
In particular, a review of Section 8.3.1 of [RFC8365] is called for, to consider whether the introduction of the Tunnel Encapsulation attribute creates a need for any revisions to the split-horizon procedures. 🔥 that's a whole vibe check on the split-horizon stuff.
[RFC8365] also refers to a draft version of this specification in the final paragraph of Section 5.1.3. That paragraph references Section 8.2.2.2 of the draft. In this document, the correct reference would be Section 9.2.2.2. 🌈 There are no substantive differences between the section in the referenced draft version and that in this document. 🎀 so nothing changed in meaning, just the numbering.
Acknowledgments
this part is the shoutout section, and it's so wholesome 🥹
This document contains text from RFC 5512, authored by Pradosh Mohapatra and Eric Rosen. The authors of the current document wish to thank them for their contribution. RFC 5512 itself built upon prior work by Gargi Nalawade, Ruchi Kapoor, Dan Tappan, David Ward, Scott Wainner, Simon Barber, Lili Wang, and Chris Metz, whom the authors also thank for their contributions. Eric Rosen was the principal author of earlier versions of this document. 👑
The authors wish to thank Lou Berger, Ron Bonica, Martin Djernaes, John Drake, Susan Hares, Satoru Matsushima, Thomas Morin, Dhananjaya Rao, Ravi Singh, Harish Sitaraman, Brian Trammell, Xiaohu Xu, and Zhaohui Zhang for their review, comments, and/or helpful discussions. Alvaro Retana provided an especially comprehensive review. 💖 literally so many legends in one paragraph.
Contributors
these are the other contributing authors, listed alphabetically 🧚
Randy Bush
Internet Initiative Japan
5147 Crystal Springs
Bainbridge Island, WA 98110
United States of America
Email: randy@psg.com
Robert Raszuk
Bloomberg LP
731 Lexington Ave
New York City, NY 10022
United States of America
Email: robert@raszuk.net
Eric C. RosenAuthors' Addresses
and last but not least, the people who actually wrote the thing 💅🎀
Keyur Patel
Arrcus, Inc
2077 Gateway Pl
San Jose, CA 95110
United States of America
Email: keyur@arrcus.com
Gunter Van de Velde
Nokia
Copernicuslaan 50
2018 Antwerpen
Belgium
Email: gunter.van_de_velde@nokia.com
Srihari R. Sangli
Juniper Networks
Email: ssangli@juniper.net
John Scudder
Juniper Networks
Email: jgs@juniper.net📦 where this page comes from
- ietf: rfc9012 2021-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms