idnits 2.17.1 draft-ietf-idr-tunnel-encaps-22.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC5566, but the abstract doesn't seem to directly say this. It does mention RFC5566 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 7, 2021) is 1199 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 7348 ** Downref: Normative reference to an Informational RFC: RFC 7637 == Outdated reference: A later version (-15) exists of draft-ietf-bess-evpn-inter-subnet-forwarding-11 -- Obsolete informational reference (is this intentional?): RFC 5512 (Obsoleted by RFC 9012) -- Obsolete informational reference (is this intentional?): RFC 5566 (Obsoleted by RFC 9012) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group K. Patel 3 Internet-Draft Arrcus, Inc 4 Obsoletes: 5512, 5566 (if approved) G. Van de Velde 5 Updates: 5640 (if approved) Nokia 6 Intended status: Standards Track S. Sangli 7 Expires: July 11, 2021 J. Scudder 8 Juniper Networks 9 January 7, 2021 11 The BGP Tunnel Encapsulation Attribute 12 draft-ietf-idr-tunnel-encaps-22 14 Abstract 16 This document defines a BGP Path Attribute known as the "Tunnel 17 Encapsulation Attribute", which can be used with BGP UPDATEs of 18 various SAFIs to provide information needed to create tunnels and 19 their corresponding encapsulation headers. It provides encodings for 20 a number of Tunnel Types along with procedures for choosing between 21 alternate tunnels and routing packets into tunnels. 23 This document obsoletes RFC 5512, which provided an earlier 24 definition of the Tunnel Encapsulation Attribute. RFC 5512 was never 25 deployed in production. Since RFC 5566 relies on RFC 5512, it is 26 likewise obsoleted. This document updates RFC 5640 by indicating 27 that the Load-Balancing Block sub-TLV may be included in any Tunnel 28 Encapsulation Attribute where load balancing is desired. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on July 11, 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Brief Summary of RFC 5512 . . . . . . . . . . . . . . . . 4 66 1.2. Deficiencies in RFC 5512 . . . . . . . . . . . . . . . . 4 67 1.3. Use Case for The Tunnel Encapsulation Attribute . . . . . 5 68 1.4. Brief Summary of Changes from RFC 5512 . . . . . . . . . 6 69 1.5. Update to RFC 5640 . . . . . . . . . . . . . . . . . . . 7 70 1.6. Effects of Obsoleting RFC 5566 . . . . . . . . . . . . . 7 71 2. The Tunnel Encapsulation Attribute . . . . . . . . . . . . . 8 72 3. Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . . . . . 9 73 3.1. The Tunnel Egress Endpoint Sub-TLV (type code 6) . . . . 9 74 3.1.1. Validating the Address Subfield . . . . . . . . . . . 11 75 3.2. Encapsulation Sub-TLVs for Particular Tunnel Types (type 76 code 1) . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 3.2.1. VXLAN (tunnel type 8) . . . . . . . . . . . . . . . . 12 78 3.2.2. NVGRE (tunnel type 9) . . . . . . . . . . . . . . . . 14 79 3.2.3. L2TPv3 (tunnel type 1) . . . . . . . . . . . . . . . 16 80 3.2.4. GRE (tunnel type 2) . . . . . . . . . . . . . . . . . 16 81 3.2.5. MPLS-in-GRE (tunnel type 11) . . . . . . . . . . . . 17 82 3.3. Outer Encapsulation Sub-TLVs . . . . . . . . . . . . . . 17 83 3.3.1. DS Field (type code 7) . . . . . . . . . . . . . . . 18 84 3.3.2. UDP Destination Port (type code 8) . . . . . . . . . 18 85 3.4. Sub-TLVs for Aiding Tunnel Selection . . . . . . . . . . 19 86 3.4.1. Protocol Type Sub-TLV (type code 2) . . . . . . . . . 19 87 3.4.2. Color Sub-TLV (type code 4) . . . . . . . . . . . . . 20 88 3.5. Embedded Label Handling Sub-TLV (type code 9) . . . . . . 20 89 3.6. MPLS Label Stack Sub-TLV (type code 10) . . . . . . . . . 21 90 3.7. Prefix-SID Sub-TLV (type code 11) . . . . . . . . . . . . 23 91 4. Extended Communities Related to the Tunnel Encapsulation 92 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 24 93 4.1. Encapsulation Extended Community . . . . . . . . . . . . 24 94 4.2. Router's MAC Extended Community . . . . . . . . . . . . . 25 95 4.3. Color Extended Community . . . . . . . . . . . . . . . . 26 96 5. Special Considerations for IP-in-IP Tunnels . . . . . . . . . 26 97 6. Semantics and Usage of the Tunnel Encapsulation attribute . . 26 98 7. Routing Considerations . . . . . . . . . . . . . . . . . . . 29 99 7.1. Impact on the BGP Decision Process . . . . . . . . . . . 29 100 7.2. Looping, Mutual Recursion, Etc. . . . . . . . . . . . . . 29 101 8. Recursive Next Hop Resolution . . . . . . . . . . . . . . . . 30 102 9. Use of Virtual Network Identifiers and Embedded Labels when 103 Imposing a Tunnel Encapsulation . . . . . . . . . . . . . . . 31 104 9.1. Tunnel Types without a Virtual Network Identifier Field . 31 105 9.2. Tunnel Types with a Virtual Network Identifier Field . . 31 106 9.2.1. Unlabeled Address Families . . . . . . . . . . . . . 32 107 9.2.2. Labeled Address Families . . . . . . . . . . . . . . 32 108 10. Applicability Restrictions . . . . . . . . . . . . . . . . . 33 109 11. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 110 12. Operational Considerations . . . . . . . . . . . . . . . . . 35 111 13. Validation and Error Handling . . . . . . . . . . . . . . . . 35 112 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 113 14.1. Obsoleting RFC 5512 . . . . . . . . . . . . . . . . . . 36 114 14.2. Obsoleting Code Points Assigned by RFCs 5566 . . . . . . 37 115 14.3. BGP Tunnel Encapsulation Parameters Grouping . . . . . . 37 116 14.4. BGP Tunnel Encapsulation Attribute Tunnel Types . . . . 37 117 14.5. Subsequent Address Family Identifiers . . . . . . . . . 37 118 14.6. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . 37 119 14.7. Flags Field of VXLAN Encapsulation sub-TLV . . . . . . . 38 120 14.8. Flags Field of NVGRE Encapsulation sub-TLV . . . . . . . 39 121 14.9. Embedded Label Handling sub-TLV . . . . . . . . . . . . 39 122 14.10. Color Extended Community Flags . . . . . . . . . . . . . 39 123 15. Security Considerations . . . . . . . . . . . . . . . . . . . 40 124 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 125 17. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 41 126 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 127 18.1. Normative References . . . . . . . . . . . . . . . . . . 42 128 18.2. Informative References . . . . . . . . . . . . . . . . . 44 129 Appendix A. Impact on RFC 8365 . . . . . . . . . . . . . . . . . 46 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 132 1. Introduction 134 This document obsoletes RFC 5512. The deficiencies of RFC 5512, and 135 a summary of the changes made, are discussed in Sections 1.1-1.3. 136 The material from RFC 5512 that is retained has been incorporated 137 into this document. Since [RFC5566] relies on RFC 5512, it is 138 likewise obsoleted. 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in BCP 143 14 [RFC2119] [RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 1.1. Brief Summary of RFC 5512 148 [RFC5512] defines a BGP Path Attribute known as the Tunnel 149 Encapsulation attribute. This attribute consists of one or more 150 TLVs. Each TLV identifies a particular type of tunnel. Each TLV 151 also contains one or more sub-TLVs. Some of the sub-TLVs, for 152 example, the "Encapsulation sub-TLV", contain information that may be 153 used to form the encapsulation header for the specified Tunnel Type. 154 Other sub- TLVs, for example, the "color sub-TLV" and the "protocol 155 sub-TLV", contain information that aids in determining whether 156 particular packets should be sent through the tunnel that the TLV 157 identifies. 159 [RFC5512] only allows the Tunnel Encapsulation attribute to be 160 attached to BGP UPDATE messages of the Encapsulation Address Family. 161 These UPDATE messages have an AFI (Address Family Identifier) of 1 or 162 2, and a SAFI of 7. In an UPDATE of the Encapsulation SAFI, the NLRI 163 (Network Layer Reachability Information) is an address of the BGP 164 speaker originating the UPDATE. Consider the following scenario: 166 o BGP speaker R1 has received and selected UPDATE U for local use; 168 o UPDATE U's SAFI is the Encapsulation SAFI; 170 o UPDATE U has the address R2 as its NLRI; 172 o UPDATE U has a Tunnel Encapsulation attribute. 174 o R1 has a packet, P, to transmit to destination D; 176 o R1's best route to D is a BGP route that has R2 as its next hop; 178 In this scenario, when R1 transmits packet P, it should transmit it 179 to R2 through one of the tunnels specified in U's Tunnel 180 Encapsulation attribute. The IP address of the tunnel egress 181 endpoint of each such tunnel is R2. Packet P is known as the 182 tunnel's "payload". 184 1.2. Deficiencies in RFC 5512 186 While the ability to specify tunnel information in a BGP UPDATE is 187 useful, the procedures of [RFC5512] have certain limitations: 189 o The requirement to use the "Encapsulation SAFI" presents an 190 unfortunate operational cost, as each BGP session that may need to 191 carry tunnel encapsulation information needs to be reconfigured to 192 support the Encapsulation SAFI. The Encapsulation SAFI has never 193 been used, and this requirement has served only to discourage the 194 use of the Tunnel Encapsulation attribute. 196 o There is no way to use the Tunnel Encapsulation attribute to 197 specify the tunnel egress endpoint address of a given tunnel; 198 [RFC5512] assumes that the tunnel egress endpoint of each tunnel 199 is specified as the NLRI of an UPDATE of the Encapsulation SAFI. 201 o If the respective best routes to two different address prefixes 202 have the same next hop, [RFC5512] does not provide a 203 straightforward method to associate each prefix with a different 204 tunnel. 206 o If a particular Tunnel Type requires an outer IP or UDP 207 encapsulation, there is no way to signal the values of any of the 208 fields of the outer encapsulation. 210 o In [RFC5512]'s specification of the sub-TLVs, each sub-TLV has 211 one-octet length field. In some cases, where a sub-TLV may 212 require more than 255 octets for its encoding, a two-octet length 213 field may be needed. 215 1.3. Use Case for The Tunnel Encapsulation Attribute 217 Consider the case of a router R1 forwarding an IP packet P. Let D be 218 P's IP destination address. R1 must look up D in its forwarding 219 table. Suppose that the "best match" route for D is route Q, where Q 220 is a BGP-distributed route whose "BGP next hop" is router R2. And 221 suppose further that the routers along the path from R1 to R2 have 222 entries for R2 in their forwarding tables, but do NOT have entries 223 for D in their forwarding tables. For example, the path from R1 to 224 R2 may be part of a "BGP-free core", where there are no BGP- 225 distributed routes at all in the core. Or, as in [RFC5565], D may be 226 an IPv4 address while the intermediate routers along the path from R1 227 to R2 may support only IPv6. 229 In cases such as this, in order for R1 to properly forward packet P, 230 it must encapsulate P and send P "through a tunnel" to R2. For 231 example, R1 may encapsulate P using GRE, L2TPv3, IP in IP, etc., 232 where the destination IP address of the encapsulation header is the 233 address of R2. 235 In order for R1 to encapsulate P for transport to R2, R1 must know 236 what encapsulation protocol to use for transporting different sorts 237 of packets to R2. R1 must also know how to fill in the various 238 fields of the encapsulation header. With certain encapsulation 239 types, this knowledge may be acquired by default or through manual 240 configuration. Other encapsulation protocols have fields such as 241 session id, key, or cookie that must be filled in. It would not be 242 desirable to require every BGP speaker to be manually configured with 243 the encapsulation information for every one of its BGP next hops. 245 This document specifies a way in which BGP itself can be used by a 246 given BGP speaker to tell other BGP speakers, "if you need to 247 encapsulate packets to be sent to me, here's the information you need 248 to properly form the encapsulation header". A BGP speaker signals 249 this information to other BGP speakers by using a new BGP attribute 250 type value, the BGP Tunnel Encapsulation Attribute. This attribute 251 specifies the encapsulation protocols that may be used as well as 252 whatever additional information (if any) is needed in order to 253 properly use those protocols. Other attributes, for example, 254 communities or extended communities, may also be included. 256 1.4. Brief Summary of Changes from RFC 5512 258 This document addresses the deficiencies identified in Section 1.2 259 by: 261 o Deprecating the Encapsulation SAFI. 263 o Defining a new "Tunnel Egress Endpoint sub-TLV" (Section 3.1) that 264 can be included in any of the TLVs contained in the Tunnel 265 Encapsulation attribute. This sub-TLV can be used to specify the 266 remote endpoint address of a particular tunnel. 268 o Allowing the Tunnel Encapsulation attribute to be carried by BGP 269 UPDATEs of additional AFI/SAFIs. Appropriate semantics are 270 provided for this way of using the attribute. 272 o Defining a number of new sub-TLVs that provide additional 273 information that is useful when forming the encapsulation header 274 used to send a packet through a particular tunnel. 276 o Defining the sub-TLV type field so that a sub-TLV whose type is in 277 the range from 0 to 127 inclusive has a one-octet length field, 278 but a sub-TLV whose type is in the range from 128 to 255 inclusive 279 has a two-octet length field. 281 One of the sub-TLVs defined in [RFC5512] is the "Encapsulation sub- 282 TLV". For a given tunnel, the Encapsulation sub-TLV specifies some 283 of the information needed to construct the encapsulation header used 284 when sending packets through that tunnel. This document defines 285 Encapsulation sub-TLVs for a number of tunnel types not discussed in 286 [RFC5512]: VXLAN (Virtual Extensible Local Area Network, [RFC7348]), 287 NVGRE (Network Virtualization Using Generic Routing Encapsulation 288 [RFC7637]), and MPLS-in-GRE (MPLS in Generic Routing Encapsulation 289 [RFC4023]). MPLS-in-UDP [RFC7510] is also supported, but an 290 Encapsulation sub-TLV for it is not needed since there are no 291 additional parameters to be signaled. 293 Some of the encapsulations mentioned in the previous paragraph need 294 to be further encapsulated inside UDP and/or IP. [RFC5512] provides 295 no way to specify that certain information is to appear in these 296 outer IP and/or UDP encapsulations. This document provides a 297 framework for including such information in the TLVs of the Tunnel 298 Encapsulation attribute. 300 When the Tunnel Encapsulation attribute is attached to a BGP UPDATE 301 whose AFI/SAFI identifies one of the labeled address families, it is 302 not always obvious whether the label embedded in the NLRI is to 303 appear somewhere in the tunnel encapsulation header (and if so, 304 where), or whether it is to appear in the payload, or whether it can 305 be omitted altogether. This is especially true if the tunnel 306 encapsulation header itself contains a "virtual network identifier". 307 This document provides a mechanism that allows one to signal (by 308 using sub-TLVs of the Tunnel Encapsulation attribute) how one wants 309 to use the embedded label when the tunnel encapsulation has its own 310 virtual network identifier field. 312 [RFC5512] defines a Tunnel Encapsulation Extended Community that can 313 be used instead of the Tunnel Encapsulation attribute under certain 314 circumstances. This document describes (Section 4.1) how the Tunnel 315 Encapsulation Extended Community can be used in a backwards- 316 compatible fashion. It is possible to combine Tunnel Encapsulation 317 Extended Communities and Tunnel Encapsulation attributes in the same 318 BGP UPDATE in this manner. 320 1.5. Update to RFC 5640 322 This document updates [RFC5640] by indicating that the Load-Balancing 323 Block sub-TLV MAY be included in any Tunnel Encapsulation Attribute 324 where loadbalancing is desired. 326 1.6. Effects of Obsoleting RFC 5566 328 This specification obsoletes RFC 5566. This has the effect of, in 329 turn, obsoleting a number of code points defined in that document. 330 From the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry, 331 "Transmit tunnel endpoint" (type code 3), "IPsec in Tunnel-mode" 332 (type code 4), "IP in IP tunnel with IPsec Transport Mode" (type code 333 5), and "MPLS-in-IP tunnel with IPsec Transport Mode" (type code 6) 334 are obsoleted. From the "BGP Tunnel Encapsulation Attribute Sub- 335 TLVs" registry, "IPsec Tunnel Authenticator" (type code 3) is 336 obsoleted. See Section 14.2. 338 2. The Tunnel Encapsulation Attribute 340 The Tunnel Encapsulation attribute is an optional transitive BGP Path 341 attribute. IANA has assigned the value 23 as the type code of the 342 attribute. The attribute is composed of a set of Type-Length-Value 343 (TLV) encodings. Each TLV contains information corresponding to a 344 particular Tunnel Type. A Tunnel Encapsulation TLV, also known as 345 Tunnel TLV, is structured as shown in Figure 1: 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Tunnel Type (2 Octets) | Length (2 Octets) | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | | 353 | Value (Variable) | 354 | | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Figure 1: Tunnel Encapsulation TLV Value Field 359 o Tunnel Type (2 octets): identifies a type of tunnel. The field 360 contains values from the IANA Registry "BGP Tunnel Encapsulation 361 Attribute Tunnel Types". See Section 3.4.1 for discussion of 362 special treatment of tunnel types with names of the form "X-in-Y". 364 o Length (2 octets): the total number of octets of the Value field. 366 o Value (variable): comprised of multiple sub-TLVs. 368 Each sub-TLV consists of three fields: a 1-octet type, a 1-octet or 369 2-octet length field (depending on the type), and zero or more octets 370 of value. A sub-TLV is structured as shown in Figure 2: 372 +--------------------------------+ 373 | Sub-TLV Type (1 Octet) | 374 +--------------------------------+ 375 | Sub-TLV Length (1 or 2 Octets) | 376 +--------------------------------+ 377 | Sub-TLV Value (Variable) | 378 +--------------------------------+ 380 Figure 2: Encapsulation Sub-TLV Value Field 382 o Sub-TLV Type (1 octet): each sub-TLV type defines a certain 383 property about the Tunnel TLV that contains this sub-TLV. The 384 field contains values from the IANA Registry "BGP Tunnel 385 Encapsulation Attribute Sub-TLVs". 387 o Sub-TLV Length (1 or 2 octets): the total number of octets of the 388 sub-TLV Value field. The Sub-TLV Length field contains 1 octet if 389 the Sub-TLV Type field contains a value in the range from 0-127. 390 The Sub-TLV Length field contains two octets if the Sub-TLV Type 391 field contains a value in the range from 128-255. 393 o Sub-TLV Value (variable): encodings of the Value field depend on 394 the sub-TLV type as enumerated above. The following sub-sections 395 define the encoding in detail. 397 3. Tunnel Encapsulation Attribute Sub-TLVs 399 This section specifies a number of sub-TLVs. These sub-TLVs can be 400 included in a TLV of the Tunnel Encapsulation attribute. 402 3.1. The Tunnel Egress Endpoint Sub-TLV (type code 6) 404 The Tunnel Egress Endpoint sub-TLV specifies the address of the 405 egress endpoint of the tunnel, that is, the address of the router 406 that will decapsulate the payload. Its Value field contains three 407 subfields: 409 1. a reserved subfield 411 2. a two-octet Address Family subfield 413 3. an Address subfield, whose length depends upon the Address 414 Family. 416 0 1 2 3 417 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 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Reserved (4 octets) | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Address Family (2 octets) | Address | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Variable) + 423 ~ ~ 424 | | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 Figure 3: Tunnel Egress Endpoint Sub-TLV Value Field 429 The Reserved subfield SHOULD be originated as zero. It MUST be 430 disregarded on receipt, and it MUST be propagated unchanged. 432 The Address Family subfield contains a value from IANA's "Address 433 Family Numbers" registry. This document assumes that the Address 434 Family is either IPv4 or IPv6; use of other address families is 435 outside the scope of this document. 437 If the Address Family subfield contains the value for IPv4, the 438 Address subfield MUST contain an IPv4 address (a /32 IPv4 prefix). 440 If the Address Family subfield contains the value for IPv6, the 441 Address subfield MUST contain an IPv6 address (a /128 IPv6 prefix). 443 In a given BGP UPDATE, the address family (IPv4 or IPv6) of a Tunnel 444 Egress Endpoint sub-TLV is independent of the address family of the 445 UPDATE itself. For example, an UPDATE whose NLRI is an IPv4 address 446 may have a Tunnel Encapsulation attribute containing Tunnel Egress 447 Endpoint sub-TLVs that contain IPv6 addresses. Also, different 448 tunnels represented in the Tunnel Encapsulation attribute may have 449 tunnel egress endpoints of different address families. 451 There is one special case: the Tunnel Egress Endpoint sub-TLV MAY 452 have a Value field whose Address Family subfield contains 0. This 453 means that the tunnel's egress endpoint is the address of the next 454 hop. If the Address Family subfield contains 0, the Address subfield 455 is omitted. In this case, the Length field of Tunnel Egress Endpoint 456 sub-TLV MUST contain the value 6 (0x06). 458 When the Tunnel Encapsulation attribute is carried in an UPDATE 459 message of one of the AFI/SAFIs specified in this document (see the 460 second paragraph of Section 6), each TLV MUST have one, and one only, 461 Tunnel Egress Endpoint sub-TLV. If a TLV does not have a Tunnel 462 Egress Endpoint sub-TLV, that TLV should be treated as if it had a 463 malformed Tunnel Egress Endpoint sub-TLV (see below). 465 In the context of this specification, if the Address Family subfield 466 has any value other than IPv4, IPv6, or the special value 0, the 467 Tunnel Egress Endpoint sub-TLV is considered "unrecognized" (see 468 Section 13). If any of the following conditions hold, the Tunnel 469 Egress Endpoint sub-TLV is considered to be "malformed": 471 o The length of the sub-TLV's Value field is other than 6 added to 472 the defined length for the address family given in its Address 473 Family subfield. Therefore, for address family behaviors defined 474 in this document, the permitted values are: 476 * 10, if the Address Family subfield contains the value for IPv4. 478 * 22, if the Address Family subfield contains the value for IPv6. 480 * 6, if the Address Family subfield contains the value zero. 482 o The IP address in the sub-TLV's Address subfield lies within a 483 block listed in the relevant Special-Purpose IP Address Registry 484 [RFC6890] with either a "destination" attribute value or a 485 "forwardable" attribute value of "false". (Such routes are 486 sometimes colloquially known as "Martians".) This restriction MAY 487 be relaxed by explicit configuration. 489 o It can be determined that the IP address in the sub-TLV's Address 490 subfield does not belong to the Autonomous System (AS) that 491 originated the route that contains the attribute. Section 3.1.1 492 describes an optional procedure to make this determination. 494 Error Handling is specified in Section 13. 496 If the Tunnel Egress Endpoint sub-TLV contains an IPv4 or IPv6 497 address that is valid but not reachable, the sub-TLV is not 498 considered to be malformed. 500 3.1.1. Validating the Address Subfield 502 This section provides a procedure that MAY be applied to validate 503 that the IP address in the sub-TLV's Address subfield belongs to the 504 AS that originated the route that contains the attribute. (The 505 notion of "belonging to" an AS is expanded on below.) Doing this is 506 thought to increase confidence that when traffic is sent to the IP 507 address depicted in the Address subfield, it will go to the same AS 508 as it would go to if the Tunnel Encapsulation Attribute were not 509 present, although of course it cannot guarantee it. See Section 15 510 for discussion of the limitations of this procedure. The principal 511 applicability of this procedure is in deployments that are not 512 strictly scoped. In deployments with strict scope, and especially 513 those scoped to a single AS, these procedures may not add substantial 514 benefit beyond those discussed in Section 11. 516 The Route Origin ASN (Autonomous System Number) of a BGP route that 517 includes a Tunnel Encapsulation Attribute can be determined by 518 inspection of the AS_PATH attribute, according to the procedure 519 specified in [RFC6811] Section 2. Call this value Route_AS. 521 In order to determine the Route Origin ASN of the address depicted in 522 the Address subfield of the Tunnel Egress Endpoint sub-TLV, it is 523 necessary to consider the forwarding route, that is, the route that 524 will be used to forward traffic toward that address. This route is 525 determined by a recursive route lookup operation for that address, as 526 discussed in [RFC4271] Section 5.1.3. The relevant AS Path to 527 consider is the last one encountered while performing the recursive 528 lookup; the procedures of RFC6811 Section 2 are applied to that AS 529 Path to determine the Route Origin ASN. If no AS Path is encountered 530 at all, for example if that route's source is a protocol other than 531 BGP, the Route Origin ASN is the BGP speaker's own AS number. Call 532 this value Egress_AS. 534 If Route_AS does not equal Egress_AS, then the Tunnel Egress Endpoint 535 sub-TLV is considered not to be valid. In some cases a network 536 operator who controls a set of Autonomous Systems might wish to allow 537 a Tunnel Egress Endpoint to reside in an AS other than Route_AS; 538 configuration MAY allow for such a case, in which case the check 539 becomes, if Egress_AS is not within the configured set of permitted 540 AS numbers, then the Tunnel Egress Endpoint sub-TLV is considered to 541 be "malformed". 543 Note that if the forwarding route changes, this procedure MUST be 544 reapplied. As a result, a sub-TLV that was formerly considered valid 545 might become not valid, or vice-versa. 547 3.2. Encapsulation Sub-TLVs for Particular Tunnel Types (type code 1) 549 This section defines Encapsulation sub-TLVs for the following tunnel 550 types: VXLAN ([RFC7348]), NVGRE ([RFC7637]), MPLS-in-GRE ([RFC4023]), 551 L2TPv3 ([RFC3931]), and GRE ([RFC2784]). 553 Rules for forming the encapsulation based on the information in a 554 given TLV are given in Section 6 and Section 9. 556 Recall that the tunnel type itself is identified by the Tunnel Type 557 field in the attribute header (Section 2); the Encapsulation sub- 558 TLV's structure is inferred from this. Regardless of the Tunnel 559 Type, the sub-TLV type of the Encapsulation sub-TLV is 1. There are 560 also tunnel types for which it is not necessary to define an 561 Encapsulation sub-TLV, because there are no fields in the 562 encapsulation header whose values need to be signaled from the tunnel 563 egress endpoint. 565 3.2.1. VXLAN (tunnel type 8) 567 This document defines an Encapsulation sub-TLV for VXLAN [RFC7348] 568 tunnels. When the Tunnel Type is VXLAN, the length of the sub-TLV is 569 12 octets. The following is the structure of the Value field in the 570 Encapsulation sub-TLV: 572 0 1 2 3 573 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 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 |V|M|R|R|R|R|R|R| VN-ID (3 Octets) | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | MAC Address (4 Octets) | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | MAC Address (2 Octets) | Reserved (2 Octets) | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 Figure 4: VXLAN Encapsulation Sub-TLV Value Field 584 V: This bit is set to 1 to indicate that a VN-ID (Virtual Network 585 Identifier) is present in the Encapsulation sub-TLV. If set to 0, 586 the VN-ID field is disregarded. Please see Section 9. 588 M: This bit is set to 1 to indicate that a MAC Address is present 589 in the Encapsulation sub-TLV. If set to 0, the MAC Address field 590 is disregarded. 592 R: The remaining bits in the 8-bit flags field are reserved for 593 further use. They MUST always be set to 0 by the originator of 594 the sub-TLV. Intermediate routers MUST propagate them without 595 modification. Any receiving routers MUST ignore these bits upon 596 receipt. 598 VN-ID: If the V bit is set, the VN-ID field contains a 3 octet VN- 599 ID value. If the V bit is not set, the VN-ID field MUST be set to 600 zero on transmission and disregarded on receipt. 602 MAC Address: If the M bit is set, this field contains a 6 octet 603 Ethernet MAC address. If the M bit is not set, this field MUST be 604 set to all zeroes on transmission and disregarded on receipt. 606 Reserved: MUST be set to zero on transmission and disregarded on 607 receipt. 609 When forming the VXLAN encapsulation header: 611 o The values of the V, M, and R bits are NOT copied into the flags 612 field of the VXLAN header. The flags field of the VXLAN header is 613 set as per [RFC7348]. 615 o If the M bit is set, the MAC Address is copied into the Inner 616 Destination MAC Address field of the Inner Ethernet Header (see 617 section 5 of [RFC7348]). 619 If the M bit is not set, and the payload being sent through the 620 VXLAN tunnel is an Ethernet frame, the Destination MAC Address 621 field of the Inner Ethernet Header is just the Destination MAC 622 Address field of the payload's Ethernet header. 624 If the M bit is not set, and the payload being sent through the 625 VXLAN tunnel is an IP or MPLS packet, the Inner Destination MAC 626 Address field is set to a configured value; if there is no 627 configured value, the VXLAN tunnel cannot be used. 629 o If the V bit is not set, and the BGP UPDATE message has AFI/SAFI 630 other than Ethernet VPNs (SAFI 70, "BGP EVPNs") then the VXLAN 631 tunnel cannot be used. 633 o Section 9 describes how the VNI field of the VXLAN encapsulation 634 header is set. 636 Note that in order to send an IP packet or an MPLS packet through a 637 VXLAN tunnel, the packet must first be encapsulated in an Ethernet 638 header, which becomes the "inner Ethernet header" described in 639 [RFC7348]. The VXLAN Encapsulation sub-TLV may contain information 640 (for example,the MAC address) that is used to form this Ethernet 641 header. 643 3.2.2. NVGRE (tunnel type 9) 645 This document defines an Encapsulation sub-TLV for NVGRE [RFC7637] 646 tunnels. When the Tunnel Type is NVGRE, the length of the sub-TLV is 647 12 octets. The following is the structure of the Value field in the 648 Encapsulation sub-TLV: 650 0 1 2 3 651 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 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 |V|M|R|R|R|R|R|R| VN-ID (3 Octets) | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | MAC Address (4 Octets) | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | MAC Address (2 Octets) | Reserved (2 Octets) | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 Figure 5: NVGRE Encapsulation Sub-TLV Value Field 662 V: This bit is set to 1 to indicate that a VN-ID is present in the 663 Encapsulation sub-TLV. If set to 0, the VN-ID field is 664 disregarded. Please see Section 9. 666 M: This bit is set to 1 to indicate that a MAC Address is present 667 in the Encapsulation sub-TLV. If set to 0, the MAC Address field 668 is disregarded. 670 R: The remaining bits in the 8-bit flags field are reserved for 671 further use. They MUST always be set to 0 by the originator of 672 the sub-TLV. Intermediate routers MUST propagate them without 673 modification. Any receiving routers MUST ignore these bits upon 674 receipt. 676 VN-ID: If the V bit is set, the VN-ID field contains a 3 octet VN- 677 ID value, used to set the NVGRE VSID (see Section 9). If the V 678 bit is not set, the VN-ID field MUST be set to zero on 679 transmission and disregarded on receipt. 681 MAC Address: If the M bit is set, this field contains a 6 octet 682 Ethernet MAC address. If the M bit is not set, this field MUST be 683 set to all zeroes on transmission and disregarded on receipt. 685 Reserved: MUST be set to zero on transmission and disregarded on 686 receipt. 688 When forming the NVGRE encapsulation header: 690 o The values of the V, M, and R bits are NOT copied into the flags 691 field of the NVGRE header. The flags field of the NVGRE header is 692 set as per [RFC7637]. 694 o If the M bit is set, the MAC Address is copied into the Inner 695 Destination MAC Address field of the Inner Ethernet Header (see 696 section 3.2 of [RFC7637]). 698 If the M bit is not set, and the payload being sent through the 699 NVGRE tunnel is an Ethernet frame, the Destination MAC Address 700 field of the Inner Ethernet Header is just the Destination MAC 701 Address field of the payload's Ethernet header. 703 If the M bit is not set, and the payload being sent through the 704 NVGRE tunnel is an IP or MPLS packet, the Inner Destination MAC 705 Address field is set to a configured value; if there is no 706 configured value, the NVGRE tunnel cannot be used. 708 o If the V bit is not set, and the BGP UPDATE message has AFI/SAFI 709 other than Ethernet VPNs (EVPN) then the NVGRE tunnel cannot be 710 used. 712 o Section 9 describes how the VSID (Virtual Subnet Identifier) field 713 of the NVGRE encapsulation header is set. 715 3.2.3. L2TPv3 (tunnel type 1) 717 When the Tunnel Type of the TLV is L2TPv3 over IP [RFC3931], the 718 length of the sub-TLV is between 4 and 12 octets, depending on the 719 length of the cookie. The following is the structure of the Value 720 field of the Encapsulation sub-TLV: 722 0 1 2 3 723 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 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Session ID (4 octets) | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | | 728 | Cookie (Variable) | 729 | | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 Figure 6: L2TPv3 Encapsulation Sub-TLV Value Field 734 Session ID: a non-zero 4-octet value locally assigned by the 735 advertising router that serves as a lookup key for the incoming 736 packet's context. 738 Cookie: an optional, variable length (encoded in octets -- 0 to 8 739 octets) value used by L2TPv3 to check the association of a 740 received data message with the session identified by the Session 741 ID. Generation and usage of the cookie value is as specified in 742 [RFC3931]. 744 The length of the cookie is not encoded explicitly, but can be 745 calculated as (sub-TLV length - 4). 747 3.2.4. GRE (tunnel type 2) 749 When the Tunnel Type of the TLV is GRE [RFC2784], the length of the 750 sub-TLV is 4 octets. The following is the structure of the Value 751 field of the Encapsulation sub-TLV: 753 0 1 2 3 754 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 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | GRE Key (4 octets) | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 Figure 7: GRE Encapsulation Sub-TLV 761 GRE Key: 4-octet field [RFC2890] that is generated by the 762 advertising router. Note that the key is optional. Unless a key 763 value is being advertised, the GRE Encapsulation sub-TLV MUST NOT 764 be present. 766 3.2.5. MPLS-in-GRE (tunnel type 11) 768 When the Tunnel Type is MPLS-in-GRE [RFC4023], the length of the sub- 769 TLV is 4 octets. The following is the structure of the Value field 770 of the Encapsulation sub-TLV: 772 0 1 2 3 773 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 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | GRE-Key (4 Octets) | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 Figure 8: MPLS-in-GRE Encapsulation Sub-TLV Value Field 780 GRE-Key: 4-octet field [RFC2890] that is generated by the 781 advertising router. Note that the key is optional. Unless a key 782 value is being advertised, the MPLS-in-GRE Encapsulation sub-TLV 783 MUST NOT be present. 785 Note that the GRE Tunnel Type defined in Section 3.2.4 can be used 786 instead of the MPLS-in-GRE Tunnel Type when it is necessary to 787 encapsulate MPLS in GRE. Including a TLV of the MPLS-in-GRE tunnel 788 type is equivalent to including a TLV of the GRE Tunnel Type that 789 also includes a Protocol Type sub-TLV (Section 3.4.1) specifying MPLS 790 as the protocol to be encapsulated. 792 Although the MPLS-in-GRE tunnel type is just a special case of the 793 GRE tunnel type and thus is not strictly necessary, it is included 794 for reasons of backwards compatibility with, for example, 795 implementations of [RFC8365]. 797 3.3. Outer Encapsulation Sub-TLVs 799 The Encapsulation sub-TLV for a particular Tunnel Type allows one to 800 specify the values that are to be placed in certain fields of the 801 encapsulation header for that Tunnel Type. However, some tunnel 802 types require an outer IP encapsulation, and some also require an 803 outer UDP encapsulation. The Encapsulation sub-TLV for a given 804 Tunnel Type does not usually provide a way to specify values for 805 fields of the outer IP and/or UDP encapsulations. If it is necessary 806 to specify values for fields of the outer encapsulation, additional 807 sub-TLVs must be used. This document defines two such sub-TLVs. 809 If an outer Encapsulation sub-TLV occurs in a TLV for a Tunnel Type 810 that does not use the corresponding outer encapsulation, the sub-TLV 811 MUST be treated as if it were an unrecognized type of sub-TLV. 813 3.3.1. DS Field (type code 7) 815 Most of the tunnel types that can be specified in the Tunnel 816 Encapsulation attribute require an outer IP encapsulation. The 817 Differentiated Services (DS) Field sub-TLV can be carried in the TLV 818 of any such Tunnel Type. It specifies the setting of the one-octet 819 Differentiated Services field in the outer IPv4 or IPv6 encapsulation 820 (see [RFC2474]). Any one-octet value can be transported; the 821 semantics of the DSCP field is beyond the scope of this document. 822 The Value field is always a single octet. 824 0 1 2 3 4 5 6 7 825 +-+-+-+-+-+-+-+-+ 826 | DS value | 827 +-+-+-+-+-+-+-+-+ 829 Figure 9: DS Field Sub-TLV Value Field 831 Because the interpretation of the DSCP field at the recipient may be 832 different from its interpretation at the originator, an 833 implementation MAY provide a facility to use policy to filter or 834 modify the DS Field. 836 3.3.2. UDP Destination Port (type code 8) 838 Some of the tunnel types that can be specified in the Tunnel 839 Encapsulation attribute require an outer UDP encapsulation. 840 Generally there is a standard UDP Destination Port value for a 841 particular Tunnel Type. However, sometimes it is useful to be able 842 to use a non-standard UDP destination port. If a particular tunnel 843 type requires an outer UDP encapsulation, and it is desired to use a 844 UDP destination port other than the standard one, the port to be used 845 can be specified by including a UDP Destination Port sub-TLV. The 846 Value field of this sub-TLV is always a two-octet field, containing 847 the port value. Any two-octet value other than zero can be 848 transported. If the reserved value zero is received, the sub-TLV 849 MUST be treated as malformed according to the rules of Section 13. 851 0 1 852 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | UDP Port (2 Octets) | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 Figure 10: UDP Destination Port Sub-TLV Value Field 859 3.4. Sub-TLVs for Aiding Tunnel Selection 861 3.4.1. Protocol Type Sub-TLV (type code 2) 863 The Protocol Type sub-TLV MAY be included in a given TLV to indicate 864 the type of the payload packets that are allowed to be encapsulated 865 with the tunnel parameters that are being signaled in the TLV. 866 Packets with other payload types MUST NOT be encapsulated in the 867 relevant tunnel. The Value field of the sub-TLV contains a 2-octet 868 value from IANA's "ETHER TYPES" registry [Ethertypes]. If the 869 reserved value 0xFFFF is received, the sub-TLV MUST be treated as 870 malformed according to the rules of Section 13. 872 0 1 873 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Ethertype (2 Octets) | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 Figure 11: Protocol Type Sub-TLV Value Field 880 For example, if there are three L2TPv3 sessions, one carrying IPv4 881 packets, one carrying IPv6 packets, and one carrying MPLS packets, 882 the egress router will include three TLVs of L2TPv3 encapsulation 883 type, each specifying a different Session ID and a different payload 884 type. The Protocol Type sub-TLV for these will be IPv4 (protocol 885 type = 0x0800), IPv6 (protocol type = 0x86dd), and MPLS (protocol 886 type = 0x8847), respectively. This informs the ingress routers of 887 the appropriate encapsulation information to use with each of the 888 given protocol types. Insertion of the specified Session ID at the 889 ingress routers allows the egress to process the incoming packets 890 correctly, according to their protocol type. 892 Note that for tunnel types whose names are of the form "X-in-Y", for 893 example, "MPLS-in-GRE", only packets of the specified payload type 894 "X" are to be carried through the tunnel of type "Y". This is the 895 equivalent of specifying a Tunnel Type "Y" and including in its TLV a 896 Protocol Type sub-TLV (see Section 3.4.1) specifying protocol "X". 897 If the Tunnel Type is "X-in-Y", it is unnecessary, though harmless, 898 to explicitly include a Protocol Type sub-TLV specifying "X". Also, 899 for "X-in-Y" type tunnels, a Protocol Type sub-TLV specifying 900 anything other than "X" MUST be ignored; this is discussed further in 901 Section 13. 903 3.4.2. Color Sub-TLV (type code 4) 905 The Color sub-TLV MAY be used as a way to "color" the corresponding 906 Tunnel TLV. The Value field of the sub-TLV is eight octets long, and 907 consists of a Color Extended Community, as defined in Section 4.3. 908 For the use of this sub-TLV and Extended Community, please see 909 Section 8. 911 The format of the Value field is depicted in Figure 15. 913 If the Length field of a Color sub-TLV has a value other than 8, or 914 the first two octets of its Value field are not 0x030b, the sub-TLV 915 MUST be treated as if it were an unrecognized sub-TLV (see 916 Section 13). 918 3.5. Embedded Label Handling Sub-TLV (type code 9) 920 Certain BGP address families (corresponding to particular AFI/SAFI 921 pairs, for example, 1/4, 2/4, 1/128, 2/128) have MPLS labels embedded 922 in their NLRIs. The term "embedded label" is used to refer to the 923 MPLS label that is embedded in an NLRI, and the term "labeled address 924 family" to refer to any AFI/SAFI that has embedded labels. 926 Some of the tunnel types (for example, VXLAN and NVGRE) that can be 927 specified in the Tunnel Encapsulation attribute have an encapsulation 928 header containing a "Virtual Network" identifier of some sort. The 929 Encapsulation sub-TLVs for these tunnel types may optionally specify 930 a value for the virtual network identifier. 932 Suppose a Tunnel Encapsulation attribute is attached to an UPDATE of 933 a labeled address family, and it is decided to use a particular 934 tunnel (specified in one of the attribute's TLVs) for transmitting a 935 packet that is being forwarded according to that UPDATE. When 936 forming the encapsulation header for that packet, different 937 deployment scenarios require different handling of the embedded label 938 and/or the virtual network identifier. The Embedded Label Handling 939 sub-TLV can be used to control the placement of the embedded label 940 and/or the virtual network identifier in the encapsulation. 942 The Embedded Label Handling sub-TLV may be included in any TLV of the 943 Tunnel Encapsulation attribute. If the Tunnel Encapsulation 944 attribute is attached to an UPDATE of a non-labeled address family, 945 then the sub-TLV MUST be disregarded. If the sub-TLV is contained in 946 a TLV whose Tunnel Type does not have a virtual network identifier in 947 its encapsulation header, the sub-TLV MUST be disregarded. In those 948 cases where the sub-TLV is ignored, it MUST NOT be stripped from the 949 TLV before the route is propagated. 951 The sub-TLV's Length field always contains the value 1, and its Value 952 field consists of a single octet. The following values are defined: 954 1: The payload will be an MPLS packet with the embedded label at 955 the top of its label stack. 957 2: The embedded label is not carried in the payload, but is carried 958 either in the virtual network identifier field of the 959 encapsulation header, or else is ignored entirely. 961 If any value other than 1 or 2 is carried, the sub-TLV MUST be 962 considered malformed, according to the procedures of Section 13. 964 Please see Section 9 for the details of how this sub-TLV is used when 965 it is carried by an UPDATE of a labeled address family. 967 0 1 2 3 4 5 6 7 968 +-+-+-+-+-+-+-+-+ 969 | 1 or 2 | 970 +-+-+-+-+-+-+-+-+ 972 Figure 12: Embedded Label Handling Sub-TLV Value Field 974 3.6. MPLS Label Stack Sub-TLV (type code 10) 976 This sub-TLV allows an MPLS label stack ([RFC3032]) to be associated 977 with a particular tunnel. 979 The length of the sub-TLV is a multiple of 4 octets and the Value 980 field of this sub-TLV is a sequence of MPLS label stack entries. The 981 first entry in the sequence is the "topmost" label, the final entry 982 in the sequence is the "bottommost" label. When this label stack is 983 pushed onto a packet, this ordering MUST be preserved. 985 Each label stack entry has the following format: 987 0 1 2 3 988 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 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | Label | TC |S| TTL | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 Figure 13: MPLS Label Stack Sub-TLV Value Field 995 The fields are as defined in [RFC3032], [RFC5462]. 997 If a packet is to be sent through the tunnel identified in a 998 particular TLV, and if that TLV contains an MPLS Label Stack sub-TLV, 999 then the label stack appearing in the sub-TLV MUST be pushed onto the 1000 packet before any other labels are pushed onto the packet. (See 1001 Section 6 for further discussion.) 1003 In particular, if the Tunnel Encapsulation attribute is attached to a 1004 BGP UPDATE of a labeled address family, the contents of the MPLS 1005 Label Stack sub-TLV MUST be pushed onto the packet before the label 1006 embedded in the NLRI is pushed onto the packet. 1008 If the MPLS Label Stack sub-TLV is included in a TLV identifying a 1009 Tunnel Type that uses virtual network identifiers (see Section 9), 1010 the contents of the MPLS Label Stack sub-TLV MUST be pushed onto the 1011 packet before the procedures of Section 9 are applied. 1013 The number of label stack entries in the sub-TLV MUST be determined 1014 from the sub-TLV length field. Thus it is not necessary to set the S 1015 bit in any of the label stack entries of the sub-TLV, and the setting 1016 of the S bit is ignored when parsing the sub-TLV. When the label 1017 stack entries are pushed onto a packet that already has a label 1018 stack, the S bits of all the entries being pushed MUST be cleared. 1019 When the label stack entries are pushed onto a packet that does not 1020 already have a label stack, the S bit of the bottommost label stack 1021 entry MUST be set, and the S bit of all the other label stack entries 1022 MUST be cleared. 1024 The TC (Traffic Class) field ([RFC3270], [RFC5129]) of each label 1025 stack entry SHOULD be set to 0, unless changed by policy at the 1026 originator of the sub-TLV. When pushing the label stack onto a 1027 packet, the TC of each label stack SHOULD be preserved, unless local 1028 policy results in a modification. 1030 The TTL (Time to Live) field of each label stack entry SHOULD be set 1031 to 255, unless changed to some other non-zero value by policy at the 1032 originator of the sub-TLV. When pushing the label stack onto a 1033 packet, the TTL of each label stack entry SHOULD be preserved, unless 1034 local policy results in a modification to some other non-zero value. 1035 If any label stack entry in the sub-TLV has a TTL value of zero, the 1036 router that is pushing the stack on a packet MUST change the value to 1037 a non-zero value, either 255 or some other value as determined by 1038 policy as discussed above. 1040 Note that this sub-TLV can appear within a TLV identifying any type 1041 of tunnel, not just within a TLV identifying an MPLS tunnel. 1042 However, if this sub-TLV appears within a TLV identifying an MPLS 1043 tunnel (or an MPLS-in-X tunnel), this sub-TLV plays the same role 1044 that would be played by an MPLS Encapsulation sub-TLV. Therefore, an 1045 MPLS Encapsulation sub-TLV is not defined. 1047 Although this specification does not supply detailed instructions for 1048 validating the received label stack, implementations might impose 1049 restrictions on the label stack they can support. If an invalid or 1050 unsupported label stack is received, the tunnel MAY be treated as not 1051 feasible according to the procedures of Section 6. 1053 3.7. Prefix-SID Sub-TLV (type code 11) 1055 [RFC8669] defines a BGP Path attribute known as the "Prefix-SID 1056 Attribute". This attribute is defined to contain a sequence of one 1057 or more TLVs, where each TLV is either a "Label-Index" TLV, or an 1058 "Originator SRGB (Source Routing Global Block)" TLV. 1060 This document defines a Prefix-SID sub-TLV. The Value field of the 1061 Prefix-SID sub-TLV can be set to any permitted value of the Value 1062 field of a BGP Prefix-SID attribute [RFC8669]. 1064 [RFC8669] only defines behavior when the Prefix-SID Attribute is 1065 attached to routes of type IPv4/IPv6 Labeled Unicast ([RFC4760], 1066 [RFC8277]), and it only defines values of the Prefix-SID Attribute 1067 for those cases. Therefore, similar limitations exist for the 1068 Prefix-SID sub-TLV: it SHOULD only be included in a BGP UPDATE 1069 message for one of the address families defined in [RFC8669]. If 1070 included in a BGP UPDATE for any other address family then it MUST be 1071 ignored. 1073 The Prefix-SID sub-TLV can occur in a TLV identifying any type of 1074 tunnel. If an Originator SRGB is specified in the sub-TLV, that SRGB 1075 MUST be interpreted to be the SRGB used by the tunnel's egress 1076 endpoint. The Label-Index, if present, is the Segment Routing SID 1077 that the tunnel's egress endpoint uses to represent the prefix 1078 appearing in the NLRI field of the BGP UPDATE to which the Tunnel 1079 Encapsulation attribute is attached. 1081 If a Label-Index is present in the Prefix-SID sub-TLV, then when a 1082 packet is sent through the tunnel identified by the TLV, if that 1083 tunnel is from a labeled address family, the corresponding MPLS label 1084 MUST be pushed on the packet's label stack. The corresponding MPLS 1085 label is computed from the Label-Index value and the SRGB of the 1086 route's originator, as specified in section 4.1 of [RFC8669]. 1088 The corresponding MPLS label is pushed on after the processing of the 1089 MPLS Label Stack sub-TLV, if present, as specified in Section 3.6. 1090 It is pushed on before any other labels (for example, a label 1091 embedded in UPDATE's NLRI, or a label determined by the procedures of 1092 Section 9), are pushed on the stack. 1094 The Prefix-SID sub-TLV has slightly different semantics than the 1095 Prefix-SID attribute. When the Prefix-SID attribute is attached to a 1096 given route, the BGP speaker that originally attached the attribute 1097 is expected to be in the same Segment Routing domain as the BGP 1098 speakers who receive the route with the attached attribute. The 1099 Label-Index tells the receiving BGP speakers what the prefix-SID is 1100 for the advertised prefix in that Segment Routing domain. When the 1101 Prefix-SID sub-TLV is used, there is no implication that the prefix- 1102 SID for the advertised prefix is the same in the Segment Routing 1103 domains of the BGP speaker that originated the sub-TLV and the BGP 1104 speaker that received it. 1106 4. Extended Communities Related to the Tunnel Encapsulation Attribute 1108 4.1. Encapsulation Extended Community 1110 The Encapsulation Extended Community is a Transitive Opaque Extended 1111 Community. 1113 The Encapsulation Extended Community encoding is as shown below 1115 0 1 2 3 1116 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 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 | 0x03 (1 Octet)| 0x0c (1 Octet)| Reserved (2 Octets) | 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | Reserved (2 Octets) | Tunnel Type (2 Octets) | 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 Figure 14: Encapsulation Extended Community 1125 The value of the high-order octet of the extended type field is 0x03, 1126 which indicates it's transitive. The value of the low-order octet of 1127 the extended type field is 0x0c. 1129 The last two octets of the Value field encode a tunnel type. 1131 This Extended Community may be attached to a route of any AFI/SAFI to 1132 which the Tunnel Encapsulation attribute may be attached. Each such 1133 Extended Community identifies a particular Tunnel Type, its semantics 1134 are the same as semantics of a Tunnel Encapsulation attribute Tunnel 1135 TLV for which the following three conditions all hold: 1137 1. it identifies the same Tunnel Type, 1138 2. it has a Tunnel Egress Endpoint sub-TLV for which one of the 1139 following two conditions holds: 1141 A. its "Address Family" subfield contains zero, or 1143 B. its "Address" subfield contains the address of the next hop 1144 field of the route to which the Tunnel Encapsulation 1145 attribute is attached 1147 3. it has no other sub-TLVs. 1149 Such a Tunnel TLV is called a "barebones" Tunnel TLV. 1151 The Encapsulation Extended Community was first defined in [RFC5512]. 1152 While it provides only a small subset of the functionality of the 1153 Tunnel Encapsulation attribute, it is used in a number of deployed 1154 applications, and is still needed for backwards compatibility. In 1155 situations where a tunnel could be encoded using a barebones TLV, it 1156 MUST be encoded using the corresponding Encapsulation Extended 1157 Community. Notwithstanding, an implementation MUST be prepared to 1158 process a tunnel received encoded as a barebones TLV. 1160 Note that for tunnel types of the form "X-in-Y", for example, MPLS- 1161 in-GRE, the Encapsulation Extended Community implies that only 1162 packets of the specified payload type "X" are to be carried through 1163 the tunnel of type "Y". Packets with other payload types MUST NOT be 1164 carried through such tunnels. See also Section 2. 1166 In the remainder of this specification, when a route is referred to 1167 as containing a Tunnel Encapsulation attribute with a TLV identifying 1168 a particular Tunnel Type, it implicitly includes the case where the 1169 route contains a Tunnel Encapsulation Extended Community identifying 1170 that Tunnel Type. 1172 4.2. Router's MAC Extended Community 1174 [I-D.ietf-bess-evpn-inter-subnet-forwarding] defines a Router's MAC 1175 Extended Community. This Extended Community, as its name implies, 1176 carries the MAC address of the advertising router. Since the VXLAN 1177 and NVGRE Encapsulation Sub-TLVs can also optionally carry a router's 1178 MAC, a conflict can arise if both the Router's MAC Extended Community 1179 and such an Encapsulation Sub-TLV are present at the same time but 1180 have different values. In case of such a conflict, the information 1181 in the Router's MAC Extended Community MUST be used. 1183 4.3. Color Extended Community 1185 The Color Extended Community is a Transitive Opaque Extended 1186 Community with the following encoding: 1188 0 1 2 3 1189 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 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 | 0x03 (1 Octet)| 0x0b (1 Octet)| Flags (2 Octets) | 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 | Color Value (4 Octets) | 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 Figure 15: Color Extended Community 1198 The value of the high-order octet of the extended type field is 0x03, 1199 which indicates it is transitive. The value of the low-order octet 1200 of the extended type field for this community is 0x0b. The color 1201 value is user defined and configured locally. No flags are defined 1202 in this document; this field MUST be set to zero by the originator 1203 and ignored by the receiver; the value MUST NOT be changed when 1204 propagating this Extended Community. The Color Value field is 1205 encoded as 4 octet value by the administrator and is outside the 1206 scope of this document. For the use of this Extended Community 1207 please see Section 8. 1209 5. Special Considerations for IP-in-IP Tunnels 1211 In certain situations with an IP fabric underlay, one could have a 1212 tunnel overlay with the tunnel type IP-in-IP. The egress BGP speaker 1213 can advertise the IP-in-IP tunnel endpoint address in the Tunnel 1214 Egress Endpoint sub-TLV. When the Tunnel type of the TLV is IP-in- 1215 IP, it will not have a Virtual Network Identifier. However, the 1216 tunnel egress endpoint address can be used in identifying the 1217 forwarding table to use for making the forwarding decisions to 1218 forward the payload. 1220 6. Semantics and Usage of the Tunnel Encapsulation attribute 1222 The BGP Tunnel Encapsulation attribute MAY be carried in any BGP 1223 UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6 1224 Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast), 1225 1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast), 1226 or 25/70 (Ethernet VPN, usually known as EVPN)). Use of the Tunnel 1227 Encapsulation attribute in BGP UPDATE messages of other AFI/SAFIs is 1228 outside the scope of this document. 1230 There is no significance to the order in which the TLVs occur within 1231 the Tunnel Encapsulation attribute. Multiple TLVs may occur for a 1232 given Tunnel Type; each such TLV is regarded as describing a 1233 different tunnel. (This also applies if the Tunnel Encapsulation 1234 Extended Community encoding is used.) 1236 The decision to attach a Tunnel Encapsulation attribute to a given 1237 BGP UPDATE is determined by policy. The set of TLVs and sub-TLVs 1238 contained in the attribute is also determined by policy. 1240 Suppose that: 1242 o a given packet P must be forwarded by router R; 1244 o the path along which P is to be forwarded is determined by BGP 1245 UPDATE U; 1247 o UPDATE U has a Tunnel Encapsulation attribute, containing at least 1248 one TLV that identifies a "feasible tunnel" for packet P. A 1249 tunnel is considered feasible if it has the following four 1250 properties: 1252 * The Tunnel Type is supported (that is, router R knows how to 1253 set up tunnels of that type, how to create the encapsulation 1254 header for tunnels of that type, etc.) 1256 * The tunnel is of a type that can be used to carry packet P (for 1257 example, an MPLS-in-UDP tunnel would not be a feasible tunnel 1258 for carrying an IP packet, unless the IP packet can first be 1259 encapsulated in a MPLS packet). 1261 * The tunnel is specified in a TLV whose Tunnel Egress Endpoint 1262 sub-TLV identifies an IP address that is reachable. The 1263 reachability condition is evaluated as per [RFC4271]. If the 1264 IP address is reachable via more than one forwarding table, 1265 local policy is used to determine which table to use. 1267 * There is no local policy that prevents the use of the tunnel. 1269 Then router R MUST send packet P through one of the feasible tunnels 1270 identified in the Tunnel Encapsulation attribute of UPDATE U. 1272 If the Tunnel Encapsulation attribute contains several TLVs (that is, 1273 if it specifies several feasible tunnels), router R may choose any 1274 one of those tunnels, based upon local policy. If any Tunnel TLV 1275 contains one or more Color sub-TLVs (Section 3.4.2) and/or the 1276 Protocol Type sub-TLV (Section 3.4.1), the choice of tunnel may be 1277 influenced by these sub-TLVs. Many other factors, for example 1278 minimization of encapsulation header overhead, could also be used to 1279 influence selection. 1281 The reachability to the address of the egress endpoint of the tunnel 1282 may change over time, directly impacting the feasibility of the 1283 tunnel. A tunnel that is not feasible at some moment, may become 1284 feasible at a later time when its egress endpoint address is 1285 reachable. The router may start using the newly feasible tunnel 1286 instead of an existing one. How this decision is made is outside the 1287 scope of this document. 1289 Once it is determined to send a packet through the tunnel specified 1290 in a particular Tunnel TLV of a particular Tunnel Encapsulation 1291 attribute, then the tunnel's egress endpoint address is the IP 1292 address contained in the Tunnel Egress Endpoint sub-TLV. If the 1293 Tunnel TLV contains a Tunnel Egress Endpoint sub-TLV whose Value 1294 field is all zeroes, then the tunnel's egress endpoint is the address 1295 of the Next Hop of the BGP Update containing the Tunnel Encapsulation 1296 attribute. The address of the tunnel egress endpoint generally 1297 appears in a "destination address" field of the encapsulation. 1299 The full set of procedures for sending a packet through a particular 1300 Tunnel Type to a particular tunnel egress endpoint depends upon the 1301 tunnel type, and is outside the scope of this document. Note that 1302 some tunnel types may require the execution of an explicit tunnel 1303 setup protocol before they can be used for carrying data. Other 1304 tunnel types may not require any tunnel setup protocol. 1306 Sending a packet through a tunnel always requires that the packet be 1307 encapsulated, with an encapsulation header that is appropriate for 1308 the Tunnel Type. The contents of the tunnel encapsulation header may 1309 be influenced by the Encapsulation sub-TLV. If there is no 1310 Encapsulation sub-TLV present, the router transmitting the packet 1311 through the tunnel must have a priori knowledge (for example, by 1312 provisioning) of how to fill in the various fields in the 1313 encapsulation header. 1315 A Tunnel Encapsulation attribute may contain several TLVs that all 1316 specify the same Tunnel Type. Each TLV should be considered as 1317 specifying a different tunnel. Two tunnels of the same type may have 1318 different Tunnel Egress Endpoint sub-TLVs, different Encapsulation 1319 sub-TLVs, etc. Choosing between two such tunnels is a matter of 1320 local policy. 1322 Once router R has decided to send packet P through a particular 1323 tunnel, it encapsulates packet P appropriately and then forwards it 1324 according to the route that leads to the tunnel's egress endpoint. 1325 This route may itself be a BGP route with a Tunnel Encapsulation 1326 attribute. If so, the encapsulated packet is treated as the payload 1327 and is encapsulated according to the Tunnel Encapsulation attribute 1328 of that route. That is, tunnels may be "stacked". 1330 Notwithstanding anything said in this document, a BGP speaker MAY 1331 have local policy that influences the choice of tunnel, and the way 1332 the encapsulation is formed. A BGP speaker MAY also have a local 1333 policy that tells it to ignore the Tunnel Encapsulation attribute 1334 entirely or in part. Of course, interoperability issues must be 1335 considered when such policies are put into place. 1337 See also Section 13, which provides further specification regarding 1338 validation and exception cases. 1340 7. Routing Considerations 1342 7.1. Impact on the BGP Decision Process 1344 The presence of the Tunnel Encapsulation attribute affects the BGP 1345 best route selection algorithm. If a route includes the Tunnel 1346 Encapsulation attribute, and if that attribute includes no tunnel 1347 which is feasible, then that route MUST NOT be considered resolvable 1348 for the purposes of Route Resolvability Condition [RFC4271] 1349 Section 9.1.2.1. 1351 7.2. Looping, Mutual Recursion, Etc. 1353 Consider a packet destined for address X. Suppose a BGP UPDATE for 1354 address prefix X carries a Tunnel Encapsulation attribute that 1355 specifies a tunnel egress endpoint of Y, and suppose that a BGP 1356 UPDATE for address prefix Y carries a Tunnel Encapsulation attribute 1357 that specifies a tunnel egress endpoint of X. It is easy to see that 1358 this can have no good outcome. [RFC4271] describes an analogous case 1359 as mutually recursive routes. 1361 This could happen as a result of misconfiguration, either accidental 1362 or intentional. It could also happen if the Tunnel Encapsulation 1363 attribute were altered by a malicious agent. Implementations should 1364 be aware that such an attack will result in unresolvable BGP routes 1365 due to the mutually recursive relationship. This document does not 1366 specify a maximum number of recursions; that is an implementation- 1367 specific matter. 1369 Improper setting (or malicious altering) of the Tunnel Encapsulation 1370 attribute could also cause data packets to loop. Suppose a BGP 1371 UPDATE for address prefix X carries a Tunnel Encapsulation attribute 1372 that specifies a tunnel egress endpoint of Y. Suppose router R 1373 receives and processes the advertisement. When router R receives a 1374 packet destined for X, it will apply the encapsulation and send the 1375 encapsulated packet to Y. Y will decapsulate the packet and forward 1376 it further. If Y is further away from X than is router R, it is 1377 possible that the path from Y to X will traverse R. This would cause 1378 a long-lasting routing loop. The control plane itself cannot detect 1379 this situation, though a TTL field in the payload packets would 1380 prevent any given packet from looping infinitely. 1382 During the deployment of techniques as described in this document, 1383 operators are encouraged to avoid mutually recursive route and/or 1384 tunnel dependencies. There is greater potential for such scenarios 1385 to arise when the tunnel egress endpoint for a given prefix differs 1386 from the address of the next hop for that prefix. 1388 8. Recursive Next Hop Resolution 1390 Suppose that: 1392 o a given packet P must be forwarded by router R1; 1394 o the path along which P is to be forwarded is determined by BGP 1395 UPDATE U1; 1397 o UPDATE U1 does not have a Tunnel Encapsulation attribute; 1399 o the address of the next hop of UPDATE U1 is router R2; 1401 o the best route to router R2 is a BGP route that was advertised in 1402 UPDATE U2; 1404 o UPDATE U2 has a Tunnel Encapsulation attribute. 1406 Then packet P MUST be sent through one of the tunnels identified in 1407 the Tunnel Encapsulation attribute of UPDATE U2. See Section 6 for 1408 further details. 1410 However, suppose that one of the TLVs in U2's Tunnel Encapsulation 1411 attribute contains one or more Color Sub-TLVs. In that case, packet 1412 P MUST NOT be sent through the tunnel contained in that TLV, unless 1413 U1 is carrying a Color Extended Community that is identified in one 1414 of U2's Color Sub-TLVs. 1416 The procedures in this section presuppose that U1's address of the 1417 next hop resolves to a BGP route, and that U2's next hop resolves 1418 (perhaps after further recursion) to a non-BGP route. 1420 9. Use of Virtual Network Identifiers and Embedded Labels when Imposing 1421 a Tunnel Encapsulation 1423 If the TLV specifying a tunnel contains an MPLS Label Stack sub-TLV, 1424 then when sending a packet through that tunnel, the procedures of 1425 Section 3.6 are applied before the procedures of this section. 1427 If the TLV specifying a tunnel contains a Prefix-SID sub-TLV, the 1428 procedures of Section 3.7 are applied before the procedures of this 1429 section. If the TLV also contains an MPLS Label Stack sub-TLV, the 1430 procedures of Section 3.6 are applied before the procedures of 1431 Section 3.7. 1433 9.1. Tunnel Types without a Virtual Network Identifier Field 1435 If a Tunnel Encapsulation attribute is attached to an UPDATE of a 1436 labeled address family, there will be one or more labels specified in 1437 the UPDATE's NLRI. When a packet is sent through a tunnel specified 1438 in one of the attribute's TLVs, and that tunnel type does not contain 1439 a virtual network identifier field, the label or labels from the NLRI 1440 are pushed on the packet's label stack. The resulting MPLS packet is 1441 then further encapsulated, as specified by the TLV. 1443 9.2. Tunnel Types with a Virtual Network Identifier Field 1445 Two of the tunnel types that can be specified in a Tunnel 1446 Encapsulation TLV have virtual network identifier fields in their 1447 encapsulation headers. In the VXLAN encapsulation, this field is 1448 called the VNI (VXLAN Network Identifier) field; in the NVGRE 1449 encapsulation, this field is called the VSID (Virtual Subnet 1450 Identifier) field. 1452 When one of these tunnel encapsulations is imposed on a packet, the 1453 setting of the virtual network identifier field in the encapsulation 1454 header depends upon the contents of the Encapsulation sub-TLV (if one 1455 is present). When the Tunnel Encapsulation attribute is being 1456 carried in a BGP UPDATE of a labeled address family, the setting of 1457 the virtual network identifier field also depends upon the contents 1458 of the Embedded Label Handling sub-TLV (if present). 1460 This section specifies the procedures for choosing the value to set 1461 in the virtual network identifier field of the encapsulation header. 1462 These procedures apply only when the Tunnel Type is VXLAN or NVGRE. 1464 9.2.1. Unlabeled Address Families 1466 This sub-section applies when: 1468 o the Tunnel Encapsulation attribute is carried in a BGP UPDATE of 1469 an unlabeled address family, and 1471 o at least one of the attribute's TLVs identifies a Tunnel Type that 1472 uses a virtual network identifier, and 1474 o it has been determined to send a packet through one of those 1475 tunnels. 1477 If the TLV identifying the tunnel contains an Encapsulation sub-TLV 1478 whose V bit is set, the virtual network identifier field of the 1479 encapsulation header is set to the value of the virtual network 1480 identifier field of the Encapsulation sub-TLV. 1482 Otherwise, the virtual network identifier field of the encapsulation 1483 header is set to a configured value; if there is no configured value, 1484 the tunnel cannot be used. 1486 9.2.2. Labeled Address Families 1488 This sub-section applies when: 1490 o the Tunnel Encapsulation attribute is carried in a BGP UPDATE of a 1491 labeled address family, and 1493 o at least one of the attribute's TLVs identifies a Tunnel Type that 1494 uses a virtual network identifier, and 1496 o it has been determined to send a packet through one of those 1497 tunnels. 1499 9.2.2.1. When a Valid VNI has been Signaled 1501 If the TLV identifying the tunnel contains an Encapsulation sub-TLV 1502 whose V bit is set, the virtual network identifier field of the 1503 encapsulation header is set to the value of the virtual network 1504 identifier field of the Encapsulation sub-TLV. However, the Embedded 1505 Label Handling sub-TLV will determine label processing as described 1506 below. 1508 o If the TLV contains an Embedded Label Handling sub-TLV whose value 1509 is 1, the embedded label (from the NLRI of the route that is 1510 carrying the Tunnel Encapsulation attribute) appears at the top of 1511 the MPLS label stack in the encapsulation payload. 1513 o If the TLV does not contain an Embedded Label Handling sub-TLV, or 1514 it contains an Embedded Label Handling sub-TLV whose value is 2, 1515 the embedded label is ignored entirely. 1517 9.2.2.2. When a Valid VNI has not been Signaled 1519 If the TLV identifying the tunnel does not contain an Encapsulation 1520 sub-TLV whose V bit is set, the virtual network identifier field of 1521 the encapsulation header is set as follows: 1523 o If the TLV contains an Embedded Label Handling sub-TLV whose value 1524 is 1, then the virtual network identifier field of the 1525 encapsulation header is set to a configured value. 1527 If there is no configured value, the tunnel cannot be used. 1529 The embedded label (from the NLRI of the route that is carrying 1530 the Tunnel Encapsulation attribute) appears at the top of the MPLS 1531 label stack in the encapsulation payload. 1533 o If the TLV does not contain an Embedded Label Handling sub-TLV, or 1534 if it contains an Embedded Label Handling sub-TLV whose value is 1535 2, the embedded label is copied into the lower 3 octets of the 1536 virtual network identifier field of the encapsulation header. 1538 In this case, the payload may or may not contain an MPLS label 1539 stack, depending upon other factors. If the payload does contain 1540 an MPLS label stack, the embedded label does not appear in that 1541 stack. 1543 10. Applicability Restrictions 1545 In a given UPDATE of a labeled address family, the label embedded in 1546 the NLRI is generally a label that is meaningful only to the router 1547 represented by the address of the next hop. Certain of the 1548 procedures of Section 9.2.2.1 or Section 9.2.2.2 cause the embedded 1549 label to be carried by a data packet to the router whose address 1550 appears in the Tunnel Egress Endpoint sub-TLV. If the Tunnel Egress 1551 Endpoint sub-TLV does not identify the same router represented by the 1552 address of the next hop, sending the packet through the tunnel may 1553 cause the label to be misinterpreted at the tunnel's egress endpoint. 1554 This may cause misdelivery of the packet. Avoidance of this 1555 unfortunate outcome is a matter of network planning and design, and 1556 is outside the scope of this document. 1558 Note that if the Tunnel Encapsulation attribute is attached to a VPN- 1559 IP route [RFC4364], and if Inter-AS "option b" (see section 10 of 1560 [RFC4364]) is being used, and if the Tunnel Egress Endpoint sub-TLV 1561 contains an IP address that is not in same AS as the router receiving 1562 the route, it is very likely that the embedded label has been 1563 changed. Therefore use of the Tunnel Encapsulation attribute in an 1564 "Inter-AS option b" scenario is not recommended. 1566 Other documents may define other ways to signal tunnel information in 1567 BGP. For example, [RFC6514] defines the "P-Multicast Service 1568 Interface Tunnel" (PMSI Tunnel) attribute. In this specification, we 1569 do not consider the effects of advertising the Tunnel Encapsulation 1570 Attribute in conjunction with other forms of signaling tunnels. Any 1571 document specifying such joint use MUST provide details as to how 1572 interactions should be handled. 1574 11. Scoping 1576 The Tunnel Encapsulation attribute is defined as a transitive 1577 attribute, so that it may be passed along by BGP speakers that do not 1578 recognize it. However the Tunnel Encapsulation attribute MUST be 1579 used only within a well-defined scope, for example, within a set of 1580 Autonomous Systems that belong to a single administrative entity. If 1581 the attribute is distributed beyond its intended scope, packets may 1582 be sent through tunnels in a manner that is not intended. 1584 To prevent the Tunnel Encapsulation attribute from being distributed 1585 beyond its intended scope, any BGP speaker that understands the 1586 attribute MUST be able to filter the attribute from incoming BGP 1587 UPDATE messages. When the attribute is filtered from an incoming 1588 UPDATE, the attribute is neither processed nor distributed. This 1589 filtering SHOULD be possible on a per-BGP-session basis; finer 1590 granularities (for example, per route and/or per attribute TLV) MAY 1591 be supported. For each external BGP (EBGP) session, filtering of the 1592 attribute on incoming UPDATEs MUST be enabled by default. 1594 In addition, any BGP speaker that understands the attribute MUST be 1595 able to filter the attribute from outgoing BGP UPDATE messages. This 1596 filtering SHOULD be possible on a per-BGP-session basis. For each 1597 EBGP session, filtering of the attribute on outgoing UPDATEs MUST be 1598 enabled by default. 1600 Since the Tunnel Encapsulation Extended Community provides a subset 1601 of the functionality of the Tunnel Encapsulation attribute, these 1602 considerations apply equally in its case: any BGP speaker that 1603 understands it MUST be able to filter it from incoming BGP UPDATE 1604 messages, it MUST be possible to filter the Tunnel Encapsulation 1605 Extended Community from outgoing messages, and in both cases this 1606 filtering MUST be enabled by default for EBGP sessions. 1608 12. Operational Considerations 1610 A potential operational difficulty arises when tunnels are used, if 1611 the size of packets entering the tunnel exceeds the maximum 1612 transmission unit (MTU) the tunnel is capable of supporting. This 1613 difficulty can be exacerbated by stacking multiple tunnels, since 1614 each stacked tunnel header further reduces the supportable MTU. This 1615 issue is long-standing and well-known. The tunnel signaling provided 1616 in this specification does nothing to address this issue, nor to 1617 aggravate it (except insofar as it may further increase the 1618 popularity of tunneling). 1620 13. Validation and Error Handling 1622 The Tunnel Encapsulation attribute is a sequence of TLVs, each of 1623 which is a sequence of sub-TLVs. The final octet of a TLV is 1624 determined by its length field. Similarly, the final octet of a sub- 1625 TLV is determined by its length field. The final octet of a TLV MUST 1626 also be the final octet of its final sub-TLV. If this is not the 1627 case, the TLV MUST be considered to be malformed, and the "Treat-as- 1628 withdraw" procedure of [RFC7606] is applied. 1630 If a Tunnel Encapsulation attribute does not have any valid TLVs, or 1631 it does not have the transitive bit set, the "Treat-as-withdraw" 1632 procedure of [RFC7606] is applied. 1634 If a Tunnel Encapsulation attribute can be parsed correctly, but 1635 contains a TLV whose Tunnel Type is not recognized by a particular 1636 BGP speaker, that BGP speaker MUST NOT consider the attribute to be 1637 malformed. Rather, it MUST interpret the attribute as if that TLV 1638 had not been present. If the route carrying the Tunnel Encapsulation 1639 attribute is propagated with the attribute, the unrecognized TLV MUST 1640 remain in the attribute. 1642 The following sub-TLVs defined in this document MUST NOT occur more 1643 than once in a given Tunnel TLV: Tunnel Egress Endpoint (discussed 1644 below), Encapsulation, DS, UDP Destination Port, Embedded Label 1645 Handling, MPLS Label Stack, Prefix-SID. If a Tunnel TLV has more 1646 than one of any of these sub-TLVs, all but the first occurrence of 1647 each such sub-TLV type MUST be disregarded. However, the Tunnel TLV 1648 containing them MUST NOT be considered to be malformed, and all the 1649 sub-TLVs MUST be propagated if the route carrying the Tunnel 1650 Encapsulation attribute is propagated. 1652 The following sub-TLVs defined in this document may appear zero or 1653 more times in a given Tunnel TLV: Protocol Type, Color. Each 1654 occurrence of such sub-TLVs is meaningful. For example, the Color 1655 sub-TLV may appear multiple times to assign multiple colors to a 1656 tunnel. 1658 If a TLV of a Tunnel Encapsulation attribute contains a sub-TLV that 1659 is not recognized by a particular BGP speaker, the BGP speaker MUST 1660 process that TLV as if the unrecognized sub-TLV had not been present. 1661 If the route carrying the Tunnel Encapsulation attribute is 1662 propagated with the attribute, the unrecognized sub-TLV MUST remain 1663 in the attribute. 1665 In general, if a TLV contains a sub-TLV that is malformed, the sub- 1666 TLV MUST be treated as if it were an unrecognized sub-TLV. There is 1667 one exception to this rule -- if a TLV contains a malformed Tunnel 1668 Egress Endpoint sub-TLV (as defined in Section 3.1), the entire TLV 1669 MUST be ignored, and MUST be removed from the Tunnel Encapsulation 1670 attribute before the route carrying that attribute is distributed. 1672 Within a Tunnel Encapsulation attribute that is carried by a BGP 1673 UPDATE whose AFI/SAFI is one of those explicitly listed in the second 1674 paragraph of Section 6, a TLV that does not contain exactly one 1675 Tunnel Egress Endpoint sub-TLV MUST be treated as if it contained a 1676 malformed Tunnel Egress Endpoint sub-TLV. 1678 A TLV identifying a particular Tunnel Type may contain a sub-TLV that 1679 is meaningless for that Tunnel Type. For example, perhaps the TLV 1680 contains a UDP Destination Port sub-TLV, but the identified tunnel 1681 type does not use UDP encapsulation at all, or a tunnel of the form 1682 "X-in-Y" contains a Protocol Type sub-TLV that specifies something 1683 other than "X". Sub-TLVs of this sort MUST be disregarded. That is, 1684 they MUST NOT affect the creation of the encapsulation header. 1685 However, the sub-TLV MUST NOT be considered to be malformed, and MUST 1686 NOT be removed from the TLV before the route carrying the Tunnel 1687 Encapsulation attribute is distributed. An implementation MAY log a 1688 message when it encounters such a sub-TLV. 1690 14. IANA Considerations 1692 This document makes the following requests of IANA. (All 1693 registration procedures listed below are per their definitions in 1694 [RFC8126].) 1696 14.1. Obsoleting RFC 5512 1698 Because this document obsoletes RFC 5512, change all registration 1699 information that references [RFC5512] to instead reference this 1700 document. 1702 14.2. Obsoleting Code Points Assigned by RFCs 5566 1704 Since this document obsoletes RFC 5566, the code points assigned by 1705 that RFC are similarly obsoleted. Specifically, the following code 1706 points should be marked as deprecated. 1708 In the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry: 1710 +-------+---------------------------------------------+ 1711 | Value | Name | 1712 +-------+---------------------------------------------+ 1713 | 3 | Transmit tunnel endpoint | 1714 | 4 | IPsec in Tunnel-mode | 1715 | 5 | IP in IP tunnel with IPsec Transport Mode | 1716 | 6 | MPLS-in-IP tunnel with IPsec Transport Mode | 1717 +-------+---------------------------------------------+ 1719 And in the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry: 1721 +-------+----------------------------+ 1722 | Value | Name | 1723 +-------+----------------------------+ 1724 | 3 | IPsec Tunnel Authenticator | 1725 +-------+----------------------------+ 1727 14.3. BGP Tunnel Encapsulation Parameters Grouping 1729 Create a new registry grouping, to be named "BGP Tunnel Encapsulation 1730 Parameters". 1732 14.4. BGP Tunnel Encapsulation Attribute Tunnel Types 1734 Relocate the "BGP Tunnel Encapsulation Attribute Tunnel Types" 1735 registry to be under the "BGP Tunnel Encapsulation Parameters" 1736 grouping. 1738 14.5. Subsequent Address Family Identifiers 1740 Modify the "Subsequent Address Family Identifiers" registry to 1741 indicate that the Encapsulation SAFI (value 7) is obsoleted. This 1742 document should be the reference. 1744 14.6. BGP Tunnel Encapsulation Attribute Sub-TLVs 1746 Relocate the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry 1747 to be under the "BGP Tunnel Encapsulation Parameters" grouping. 1749 Add the following note to the registry: 1751 If the Sub-TLV Type is in the range from 0 to 127 inclusive, the 1752 Sub-TLV Length field contains one octet. If the Sub-TLV Type is 1753 in the range from 128-255 inclusive, the Sub-TLV Length field 1754 contains two octets. 1756 Change the registration policy of the registry to the following: 1758 +----------+-------------------------+ 1759 | Value(s) | Registration Procedure | 1760 +----------+-------------------------+ 1761 | 0 | Reserved | 1762 | 1-63 | Standards Action | 1763 | 64-125 | First Come First Served | 1764 | 126-127 | Experimental Use | 1765 | 128-191 | Standards Action | 1766 | 192-252 | First Come First Served | 1767 | 253-254 | Experimental Use | 1768 | 255 | Reserved | 1769 +----------+-------------------------+ 1771 Rename the following entries within the registry: 1773 +-------+-----------------+------------------------+ 1774 | Value | Old Name | New Name | 1775 +-------+-----------------+------------------------+ 1776 | 6 | Remote Endpoint | Tunnel Egress Endpoint | 1777 | 7 | IPv4 DS Field | DS Field | 1778 +-------+-----------------+------------------------+ 1780 14.7. Flags Field of VXLAN Encapsulation sub-TLV 1782 Create a registry named "Flags Field of VXLAN Encapsulation sub-TLV" 1783 under the "BGP Tunnel Encapsulation Parameters" grouping. The 1784 registration policy for this registry is "Standards Action". The 1785 minimum possible value is 0, the maximum is 7. 1787 The initial values for this new registry are indicated below. 1789 +--------------+-----------------+-----------------+ 1790 | Bit Position | Description | Reference | 1791 +--------------+-----------------+-----------------+ 1792 | 0 | V (VN-ID) | (this document) | 1793 | 1 | M (MAC Address) | (this document) | 1794 +--------------+-----------------+-----------------+ 1796 14.8. Flags Field of NVGRE Encapsulation sub-TLV 1798 Create a registry named "Flags Field of NVGRE Encapsulation sub-TLV" 1799 under the "BGP Tunnel Encapsulation Parameters" grouping. The 1800 registration policy for this registry is "Standards Action". The 1801 minimum possible value is 0, the maximum is 7. 1803 The initial values for this new registry are indicated below. 1805 +--------------+-----------------+-----------------+ 1806 | Bit Position | Description | Reference | 1807 +--------------+-----------------+-----------------+ 1808 | 0 | V (VN-ID) | (this document) | 1809 | 1 | M (MAC Address) | (this document) | 1810 +--------------+-----------------+-----------------+ 1812 14.9. Embedded Label Handling sub-TLV 1814 Create a registry named "Embedded Label Handling sub-TLV" under the 1815 "BGP Tunnel Encapsulation Parameters" grouping. The registration 1816 policy for this registry is "Standards Action". The minimum possible 1817 value is 0, the maximum is 255. 1819 The initial values for this new registry are indicated below. 1821 +-------+-------------------------------------+-----------------+ 1822 | Value | Description | Reference | 1823 +-------+-------------------------------------+-----------------+ 1824 | 0 | Reserved | (this document) | 1825 | 1 | Payload of MPLS with embedded label | (this document) | 1826 | 2 | no embedded label in payload | (this document) | 1827 +-------+-------------------------------------+-----------------+ 1829 14.10. Color Extended Community Flags 1831 Create a registry named "Color Extended Community Flags" under the 1832 "BGP Tunnel Encapsulation Parameters" grouping. The registration 1833 policy for this registry is "Standards Action". The minimum possible 1834 value is 0, the maximum is 15. 1836 No initial values are to be registered. The format of the registry 1837 is shown below. 1839 +--------------+-------------+-----------+ 1840 | Bit Position | Description | Reference | 1841 +--------------+-------------+-----------+ 1842 +--------------+-------------+-----------+ 1844 15. Security Considerations 1846 As Section 11 discusses, it is intended that the Tunnel Encapsulation 1847 attribute be used only within a well-defined scope, for example, 1848 within a set of Autonomous Systems that belong to a single 1849 administrative entity. As long as the filtering mechanisms discussed 1850 in that section are applied diligently, an attacker outside the scope 1851 would not be able to use the Tunnel Encapsulation attribute in an 1852 attack. This leaves open the questions of attackers within the scope 1853 (for example, a compromised router) and failures in filtering that 1854 allow an external attack to succeed. 1856 As [RFC4272] discusses, BGP is vulnerable to traffic diversion 1857 attacks. The Tunnel Encapsulation attribute adds a new means by 1858 which an attacker could cause traffic to be diverted from its normal 1859 path, especially when the Tunnel Egress Endpoint sub-TLV is used. 1860 Such an attack would differ from pre-existing vulnerabilities in that 1861 traffic could be tunneled to a distant target across intervening 1862 network infrastructure, allowing an attack to potentially succeed 1863 more easily, since less infrastructure would have to be subverted. 1864 Potential consequences include "hijacking" of traffic (insertion of 1865 an undesired node in the path allowing for inspection or modification 1866 of traffic, or avoidance of security controls) or denial of service 1867 (directing traffic to a node that doesn't desire to receive it). 1869 In order to further mitigate the risk of diversion of traffic from 1870 its intended destination, Section 3.1.1 provides an optional 1871 procedure to check that the destination given in a Tunnel Egress 1872 Endpoint sub-TLV is within the AS that was the source of the route. 1873 One then has some level of assurance that the tunneled traffic is 1874 going to the same destination AS that it would have gone to had the 1875 Tunnel Encapsulation attribute not been present. As RFC 4272 1876 discusses, it's possible for an attacker to announce an inaccurate 1877 AS_PATH, therefore an attacker with the ability to inject a Tunnel 1878 Egress Endpoint sub-TLV could equally craft an AS_PATH that would 1879 pass the validation procedures of Section 3.1.1. BGP Origin 1880 Validation [RFC6811] and BGPsec [RFC8205] provide means to increase 1881 assurance that the origins being validated have not been falsified. 1883 Many tunnels carry traffic that embeds a destination address that 1884 comes from a non-global namespace. One example is MPLS VPNs. If a 1885 tunnel crosses from one namespace to another, without the necessary 1886 translation being performed for the embedded address(es), there 1887 exists a risk of misdelivery of traffic. If the traffic contains 1888 confidential data that's not otherwise protected (for example, by 1889 end-to-end encryption) then confidential information could be 1890 revealed. The restriction of applicability of the Tunnel 1891 Encapsulation attribute to a well-defined scope limits the likelihood 1892 of this occurring. See the discussion of "option b" in Section 10 1893 for further discussion of one such scenario. 1895 RFC 8402 specifies that "SR domain boundary routers MUST filter any 1896 external traffic" ([RFC8402] Section 8.1). For these purposes, 1897 traffic introduced into a SR domain using the Prefix-SID sub-TLV lies 1898 within the SR domain, even though the prefix-SIDs used by the routers 1899 at the two ends of the tunnel may be different, as discussed in 1900 Section 3.7. This implies that the duty to filter external traffic 1901 extends to all routers participating in such tunnels. 1903 16. Acknowledgments 1905 This document contains text from RFC 5512, authored by Pradosh 1906 Mohapatra and Eric Rosen. The authors of the current document wish 1907 to thank them for their contribution. RFC 5512 itself built upon 1908 prior work by Gargi Nalawade, Ruchi Kapoor, Dan Tappan, David Ward, 1909 Scott Wainner, Simon Barber, Lili Wang, and Chris Metz, whom the 1910 authors also thank for their contributions. Eric Rosen was the 1911 principal author of earlier versions of this document. 1913 The authors wish to thank Lou Berger, Ron Bonica, Martin Djernaes, 1914 John Drake, Susan Hares, Satoru Matsushima, Thomas Morin, Dhananjaya 1915 Rao, Ravi Singh, Harish Sitaraman, Brian Trammell, Xiaohu Xu, and 1916 Zhaohui Zhang for their review, comments, and/or helpful discussions. 1917 Alvaro Retana provided an especially comprehensive review. 1919 17. Contributor Addresses 1921 Below is a list of other contributing authors in alphabetical order: 1923 Randy Bush 1924 Internet Initiative Japan 1925 5147 Crystal Springs 1926 Bainbridge Island, Washington 98110 1927 United States 1929 Email: randy@psg.com 1931 Robert Raszuk 1932 Bloomberg LP 1933 731 Lexington Ave 1934 New York City, NY 10022 1935 United States 1937 Email: robert@raszuk.net 1939 Eric C. Rosen 1941 18. References 1943 18.1. Normative References 1945 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1946 Requirement Levels", BCP 14, RFC 2119, 1947 DOI 10.17487/RFC2119, March 1997, 1948 . 1950 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1951 "Definition of the Differentiated Services Field (DS 1952 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1953 DOI 10.17487/RFC2474, December 1998, 1954 . 1956 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1957 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1958 DOI 10.17487/RFC2784, March 2000, 1959 . 1961 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 1962 RFC 2890, DOI 10.17487/RFC2890, September 2000, 1963 . 1965 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1966 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1967 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1968 . 1970 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 1971 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 1972 Protocol Label Switching (MPLS) Support of Differentiated 1973 Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, 1974 . 1976 [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., 1977 "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", 1978 RFC 3931, DOI 10.17487/RFC3931, March 2005, 1979 . 1981 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 1982 "Encapsulating MPLS in IP or Generic Routing Encapsulation 1983 (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, 1984 . 1986 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1987 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1988 DOI 10.17487/RFC4271, January 2006, 1989 . 1991 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1992 "Multiprotocol Extensions for BGP-4", RFC 4760, 1993 DOI 10.17487/RFC4760, January 2007, 1994 . 1996 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 1997 Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 1998 2008, . 2000 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 2001 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 2002 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2003 2009, . 2005 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 2006 Austein, "BGP Prefix Origin Validation", RFC 6811, 2007 DOI 10.17487/RFC6811, January 2013, 2008 . 2010 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 2011 "Special-Purpose IP Address Registries", BCP 153, 2012 RFC 6890, DOI 10.17487/RFC6890, April 2013, 2013 . 2015 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 2016 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 2017 eXtensible Local Area Network (VXLAN): A Framework for 2018 Overlaying Virtualized Layer 2 Networks over Layer 3 2019 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 2020 . 2022 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 2023 Patel, "Revised Error Handling for BGP UPDATE Messages", 2024 RFC 7606, DOI 10.17487/RFC7606, August 2015, 2025 . 2027 [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network 2028 Virtualization Using Generic Routing Encapsulation", 2029 RFC 7637, DOI 10.17487/RFC7637, September 2015, 2030 . 2032 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2033 Writing an IANA Considerations Section in RFCs", BCP 26, 2034 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2035 . 2037 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2038 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2039 May 2017, . 2041 [RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, 2042 A., and H. Gredler, "Segment Routing Prefix Segment 2043 Identifier Extensions for BGP", RFC 8669, 2044 DOI 10.17487/RFC8669, December 2019, 2045 . 2047 18.2. Informative References 2049 [Ethertypes] 2050 "IANA Ethertype Registry", 2051 . 2054 [I-D.ietf-bess-evpn-inter-subnet-forwarding] 2055 Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. 2056 Rabadan, "Integrated Routing and Bridging in EVPN", draft- 2057 ietf-bess-evpn-inter-subnet-forwarding-11 (work in 2058 progress), October 2020. 2060 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 2061 RFC 4272, DOI 10.17487/RFC4272, January 2006, 2062 . 2064 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 2065 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2066 2006, . 2068 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 2069 Subsequent Address Family Identifier (SAFI) and the BGP 2070 Tunnel Encapsulation Attribute", RFC 5512, 2071 DOI 10.17487/RFC5512, April 2009, 2072 . 2074 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 2075 Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, 2076 . 2078 [RFC5566] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel 2079 Encapsulation Attribute", RFC 5566, DOI 10.17487/RFC5566, 2080 June 2009, . 2082 [RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load- 2083 Balancing for Mesh Softwires", RFC 5640, 2084 DOI 10.17487/RFC5640, August 2009, 2085 . 2087 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 2088 Encodings and Procedures for Multicast in MPLS/BGP IP 2089 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 2090 . 2092 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 2093 "Encapsulating MPLS in UDP", RFC 7510, 2094 DOI 10.17487/RFC7510, April 2015, 2095 . 2097 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 2098 Specification", RFC 8205, DOI 10.17487/RFC8205, September 2099 2017, . 2101 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 2102 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 2103 . 2105 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 2106 Uttaro, J., and W. Henderickx, "A Network Virtualization 2107 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 2108 DOI 10.17487/RFC8365, March 2018, 2109 . 2111 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 2112 Decraene, B., Litkowski, S., and R. Shakir, "Segment 2113 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 2114 July 2018, . 2116 Appendix A. Impact on RFC 8365 2118 [RFC8365] references RFC 5512 for its definition of the BGP 2119 Encapsulation Extended Community. That extended community is now 2120 defined in this document, in a way consistent with its previous 2121 definition. 2123 RFC 8365 talks in Section 6 about the use of the Encapsulation 2124 Extended Community to allow Network Virtualization Edge devices 2125 (NVEs) to signal their supported encapsulations. We note that with 2126 the introduction of this specification, the Tunnel Encapsulation 2127 Attribute can also be used for this purpose. For purposes where RFC 2128 8365 talks about "advertising supported encapsulations" (for example, 2129 in the second paragraph of Section 6), encapsulations advertised 2130 using the Tunnel Encapsulation Attribute should be considered equally 2131 with those advertised using the Encapsulation Extended Community. 2133 In particular, a review of Section 8.3.1 of RFC 8365 is called for, 2134 to consider whether the introduction of the Tunnel Encapsulation 2135 Attribute creates a need for any revisions to the split horizon 2136 procedures. 2138 RFC 8365 also refers to a draft version of this specification in the 2139 final paragraph of section 5.1.3. That paragraph references 2140 Section 8.2.2.2 of the draft. In this version of the document the 2141 correct reference would be Section 9.2.2.2. There are no substantive 2142 differences between the section in the referenced draft, and that in 2143 this document. 2145 Authors' Addresses 2147 Keyur Patel 2148 Arrcus, Inc 2149 2077 Gateway Pl 2150 San Jose, CA 95110 2151 United States 2153 Email: keyur@arrcus.com 2154 Gunter Van de Velde 2155 Nokia 2156 Copernicuslaan 50 2157 Antwerpen 2018 2158 Belgium 2160 Email: gunter.van_de_velde@nokia.com 2162 Srihari R. Sangli 2163 Juniper Networks 2165 Email: ssangli@juniper.net 2167 John Scudder 2168 Juniper Networks 2170 Email: jgs@juniper.net