idnits 2.17.1 draft-ietf-idr-tunnel-encaps-20.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 RFC5640, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC5566, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 10, 2020) is 1261 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 (==), 5 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, 5640 (if G. Van de Velde 5 approved) Nokia 6 Intended status: Standards Track S. Sangli 7 Expires: May 14, 2021 J. Scudder 8 Juniper Networks 9 November 10, 2020 11 The BGP Tunnel Encapsulation Attribute 12 draft-ietf-idr-tunnel-encaps-20 14 Abstract 16 RFC 5512 defines a BGP Path Attribute known as the "Tunnel 17 Encapsulation Attribute". This attribute allows one to specify a set 18 of tunnels. For each such tunnel, the attribute can provide the 19 information needed to create the tunnel and the corresponding 20 encapsulation header. The attribute can also provide information 21 that aids in choosing whether a particular packet is to be sent 22 through a particular tunnel. RFC 5512 states that the attribute is 23 only carried in BGP UPDATEs that use the "Encapsulation Subsequent 24 Address Family (Encapsulation SAFI)". This document deprecates the 25 Encapsulation SAFI (which has never been used in production), and 26 specifies semantics for the attribute when it is carried in UPDATEs 27 of certain other SAFIs. This document adds support for additional 28 Tunnel Types, and allows a remote tunnel endpoint address to be 29 specified for each tunnel. This document also provides support for 30 specifying fields of any inner or outer encapsulations that may be 31 used by a particular tunnel. 33 This document obsoletes RFC 5512. Since RFCs 5566 and 5640 rely on 34 RFC 5512, they are likewise obsoleted. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on May 14, 2021. 53 Copyright Notice 55 Copyright (c) 2020 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Brief Summary of RFC 5512 . . . . . . . . . . . . . . . . 4 72 1.2. Deficiencies in RFC 5512 . . . . . . . . . . . . . . . . 4 73 1.3. Use Case for The Tunnel Encapsulation Attribute . . . . . 5 74 1.4. Brief Summary of Changes from RFC 5512 . . . . . . . . . 6 75 1.5. Effects of Obsoleting RFCs 5566 and 5640 . . . . . . . . 7 76 2. The Tunnel Encapsulation Attribute . . . . . . . . . . . . . 8 77 3. Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . . . . . 9 78 3.1. The Tunnel Egress Endpoint Sub-TLV . . . . . . . . . . . 9 79 3.1.1. Validating the Address Field . . . . . . . . . . . . 11 80 3.2. Encapsulation Sub-TLVs for Particular Tunnel Types . . . 12 81 3.2.1. VXLAN . . . . . . . . . . . . . . . . . . . . . . . . 12 82 3.2.2. NVGRE . . . . . . . . . . . . . . . . . . . . . . . . 14 83 3.2.3. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . 16 84 3.2.4. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 3.2.5. MPLS-in-GRE . . . . . . . . . . . . . . . . . . . . . 17 86 3.3. Outer Encapsulation Sub-TLVs . . . . . . . . . . . . . . 17 87 3.3.1. DS Field . . . . . . . . . . . . . . . . . . . . . . 18 88 3.3.2. UDP Destination Port . . . . . . . . . . . . . . . . 18 89 3.4. Sub-TLVs for Aiding Tunnel Selection . . . . . . . . . . 18 90 3.4.1. Protocol Type Sub-TLV . . . . . . . . . . . . . . . . 19 91 3.4.2. Color Sub-TLV . . . . . . . . . . . . . . . . . . . . 19 92 3.5. Embedded Label Handling Sub-TLV . . . . . . . . . . . . . 20 93 3.6. MPLS Label Stack Sub-TLV . . . . . . . . . . . . . . . . 21 94 3.7. Prefix-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 23 95 4. Extended Communities Related to the Tunnel Encapsulation 96 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 24 97 4.1. Encapsulation Extended Community . . . . . . . . . . . . 24 98 4.2. Router's MAC Extended Community . . . . . . . . . . . . . 25 99 4.3. Color Extended Community . . . . . . . . . . . . . . . . 25 100 5. Special Considerations for IP-in-IP Tunnels . . . . . . . . . 26 101 6. Semantics and Usage of the Tunnel Encapsulation attribute . . 26 102 7. Routing Considerations . . . . . . . . . . . . . . . . . . . 29 103 7.1. Impact on the BGP Decision Process . . . . . . . . . . . 29 104 7.2. Looping, Mutual Recursion, Etc. . . . . . . . . . . . . . 29 105 8. Recursive Next Hop Resolution . . . . . . . . . . . . . . . . 30 106 9. Use of Virtual Network Identifiers and Embedded Labels when 107 Imposing a Tunnel Encapsulation . . . . . . . . . . . . . . . 30 108 9.1. Tunnel Types without a Virtual Network Identifier Field . 31 109 9.2. Tunnel Types with a Virtual Network Identifier Field . . 31 110 9.2.1. Unlabeled Address Families . . . . . . . . . . . . . 31 111 9.2.2. Labeled Address Families . . . . . . . . . . . . . . 32 112 10. Applicability Restrictions . . . . . . . . . . . . . . . . . 33 113 11. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 114 12. Operational Considerations . . . . . . . . . . . . . . . . . 34 115 13. Validation and Error Handling . . . . . . . . . . . . . . . . 35 116 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 117 14.1. Obsoleting RFC 5512 . . . . . . . . . . . . . . . . . . 36 118 14.2. Obsoleting Code Points Assigned by RFCs 5566 and 5640 . 36 119 14.3. BGP Tunnel Encapsulation Parameters Grouping . . . . . . 37 120 14.4. Subsequent Address Family Identifiers . . . . . . . . . 37 121 14.5. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . 37 122 14.6. Flags Field of VXLAN Encapsulation sub-TLV . . . . . . . 38 123 14.7. Flags Field of NVGRE Encapsulation sub-TLV . . . . . . . 38 124 14.8. Embedded Label Handling sub-TLV . . . . . . . . . . . . 39 125 14.9. Color Extended Community Flags . . . . . . . . . . . . . 39 126 15. Security Considerations . . . . . . . . . . . . . . . . . . . 39 127 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 128 17. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 40 129 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 130 18.1. Normative References . . . . . . . . . . . . . . . . . . 41 131 18.2. Informative References . . . . . . . . . . . . . . . . . 43 132 Appendix A. Impact on RFC 8365 . . . . . . . . . . . . . . . . . 45 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 135 1. Introduction 137 This document obsoletes RFC 5512. The deficiencies of RFC 5512, and 138 a summary of the changes made, are discussed in Sections 1.1-1.3. 139 The material from RFC 5512 that is retained has been incorporated 140 into this document. Since [RFC5566] and [RFC5640] rely on RFC 5512, 141 they are likewise obsoleted. 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in BCP 146 14 [RFC2119] [RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 1.1. Brief Summary of RFC 5512 151 [RFC5512] defines a BGP Path Attribute known as the Tunnel 152 Encapsulation attribute. This attribute consists of one or more 153 TLVs. Each TLV identifies a particular type of tunnel. Each TLV 154 also contains one or more sub-TLVs. Some of the sub-TLVs, e.g., the 155 "Encapsulation sub-TLV", contain information that may be used to form 156 the encapsulation header for the specified Tunnel Type. Other sub- 157 TLVs, e.g., the "color sub-TLV" and the "protocol sub-TLV", contain 158 information that aids in determining whether particular packets 159 should be sent through the tunnel that the TLV identifies. 161 [RFC5512] only allows the Tunnel Encapsulation attribute to be 162 attached to BGP UPDATE messages of the Encapsulation Address Family. 163 These UPDATE messages have an AFI (Address Family Identifier) of 1 or 164 2, and a SAFI of 7. In an UPDATE of the Encapsulation SAFI, the NLRI 165 (Network Layer Reachability Information) is an address of the BGP 166 speaker originating the UPDATE. Consider the following scenario: 168 o BGP speaker R1 has received and selected UPDATE U for local use; 170 o UPDATE U's SAFI is the Encapsulation SAFI; 172 o UPDATE U has the address R2 as its NLRI; 174 o UPDATE U has a Tunnel Encapsulation attribute. 176 o R1 has a packet, P, to transmit to destination D; 178 o R1's best route to D is a BGP route that has R2 as its next hop; 180 In this scenario, when R1 transmits packet P, it should transmit it 181 to R2 through one of the tunnels specified in U's Tunnel 182 Encapsulation attribute. The IP address of the tunnel egress 183 endpoint of each such tunnel is R2. Packet P is known as the 184 tunnel's "payload". 186 1.2. Deficiencies in RFC 5512 188 While the ability to specify tunnel information in a BGP UPDATE is 189 useful, the procedures of [RFC5512] have certain limitations: 191 o The requirement to use the "Encapsulation SAFI" presents an 192 unfortunate operational cost, as each BGP session that may need to 193 carry tunnel encapsulation information needs to be reconfigured to 194 support the Encapsulation SAFI. The Encapsulation SAFI has never 195 been used, and this requirement has served only to discourage the 196 use of the Tunnel Encapsulation attribute. 198 o There is no way to use the Tunnel Encapsulation attribute to 199 specify the tunnel egress endpoint address of a given tunnel; 200 [RFC5512] assumes that the tunnel egress endpoint of each tunnel 201 is specified as the NLRI of an UPDATE of the Encapsulation SAFI. 203 o If the respective best routes to two different address prefixes 204 have the same next hop, [RFC5512] does not provide a 205 straightforward method to associate each prefix with a different 206 tunnel. 208 o If a particular Tunnel Type requires an outer IP or UDP 209 encapsulation, there is no way to signal the values of any of the 210 fields of the outer encapsulation. 212 o In [RFC5512]'s specification of the sub-TLVs, each sub-TLV has 213 one-octet length field. In some cases, where a sub-TLV may 214 require more than 255 octets for its encoding, a two-octet length 215 field may be needed. 217 1.3. Use Case for The Tunnel Encapsulation Attribute 219 Consider the case of a router R1 forwarding an IP packet P. Let D be 220 P's IP destination address. R1 must look up D in its forwarding 221 table. Suppose that the "best match" route for D is route Q, where Q 222 is a BGP-distributed route whose "BGP next hop" is router R2. And 223 suppose further that the routers along the path from R1 to R2 have 224 entries for R2 in their forwarding tables, but do NOT have entries 225 for D in their forwarding tables. For example, the path from R1 to 226 R2 may be part of a "BGP-free core", where there are no BGP- 227 distributed routes at all in the core. Or, as in [RFC5565], D may be 228 an IPv4 address while the intermediate routers along the path from R1 229 to R2 may support only IPv6. 231 In cases such as this, in order for R1 to properly forward packet P, 232 it must encapsulate P and send P "through a tunnel" to R2. For 233 example, R1 may encapsulate P using GRE, L2TPv3, IP in IP, etc., 234 where the destination IP address of the encapsulation header is the 235 address of R2. 237 In order for R1 to encapsulate P for transport to R2, R1 must know 238 what encapsulation protocol to use for transporting different sorts 239 of packets to R2. R1 must also know how to fill in the various 240 fields of the encapsulation header. With certain encapsulation 241 types, this knowledge may be acquired by default or through manual 242 configuration. Other encapsulation protocols have fields such as 243 session id, key, or cookie that must be filled in. It would not be 244 desirable to require every BGP speaker to be manually configured with 245 the encapsulation information for every one of its BGP next hops. 247 This document specifies a way in which BGP itself can be used by a 248 given BGP speaker to tell other BGP speakers, "if you need to 249 encapsulate packets to be sent to me, here's the information you need 250 to properly form the encapsulation header". A BGP speaker signals 251 this information to other BGP speakers by using a new BGP attribute 252 type value, the BGP Tunnel Encapsulation Attribute. This attribute 253 specifies the encapsulation protocols that may be used as well as 254 whatever additional information (if any) is needed in order to 255 properly use those protocols. Other attributes, e.g., communities or 256 extended communities, may also be included. 258 1.4. Brief Summary of Changes from RFC 5512 260 This document addresses these deficiencies by: 262 o Deprecating the Encapsulation SAFI. 264 o Defining a new "Tunnel Egress Endpoint sub-TLV" (Section 3.1) that 265 can be included in any of the TLVs contained in the Tunnel 266 Encapsulation attribute. This sub-TLV can be used to specify the 267 remote endpoint address of a particular tunnel. 269 o Allowing the Tunnel Encapsulation attribute to be carried by BGP 270 UPDATEs of additional AFI/SAFIs. Appropriate semantics are 271 provided for this way of using the attribute. 273 o Defining a number of new sub-TLVs that provide additional 274 information that is useful when forming the encapsulation header 275 used to send a packet through a particular tunnel. 277 o Defining the sub-TLV type field so that a sub-TLV whose type is in 278 the range from 0 to 127 inclusive has a one-octet length field, 279 but a sub-TLV whose type is in the range from 128 to 255 inclusive 280 has a two-octet length field. 282 One of the sub-TLVs defined in [RFC5512] is the "Encapsulation sub- 283 TLV". For a given tunnel, the Encapsulation sub-TLV specifies some 284 of the information needed to construct the encapsulation header used 285 when sending packets through that tunnel. This document defines 286 Encapsulation sub-TLVs for a number of tunnel types not discussed in 288 [RFC5512]: VXLAN (Virtual Extensible Local Area Network, [RFC7348]), 289 NVGRE (Network Virtualization Using Generic Routing Encapsulation 290 [RFC7637]), and MPLS-in-GRE (MPLS in Generic Routing Encapsulation 291 [RFC4023]). MPLS-in-UDP [RFC7510] is also supported, but an 292 Encapsulation sub-TLV for it is not needed since there are no 293 additional parameters to be signaled. 295 Some of the encapsulations mentioned in the previous paragraph need 296 to be further encapsulated inside UDP and/or IP. [RFC5512] provides 297 no way to specify that certain information is to appear in these 298 outer IP and/or UDP encapsulations. This document provides a 299 framework for including such information in the TLVs of the Tunnel 300 Encapsulation attribute. 302 When the Tunnel Encapsulation attribute is attached to a BGP UPDATE 303 whose AFI/SAFI identifies one of the labeled address families, it is 304 not always obvious whether the label embedded in the NLRI is to 305 appear somewhere in the tunnel encapsulation header (and if so, 306 where), or whether it is to appear in the payload, or whether it can 307 be omitted altogether. This is especially true if the tunnel 308 encapsulation header itself contains a "virtual network identifier". 309 This document provides a mechanism that allows one to signal (by 310 using sub-TLVs of the Tunnel Encapsulation attribute) how one wants 311 to use the embedded label when the tunnel encapsulation has its own 312 virtual network identifier field. 314 [RFC5512] defines a Tunnel Encapsulation Extended Community that can 315 be used instead of the Tunnel Encapsulation attribute under certain 316 circumstances. This document describes (Section 4.1) how the Tunnel 317 Encapsulation Extended Community can be used in a backwards- 318 compatible fashion. It is possible to combine Tunnel Encapsulation 319 Extended Communities and Tunnel Encapsulation attributes in the same 320 BGP UPDATE in this manner. 322 1.5. Effects of Obsoleting RFCs 5566 and 5640 324 This specification obsoletes RFCs 5566 and 5640. This has the effect 325 of, in turn, obsoleting a number of code points defined in those 326 documents. From the "BGP Tunnel Encapsulation Attribute Tunnel 327 Types" registry, "Transmit tunnel endpoint" (type code 3), "IPsec in 328 Tunnel-mode" (type code 4), "IP in IP tunnel with IPsec Transport 329 Mode" (type code 5), and "MPLS-in-IP tunnel with IPsec Transport 330 Mode" (type code 6) are obsoleted. From the "BGP Tunnel 331 Encapsulation Attribute Sub-TLVs" registry, "IPsec Tunnel 332 Authenticator" (type code 3) and "Load-Balancing Block" (type code 5) 333 are obsoleted. See Section 14.2. 335 Because RFC 8365 depends on RFC 5640, it is similarly obsoleted. 336 This is further discussed in Appendix A. 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 | 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 404 The Tunnel Egress Endpoint sub-TLV, whose type code is 6, specifies 405 the address of the egress endpoint of the tunnel, that is, the 406 address of the router that will decapsulate the payload. Its value 407 field contains three 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 | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Address Family | Address ~ 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 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 If the Address Family subfield has any value other than IPv4 or IPv6, 466 the Tunnel Egress Endpoint sub-TLV is considered "unrecognized" (see 467 Section 13). If any of the following conditions hold, the Tunnel 468 Egress Endpoint sub-TLV is considered to be "malformed": 470 o The length of the sub-TLV's Value field is other than 6 added to 471 the defined length for the address family given in its Address 472 Family subfield. Therefore, for address family behaviors defined 473 in this document, the permitted values are: 475 * 10, if the Address Family subfield contains the value for IPv4. 477 * 22, if the Address Family subfield contains the value for IPv6. 479 * 6, if the Address Family subfield contains the value zero. 481 o The IP address in the sub-TLV's address subfield lies within a 482 block listed in the relevant Special-Purpose IP Address Registry 483 [RFC6890] with either a "destination" attribute value or a 484 "forwardable" attribute value of "false". (Such routes are 485 sometimes colloquially known as "Martians".) 487 o It can be determined that the IP address in the sub-TLV's address 488 subfield does not belong to the Autonomous System (AS) that 489 originated the route that contains the attribute. Section 3.1.1 490 describes an optional procedure to make this determination. 492 Error Handling is specified in Section 13. 494 If the Tunnel Egress Endpoint sub-TLV contains an IPv4 or IPv6 495 address that is valid but not reachable, the sub-TLV is not 496 considered to be malformed. 498 3.1.1. Validating the Address Field 500 This section provides a procedure that MAY be applied to validate 501 that the IP address in the sub-TLV's address subfield belongs to the 502 AS that originated the route that contains the attribute. (The 503 notion of "belonging to" an AS is expanded on below.) Doing this is 504 thought to increase confidence that when traffic is sent to the IP 505 address depicted in the Address Field, it will go to the same AS as 506 it would go to if the Tunnel Encapsulation Attribute were not 507 present, although of course it cannot guarantee it. See Section 15 508 for discussion of the limitations of this procedure. The principal 509 applicability of this procedure is in deployments that are not 510 strictly scoped. In deployments with strict scope, and especially 511 those scoped to a single AS, these procedures may not add substantial 512 benefit beyond those discussed in Section 11. 514 The Route Origin ASN (Autonomous System Number) of a BGP route that 515 includes a Tunnel Encapsulation Attribute can be determined by 516 inspection of the AS_PATH attribute, according to the procedure 517 specified in [RFC6811] Section 2. Call this value Route_AS. 519 In order to determine the Route Origin ASN of the address depicted in 520 the Address Field of the Tunnel Egress Endpoint sub-TLV, it is 521 necessary to consider the forwarding route, that is, the route that 522 will be used to forward traffic toward that address. This route is 523 determined by a recursive route lookup operation for that address, as 524 discussed in [RFC4271] Section 5.1.3. The relevant AS Path to 525 consider is the last one encountered while performing the recursive 526 lookup; the procedures of RFC6811 Section 2 are applied to that AS 527 Path to determine the Route Origin ASN. If no AS Path is encountered 528 at all, for example if that route's source is a protocol other than 529 BGP, the Route Origin ASN is the BGP speaker's own AS number. Call 530 this value Egress_AS. 532 If Route_AS does not equal Egress_AS, then the Tunnel Egress Endpoint 533 sub-TLV is considered not to be valid. In some cases a network 534 operator who controls a set of Autonomous Systems might wish to allow 535 a Tunnel Egress Endpoint to reside in an AS other than Route_AS; 536 configuration MAY allow for such a case, in which case the check 537 becomes, if Egress_AS is not within the configured set of permitted 538 AS numbers, then the Tunnel Egress Endpoint sub-TLV is considered to 539 be "malformed". 541 Note that if the forwarding route changes, this procedure MUST be 542 reapplied. As a result, a sub-TLV that was formerly considered valid 543 might become not valid, or vice-versa. 545 3.2. Encapsulation Sub-TLVs for Particular Tunnel Types 547 This section defines Encapsulation sub-TLVs for the following tunnel 548 types: VXLAN ([RFC7348]), NVGRE ([RFC7637]), MPLS-in-GRE ([RFC4023]), 549 L2TPv3 ([RFC3931]), and GRE ([RFC2784]). 551 Rules for forming the encapsulation based on the information in a 552 given TLV are given in Section 6 and Section 9. 554 Recall that the Tunnel Type itself is identified by the Tunnel Type 555 field in the attribute header (Section 2); the Encapsulation sub- 556 TLV's structure is inferred from this. Regardless of the Tunnel 557 Type, the sub-TLV type of the Encapsulation sub-TLV is 1. There are 558 also tunnel types for which it is not necessary to define an 559 Encapsulation sub-TLV, because there are no fields in the 560 encapsulation header whose values need to be signaled from the tunnel 561 egress endpoint. 563 3.2.1. VXLAN 565 This document defines an Encapsulation sub-TLV for VXLAN tunnels. 566 When the Tunnel Type is VXLAN (value 8), the length of the sub-TLV is 567 12 octets. The following is the structure of the value field in the 568 Encapsulation sub-TLV: 570 0 1 2 3 571 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 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 |V|M|R|R|R|R|R|R| VN-ID (3 Octets) | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | MAC Address (4 Octets) | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | MAC Address (2 Octets) | Reserved | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 Figure 4: VXLAN Encapsulation Sub-TLV Value Field 582 V: This bit is set to 1 to indicate that a VN-ID (Virtual Network 583 Identifier) is present in the Encapsulation sub-TLV. If set to 0, 584 the VN-ID field is disregarded. Please see Section 9. 586 M: This bit is set to 1 to indicate that a MAC Address is present 587 in the Encapsulation sub-TLV. If set to 0, the MAC Address field 588 is disregarded. 590 R: The remaining bits in the 8-bit flags field are reserved for 591 further use. They MUST always be set to 0 by the originator of 592 the sub-TLV. Intermediate routers MUST propagate them without 593 modification. Any receiving routers MUST ignore these bits upon a 594 receipt of the sub-TLV. 596 VN-ID: If the V bit is set, the VN-ID field contains a 3 octet VN- 597 ID value. If the V bit is not set, the VN-ID field MUST be set to 598 zero on transmission and disregarded on receipt. 600 MAC Address: If the M bit is set, this field contains a 6 octet 601 Ethernet MAC address. If the M bit is not set, this field MUST be 602 set to all zeroes on transmission and disregarded on receipt. 604 Reserved: MUST be set to zero on transmission and disregarded on 605 receipt. 607 When forming the VXLAN encapsulation header: 609 o The values of the V, M, and R bits are NOT copied into the flags 610 field of the VXLAN header. The flags field of the VXLAN header is 611 set as per [RFC7348]. 613 o If the M bit is set, the MAC Address is copied into the Inner 614 Destination MAC Address field of the Inner Ethernet Header (see 615 section 5 of [RFC7348]). 617 If the M bit is not set, and the payload being sent through the 618 VXLAN tunnel is an Ethernet frame, the Destination MAC Address 619 field of the Inner Ethernet Header is just the Destination MAC 620 Address field of the payload's Ethernet header. 622 If the M bit is not set, and the payload being sent through the 623 VXLAN tunnel is an IP or MPLS packet, the Inner Destination MAC 624 address field is set to a configured value; if there is no 625 configured value, the VXLAN tunnel cannot be used. 627 o If the V bit is not set, and the BGP UPDATE message has AFI/SAFI 628 other than Ethernet VPNs (EVPN) then the VXLAN tunnel cannot be 629 used. 631 o Section 9 describes how the VNI field of the VXLAN encapsulation 632 header is set. 634 Note that in order to send an IP packet or an MPLS packet through a 635 VXLAN tunnel, the packet must first be encapsulated in an Ethernet 636 header, which becomes the "inner Ethernet header" described in 637 [RFC7348]. The VXLAN Encapsulation sub-TLV may contain information 638 (e.g.,the MAC address) that is used to form this Ethernet header. 640 3.2.2. NVGRE 642 This document defines an Encapsulation sub-TLV for NVGRE tunnels. 643 When the Tunnel Type is NVGRE (value 9), the length of the sub-TLV is 644 12 octets. The following is the structure of the value field in the 645 Encapsulation sub-TLV: 647 0 1 2 3 648 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 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 |V|M|R|R|R|R|R|R| VN-ID (3 Octets) | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | MAC Address (4 Octets) | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | MAC Address (2 Octets) | Reserved | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 Figure 5: NVGRE Encapsulation Sub-TLV Value Field 659 V: This bit is set to 1 to indicate that a VN-ID is present in the 660 Encapsulation sub-TLV. If set to 0, the VN-ID field is 661 disregarded. Please see Section 9. 663 M: This bit is set to 1 to indicate that a MAC Address is present 664 in the Encapsulation sub-TLV. If set to 0, the MAC Address field 665 is disregarded. 667 R: The remaining bits in the 8-bit flags field are reserved for 668 further use. They MUST always be set to 0 by the originator of 669 the sub-TLV. Intermediate routers MUST propagate them without 670 modification. Any receiving routers MUST ignore these bits upon 671 receipt. 673 VN-ID: If the V bit is set, the VN-ID field contains a 3 octet VN- 674 ID value, used to set the NVGRE VSID (see Section 9). If the V 675 bit is not set, the VN-ID field MUST be set to zero on 676 transmission and disregarded on receipt. 678 MAC Address: If the M bit is set, this field contains a 6 octet 679 Ethernet MAC address. If the M bit is not set, this field MUST be 680 set to all zeroes on transmission and disregarded on receipt. 682 Reserved (two fields): MUST be set to zero on transmission and 683 disregarded on receipt. 685 When forming the NVGRE encapsulation header: 687 o The values of the V, M, and R bits are NOT copied into the flags 688 field of the NVGRE header. The flags field of the VXLAN header is 689 set as per [RFC7637]. 691 o If the M bit is set, the MAC Address is copied into the Inner 692 Destination MAC Address field of the Inner Ethernet Header (see 693 section 3.2 of [RFC7637]). 695 If the M bit is not set, and the payload being sent through the 696 NVGRE tunnel is an Ethernet frame, the Destination MAC Address 697 field of the Inner Ethernet Header is just the Destination MAC 698 Address field of the payload's Ethernet header. 700 If the M bit is not set, and the payload being sent through the 701 NVGRE tunnel is an IP or MPLS packet, the Inner Destination MAC 702 address field is set to a configured value; if there is no 703 configured value, the NVGRE tunnel cannot be used. 705 o If the V bit is not set, and the BGP UPDATE message has AFI/SAFI 706 other than Ethernet VPNs (EVPN) then the NVGRE tunnel cannot be 707 used. 709 o Section 9 describes how the VSID (Virtual Subnet Identifier) field 710 of the NVGRE encapsulation header is set. 712 3.2.3. L2TPv3 714 When the Tunnel Type of the TLV is L2TPv3 over IP (value 1), the 715 length of the sub-TLV is between 4 and 12 octets, depending on the 716 length of the cookie. The following is the structure of the value 717 field of the Encapsulation sub-TLV: 719 0 1 2 3 720 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 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Session ID (4 octets) | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | | 725 | Cookie (Variable) | 726 | | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 Figure 6: L2TPv3 Encapsulation Sub-TLV Value Field 731 Session ID: a non-zero 4-octet value locally assigned by the 732 advertising router that serves as a lookup key for the incoming 733 packet's context. 735 Cookie: an optional, variable length (encoded in octets -- 0 to 8 736 octets) value used by L2TPv3 to check the association of a 737 received data message with the session identified by the Session 738 ID. Generation and usage of the cookie value is as specified in 739 [RFC3931]. 741 The length of the cookie is not encoded explicitly, but can be 742 calculated as (sub-TLV length - 4). 744 3.2.4. GRE 746 When the Tunnel Type of the TLV is GRE (value 2), the length of the 747 sub-TLV is 4 octets. The following is the structure of the value 748 field of the Encapsulation sub-TLV: 750 0 1 2 3 751 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 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | GRE Key (4 octets) | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 Figure 7: GRE Encapsulation Sub-TLV 758 GRE Key: 4-octet field [RFC2890] that is generated by the 759 advertising router. Note that the key is optional. Unless a key 760 value is being advertised, the GRE Encapsulation sub-TLV MUST NOT 761 be present. 763 3.2.5. MPLS-in-GRE 765 When the Tunnel Type is MPLS-in-GRE (value 11), the length of the 766 sub-TLV is 4 octets. The following is the structure of the value 767 field of the Encapsulation sub-TLV: 769 0 1 2 3 770 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 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | GRE-Key (4 Octets) | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 Figure 8: MPLS-in-GRE Encapsulation Sub-TLV Value Field 777 GRE-Key: 4-octet field [RFC2890] that is generated by the 778 advertising router. Note that the key is optional. Unless a key 779 value is being advertised, the MPLS-in-GRE Encapsulation sub-TLV 780 MUST NOT be present. 782 Note that the GRE Tunnel Type defined in Section 3.2.4 can be used 783 instead of the MPLS-in-GRE Tunnel Type when it is necessary to 784 encapsulate MPLS in GRE. Including a TLV of the MPLS-in-GRE tunnel 785 type is equivalent to including a TLV of the GRE Tunnel Type that 786 also includes a Protocol Type sub-TLV (Section 3.4.1) specifying MPLS 787 as the protocol to be encapsulated. 789 While it is not really necessary to have both the GRE and MPLS-in-GRE 790 tunnel types, both are included for reasons of backwards 791 compatibility. 793 3.3. Outer Encapsulation Sub-TLVs 795 The Encapsulation sub-TLV for a particular Tunnel Type allows one to 796 specify the values that are to be placed in certain fields of the 797 encapsulation header for that Tunnel Type. However, some tunnel 798 types require an outer IP encapsulation, and some also require an 799 outer UDP encapsulation. The Encapsulation sub-TLV for a given 800 Tunnel Type does not usually provide a way to specify values for 801 fields of the outer IP and/or UDP encapsulations. If it is necessary 802 to specify values for fields of the outer encapsulation, additional 803 sub-TLVs must be used. This document defines two such sub-TLVs. 805 If an outer Encapsulation sub-TLV occurs in a TLV for a Tunnel Type 806 that does not use the corresponding outer encapsulation, the sub-TLV 807 MUST be treated as if it were an unknown type of sub-TLV. 809 3.3.1. DS Field 811 Most of the tunnel types that can be specified in the Tunnel 812 Encapsulation attribute require an outer IP encapsulation. The 813 Differentiated Services (DS) Field sub-TLV, whose type code is 7, can 814 be carried in the TLV of any such Tunnel Type. It specifies the 815 setting of the one-octet Differentiated Services field in the outer 816 IPv4 or IPv6 encapsulation (see [RFC2474]). Any one-octet value can 817 be transported; the semantics of the DSCP field is beyond the scope 818 of this document. The value field is always a single octet. 820 0 1 2 3 4 5 6 7 821 +-+-+-+-+-+-+-+-+ 822 | DS value | 823 +-+-+-+-+-+-+-+-+ 825 DS Field Sub-TLV Value Field 827 3.3.2. UDP Destination Port 829 Some of the tunnel types that can be specified in the Tunnel 830 Encapsulation attribute require an outer UDP encapsulation. 831 Generally there is a standard UDP Destination Port value for a 832 particular Tunnel Type. However, sometimes it is useful to be able 833 to use a non-standard UDP destination port. If a particular tunnel 834 type requires an outer UDP encapsulation, and it is desired to use a 835 UDP destination port other than the standard one, the port to be used 836 can be specified by including a UDP Destination Port sub-TLV, whose 837 type code is 8. The value field of this sub-TLV is always a two- 838 octet field, containing the port value. Any two-octet value other 839 than zero can be transported. If the reserved value zero is 840 received, the sub-TLV MUST be treated as malformed according to the 841 rules of Section 13. 843 0 1 844 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | UDP Port | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 UDP Destination Port Sub-TLV Value Field 851 3.4. Sub-TLVs for Aiding Tunnel Selection 852 3.4.1. Protocol Type Sub-TLV 854 The Protocol Type sub-TLV, whose type code is 2, MAY be included in a 855 given TLV to indicate the type of the payload packets that are 856 allowed to be encapsulated with the tunnel parameters that are being 857 signaled in the TLV. Packets with other payload types MUST NOT be 858 encapsulated in the relevant tunnel. The value field of the sub-TLV 859 contains a 2-octet value from IANA's "ETHER TYPES" registry 860 [Ethertypes]. If the reserved value 0xFFFF is received, the sub-TLV 861 MUST be treated as malformed according to the rules of Section 13. 863 0 1 864 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | Ethertype | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 Protocol Type Sub-TLV Value Field 871 For example, if there are three L2TPv3 sessions, one carrying IPv4 872 packets, one carrying IPv6 packets, and one carrying MPLS packets, 873 the egress router will include three TLVs of L2TPv3 encapsulation 874 type, each specifying a different Session ID and a different payload 875 type. The Protocol Type sub-TLV for these will be IPv4 (protocol 876 type = 0x0800), IPv6 (protocol type = 0x86dd), and MPLS (protocol 877 type = 0x8847), respectively. This informs the ingress routers of 878 the appropriate encapsulation information to use with each of the 879 given protocol types. Insertion of the specified Session ID at the 880 ingress routers allows the egress to process the incoming packets 881 correctly, according to their protocol type. 883 Note that for tunnel types whose names are of the form "X-in-Y", 884 e.g., "MPLS-in-GRE", only packets of the specified payload type "X" 885 are to be carried through the tunnel of type "Y". This is the 886 equivalent of specifying a Tunnel Type "Y" and including in its TLV a 887 Protocol Type sub-TLV (see Section 3.4.1) specifying protocol "X". 888 If the Tunnel Type is "X-in-Y", it is unnecessary, though harmless, 889 to explicitly include a Protocol Type sub-TLV specifying "X". Also, 890 for "X-in-Y" type tunnels, a Protocol Type sub-TLV specifying 891 anything other than "X" MUST be ignored; this is discussed further in 892 Section 13. 894 3.4.2. Color Sub-TLV 896 The Color sub-TLV, whose type code is 4, MAY be used as a way to 897 "color" the corresponding Tunnel TLV. The value field of the sub-TLV 898 is eight octets long, and consists of a Color Extended Community, as 899 defined in Section 4.3. For the use of this sub-TLV and Extended 900 Community, please see Section 8. 902 The format of the value field is depicted in Figure 11. 904 If the Length field of a Color sub-TLV has a value other than 8, or 905 the first two octets of its value field are not 0x030b, the sub-TLV 906 MUST be treated as if it were an unrecognized sub-TLV (see 907 Section 13). 909 3.5. Embedded Label Handling Sub-TLV 911 Certain BGP address families (corresponding to particular AFI/SAFI 912 pairs, e.g., 1/4, 2/4, 1/128, 2/128) have MPLS labels embedded in 913 their NLRIs. The term "embedded label" is used to refer to the MPLS 914 label that is embedded in an NLRI, and the term "labeled address 915 family" to refer to any AFI/SAFI that has embedded labels. 917 Some of the tunnel types (e.g., VXLAN and NVGRE) that can be 918 specified in the Tunnel Encapsulation attribute have an encapsulation 919 header containing a "Virtual Network" identifier of some sort. The 920 Encapsulation sub-TLVs for these tunnel types may optionally specify 921 a value for the virtual network identifier. 923 Suppose a Tunnel Encapsulation attribute is attached to an UPDATE of 924 a labeled address family, and it is decided to use a particular 925 tunnel (specified in one of the attribute's TLVs) for transmitting a 926 packet that is being forwarded according to that UPDATE. When 927 forming the encapsulation header for that packet, different 928 deployment scenarios require different handling of the embedded label 929 and/or the virtual network identifier. The Embedded Label Handling 930 sub-TLV can be used to control the placement of the embedded label 931 and/or the virtual network identifier in the encapsulation. 933 The Embedded Label Handling sub-TLV, whose type code is 9, may be 934 included in any TLV of the Tunnel Encapsulation attribute. If the 935 Tunnel Encapsulation attribute is attached to an UPDATE of a non- 936 labeled address family, then the sub-TLV MUST be disregarded. If the 937 sub-TLV is contained in a TLV whose Tunnel Type does not have a 938 virtual network identifier in its encapsulation header, the sub-TLV 939 MUST be disregarded. In those cases where the sub-TLV is ignored, it 940 SHOULD NOT be stripped from the TLV before the route is propagated. 942 The sub-TLV's Length field always contains the value 1, and its value 943 field consists of a single octet. The following values are defined: 945 1: The payload will be an MPLS packet with the embedded label at 946 the top of its label stack. 948 2: The embedded label is not carried in the payload, but is carried 949 either in the virtual network identifier field of the 950 encapsulation header, or else is ignored entirely. 952 If any value other than 1 or 2 is carried, the sub-TLV MUST be 953 considered malformed, according to the procedures of Section 13. 955 Please see Section 9 for the details of how this sub-TLV is used when 956 it is carried by an UPDATE of a labeled address family. 958 0 1 2 3 4 5 6 7 959 +-+-+-+-+-+-+-+-+ 960 | 0 or 1 | 961 +-+-+-+-+-+-+-+-+ 963 Embedded Label Handling Sub-TLV Value Field 965 3.6. MPLS Label Stack Sub-TLV 967 This sub-TLV, whose type code is 10, allows an MPLS label stack 968 ([RFC3032]) to be associated with a particular tunnel. 970 The length of the sub-TLV is a multiple of 4 octets and the value 971 field of this sub-TLV is a sequence of MPLS label stack entries. The 972 first entry in the sequence is the "topmost" label, the final entry 973 in the sequence is the "bottommost" label. When this label stack is 974 pushed onto a packet, this ordering MUST be preserved. 976 Each label stack entry has the following format: 978 0 1 2 3 979 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 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | Label | TC |S| TTL | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 Figure 9: MPLS Label Stack Sub-TLV Value Field 986 The fields are as defined in [RFC3032], [RFC5462]. 988 If a packet is to be sent through the tunnel identified in a 989 particular TLV, and if that TLV contains an MPLS Label Stack sub-TLV, 990 then the label stack appearing in the sub-TLV MUST be pushed onto the 991 packet before any other labels are pushed onto the packet. (See 992 Section 6 for further discussion.) 994 In particular, if the Tunnel Encapsulation attribute is attached to a 995 BGP UPDATE of a labeled address family, the contents of the MPLS 996 Label Stack sub-TLV MUST be pushed onto the packet before the label 997 embedded in the NLRI is pushed onto the packet. 999 If the MPLS Label Stack sub-TLV is included in a TLV identifying a 1000 Tunnel Type that uses virtual network identifiers (see Section 9), 1001 the contents of the MPLS Label Stack sub-TLV MUST be pushed onto the 1002 packet before the procedures of Section 9 are applied. 1004 The number of label stack entries in the sub-TLV MUST be determined 1005 from the sub-TLV length field. Thus it is not necessary to set the S 1006 bit in any of the label stack entries of the sub-TLV, and the setting 1007 of the S bit is ignored when parsing the sub-TLV. When the label 1008 stack entries are pushed onto a packet that already has a label 1009 stack, the S bits of all the entries being pushed MUST be cleared. 1010 When the label stack entries are pushed onto a packet that does not 1011 already have a label stack, the S bit of the bottommost label stack 1012 entry MUST be set, and the S bit of all the other label stack entries 1013 MUST be cleared. 1015 The TC (Traffic Class) field ([RFC3270], [RFC5129]) of each label 1016 stack entry SHOULD be set to 0, unless changed by policy at the 1017 originator of the sub-TLV. When pushing the label stack onto a 1018 packet, the TC of each label stack SHOULD be preserved, unless local 1019 policy results in a modification. 1021 The TTL (Time to Live) field of each label stack entry SHOULD be set 1022 to 255, unless changed to some other non-zero value by policy at the 1023 originator of the sub-TLV. When pushing the label stack onto a 1024 packet, the TTL of each label stack entry SHOULD be preserved, unless 1025 local policy results in a modification to some other non-zero value. 1026 If any label stack entry in the sub-TLV has a TTL value of zero, the 1027 router that is pushing the stack on a packet MUST change the value to 1028 a non-zero value, either 255 or some other value as determined by 1029 policy as discussed above. 1031 Note that this sub-TLV can appear within a TLV identifying any type 1032 of tunnel, not just within a TLV identifying an MPLS tunnel. 1033 However, if this sub-TLV appears within a TLV identifying an MPLS 1034 tunnel (or an MPLS-in-X tunnel), this sub-TLV plays the same role 1035 that would be played by an MPLS Encapsulation sub-TLV. Therefore, an 1036 MPLS Encapsulation sub-TLV is not defined. 1038 Although this specification does not supply detailed instructions for 1039 validating the received label stack, implementations might impose 1040 restrictions on the label stack they can support. If an invalid or 1041 unsupported label stack is received, the tunnel MAY be treated as not 1042 feasible according to the procedures of Section 6. 1044 3.7. Prefix-SID Sub-TLV 1046 [RFC8669] defines a BGP Path attribute known as the "Prefix-SID 1047 Attribute". This attribute is defined to contain a sequence of one 1048 or more TLVs, where each TLV is either a "Label-Index" TLV, or an 1049 "Originator SRGB (Source Routing Global Block)" TLV. 1051 This document defines a Prefix-SID sub-TLV, whose type code is 11. 1052 The value field of the Prefix-SID sub-TLV can be set to any permitted 1053 value of the value field of a BGP Prefix-SID attribute [RFC8669]. 1055 [RFC8669] only defines behavior when the Prefix-SID Attribute is 1056 attached to routes of type IPv4/IPv6 Labeled Unicast ([RFC4760], 1057 [RFC8277]), and it only defines values of the Prefix-SID Attribute 1058 for those cases. Therefore, similar limitations exist for the 1059 Prefix-SID sub-TLV: it SHOULD only be included in a BGP UPDATE 1060 message for one of the address families defined in [RFC8669]. If 1061 included in a BGP UPDATE for any other address family then it MUST be 1062 ignored. 1064 The Prefix-SID sub-TLV can occur in a TLV identifying any type of 1065 tunnel. If an Originator SRGB is specified in the sub-TLV, that SRGB 1066 MUST be interpreted to be the SRGB used by the tunnel's egress 1067 endpoint. The Label-Index, if present, is the Segment Routing SID 1068 that the tunnel's egress endpoint uses to represent the prefix 1069 appearing in the NLRI field of the BGP UPDATE to which the Tunnel 1070 Encapsulation attribute is attached. 1072 If a Label-Index is present in the Prefix-SID sub-TLV, then when a 1073 packet is sent through the tunnel identified by the TLV, if that 1074 tunnel is from a labeled address family, the corresponding MPLS label 1075 MUST be pushed on the packet's label stack. The corresponding MPLS 1076 label is computed from the Label-Index value and the SRGB of the 1077 route's originator, as specified in section 4.1 of [RFC8669]. 1079 The corresponding MPLS label is pushed on after the processing of the 1080 MPLS Label Stack sub-TLV, if present, as specified in Section 3.6. 1081 It is pushed on before any other labels (e.g., a label embedded in 1082 UPDATE's NLRI, or a label determined by the procedures of Section 9, 1083 are pushed on the stack. 1085 The Prefix-SID sub-TLV has slightly different semantics than the 1086 Prefix-SID attribute. When the Prefix-SID attribute is attached to a 1087 given route, the BGP speaker that originally attached the attribute 1088 is expected to be in the same Segment Routing domain as the BGP 1089 speakers who receive the route with the attached attribute. The 1090 Label-Index tells the receiving BGP speakers what the prefix-SID is 1091 for the advertised prefix in that Segment Routing domain. When the 1092 Prefix-SID sub-TLV is used, the receiving BGP speaker need not even 1093 be in the same Segment Routing Domain as the tunnel's egress 1094 endpoint, and there is no implication that the prefix-SID for the 1095 advertised prefix is the same in the Segment Routing domains of the 1096 BGP speaker that originated the sub-TLV and the BGP speaker that 1097 received it. 1099 4. Extended Communities Related to the Tunnel Encapsulation Attribute 1101 4.1. Encapsulation Extended Community 1103 The Encapsulation Extended Community is a Transitive Opaque Extended 1104 Community. 1106 The Encapsulation Extended Community encoding is as shown below 1108 0 1 2 3 1109 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 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 | 0x03 | 0x0c | Reserved | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 | Reserved | Tunnel Type | 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 Figure 10: Encapsulation Extended Community 1118 The value of the high-order octet of the extended type field is 0x03, 1119 which indicates it's transitive. The value of the low-order octet of 1120 the extended type field is 0x0c. 1122 The last two octets of the value field encode a tunnel type. 1124 This Extended Community may be attached to a route of any AFI/SAFI to 1125 which the Tunnel Encapsulation attribute may be attached. Each such 1126 Extended Community identifies a particular Tunnel Type, its semantics 1127 are the same as semantics of a Tunnel Encapsulation attribute Tunnel 1128 TLV for which the following three conditions all hold: 1130 1. it identifies the same Tunnel Type, 1132 2. it has a Tunnel Egress Endpoint sub-TLV for which one of the 1133 following two conditions holds: 1135 A. its "Address Family" subfield contains zero, or 1137 B. its "Address" subfield contains the address of the next hop 1138 field of the route to which the Tunnel Encapsulation 1139 attribute is attached 1141 3. it has no other sub-TLVs. 1143 Such a Tunnel TLV is called a "barebones" Tunnel TLV. 1145 The Encapsulation Extended Community was first defined in [RFC5512]. 1146 While it provides only a small subset of the functionality of the 1147 Tunnel Encapsulation attribute, it is used in a number of deployed 1148 applications, and is still needed for backwards compatibility. In 1149 situations where a tunnel could be encoded using a barebones TLV, it 1150 MUST be encoded using the corresponding Encapsulation Extended 1151 Community. Notwithstanding, an implementation MUST be prepared to 1152 process a tunnel received encoded as a barebones TLV 1154 Note that for tunnel types of the form "X-in-Y", e.g., MPLS-in-GRE, 1155 the Encapsulation Extended Community implies that only packets of the 1156 specified payload type "X" are to be carried through the tunnel of 1157 type "Y". Packets with other payload types MUST NOT be carried 1158 through such tunnels. See also Section 2. 1160 In the remainder of this specification, when a route is referred to 1161 as containing a Tunnel Encapsulation attribute with a TLV identifying 1162 a particular Tunnel Type, it implicitly includes the case where the 1163 route contains a Tunnel Encapsulation Extended Community identifying 1164 that Tunnel Type. 1166 4.2. Router's MAC Extended Community 1168 [I-D.ietf-bess-evpn-inter-subnet-forwarding] defines a Router's MAC 1169 Extended Community. This Extended Community, as its name implies, 1170 carries the MAC address of the advertising router. Since the VXLAN 1171 and NVGRE Encapsulation Sub-TLVs can also optionally carry a router's 1172 MAC, a conflict can arise if both the Router's MAC Extended Community 1173 and such an Encapsulation Sub-TLV are present at the same time but 1174 have different values. In case of such a conflict, the information 1175 in the Router's MAC Extended Community MUST be used. 1177 4.3. Color Extended Community 1179 The Color Extended Community is a Transitive Opaque Extended 1180 Community with the following encoding: 1182 0 1 2 3 1183 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 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | 0x03 | 0x0b | Flags | 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | Color Value | 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 Figure 11: Color Extended Community 1192 The value of the high-order octet of the extended type field is 0x03, 1193 which indicates it is transitive. The value of the low-order octet 1194 of the extended type field for this community is 0x0b. The color 1195 value is user defined and configured locally. No flags are defined 1196 in this document; this field MUST be set to zero by the originator 1197 and ignored by the receiver; the value MUST NOT be changed when 1198 propagating this Extended Community. The Color Value field is 1199 encoded as 4 octet value by the administrator and is outside the 1200 scope of this document. For the use of this Extended Community 1201 please see Section 8. 1203 5. Special Considerations for IP-in-IP Tunnels 1205 In certain situations with an IP fabric underlay, one could have a 1206 tunnel overlay with the tunnel type IP-in-IP. The egress BGP speaker 1207 can advertise the IP-in-IP tunnel endpoint address in the Tunnel 1208 Egress Endpoint sub-TLV. When the Tunnel type of the TLV is IP-in- 1209 IP, it will not have a Virtual Network Identifier. However, the 1210 tunnel egress endpoint address can be used in identifying the 1211 forwarding table to use for making the forwarding decisions to 1212 forward the payload. 1214 6. Semantics and Usage of the Tunnel Encapsulation attribute 1216 [RFC5512] specifies the use of the Tunnel Encapsulation attribute in 1217 BGP UPDATE messages of AFI/SAFI 1/7 and 2/7. That document restricts 1218 the use of this attribute to UPDATE messages of those SAFIs. This 1219 document removes that restriction. 1221 The BGP Tunnel Encapsulation attribute MAY be carried in any BGP 1222 UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6 1223 Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast), 1224 1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast), 1225 or 25/70 (Ethernet VPN, usually known as EVPN)). Use of the Tunnel 1226 Encapsulation attribute in BGP UPDATE messages of other AFI/SAFIs is 1227 outside the scope of this document. 1229 There is no significance to the order in which the TLVs occur within 1230 the Tunnel Encapsulation attribute. Multiple TLVs may occur for a 1231 given Tunnel Type; each such TLV is regarded as describing a 1232 different tunnel. (This also applies if the Tunnel Encapsulation 1233 Extended Community encoding is used.) 1235 The decision to attach a Tunnel Encapsulation attribute to a given 1236 BGP UPDATE is determined by policy. The set of TLVs and sub-TLVs 1237 contained in the attribute is also determined by policy. 1239 Suppose that: 1241 o a given packet P must be forwarded by router R; 1243 o the path along which P is to be forwarded is determined by BGP 1244 UPDATE U; 1246 o UPDATE U has a Tunnel Encapsulation attribute, containing at least 1247 one TLV that identifies a "feasible tunnel" for packet P. A 1248 tunnel is considered feasible if it has the following four 1249 properties: 1251 * The Tunnel Type is supported (i.e., router R knows how to set 1252 up tunnels of that type, how to create the encapsulation header 1253 for tunnels of that type, etc.) 1255 * The tunnel is of a type that can be used to carry packet P 1256 (e.g., an MPLS-in-UDP tunnel would not be a feasible tunnel for 1257 carrying an IP packet, unless the IP packet can first be 1258 encapsulated in a MPLS packet). 1260 * The tunnel is specified in a TLV whose Tunnel Egress Endpoint 1261 sub-TLV identifies an IP address that is reachable. The 1262 reachability condition is evaluated as per [RFC4271]. If the 1263 IP address is reachable via more than one forwarding table, 1264 local policy is used to determine which table to use. 1266 * There is no local policy that prevents the use of the tunnel. 1268 Then router R MUST send packet P through one of the feasible tunnels 1269 identified in the Tunnel Encapsulation attribute of UPDATE U. 1271 If the Tunnel Encapsulation attribute contains several TLVs (i.e., if 1272 it specifies several feasible tunnels), router R may choose any one 1273 of those tunnels, based upon local policy. If any Tunnel TLV 1274 contains one or more Color sub-TLVs (Section 3.4.2) and/or the 1275 Protocol Type sub-TLV (Section 3.4.1), the choice of tunnel may be 1276 influenced by these sub-TLVs. 1278 The reachability to the address of the egress endpoint of the tunnel 1279 may change over time, directly impacting the feasibility of the 1280 tunnel. A tunnel that is not feasible at some moment, may become 1281 feasible at a later time when its egress endpoint address is 1282 reachable. The router may start using the newly feasible tunnel 1283 instead of an existing one. How this decision is made is outside the 1284 scope of this document. 1286 Once it is determined to send a packet through the tunnel specified 1287 in a particular Tunnel TLV of a particular Tunnel Encapsulation 1288 attribute, then the tunnel's egress endpoint address is the IP 1289 address contained in the sub-TLV. If the Tunnel TLV contains a 1290 Tunnel Egress Endpoint sub-TLV whose value field is all zeroes, then 1291 the tunnel's egress endpoint is the address of the Next Hop of the 1292 BGP Update containing the Tunnel Encapsulation attribute. The 1293 address of the tunnel egress endpoint generally appears in a 1294 "destination address" field of the encapsulation. 1296 The full set of procedures for sending a packet through a particular 1297 Tunnel Type to a particular tunnel egress endpoint depends upon the 1298 tunnel type, and is outside the scope of this document. Note that 1299 some tunnel types may require the execution of an explicit tunnel 1300 setup protocol before they can be used for carrying data. Other 1301 tunnel types may not require any tunnel setup protocol. 1303 Sending a packet through a tunnel always requires that the packet be 1304 encapsulated, with an encapsulation header that is appropriate for 1305 the Tunnel Type. The contents of the tunnel encapsulation header may 1306 be influenced by the Encapsulation sub-TLV. If there is no 1307 Encapsulation sub-TLV present, the router transmitting the packet 1308 through the tunnel must have a priori knowledge (e.g., by 1309 provisioning) of how to fill in the various fields in the 1310 encapsulation header. 1312 A Tunnel Encapsulation attribute may contain several TLVs that all 1313 specify the same Tunnel Type. Each TLV should be considered as 1314 specifying a different tunnel. Two tunnels of the same type may have 1315 different Tunnel Egress Endpoint sub-TLVs, different Encapsulation 1316 sub-TLVs, etc. Choosing between two such tunnels is a matter of 1317 local policy. 1319 Once router R has decided to send packet P through a particular 1320 tunnel, it encapsulates packet P appropriately and then forwards it 1321 according to the route that leads to the tunnel's egress endpoint. 1322 This route may itself be a BGP route with a Tunnel Encapsulation 1323 attribute. If so, the encapsulated packet is treated as the payload 1324 and is encapsulated according to the Tunnel Encapsulation attribute 1325 of that route. That is, tunnels may be "stacked". 1327 Notwithstanding anything said in this document, a BGP speaker MAY 1328 have local policy that influences the choice of tunnel, and the way 1329 the encapsulation is formed. A BGP speaker MAY also have a local 1330 policy that tells it to ignore the Tunnel Encapsulation attribute 1331 entirely or in part. Of course, interoperability issues must be 1332 considered when such policies are put into place. 1334 See also Section 13, which provides further specification regarding 1335 validation and exception cases. 1337 7. Routing Considerations 1339 7.1. Impact on the BGP Decision Process 1341 The presence of the Tunnel Encapsulation attribute affects the BGP 1342 best route selection algorithm. If a route includes the Tunnel 1343 Encapsulation attribute, and if that attribute includes no tunnel 1344 which is feasible, then that route MUST NOT be considered resolvable 1345 for the purposes of Route Resolvability Condition [RFC4271] 1346 Section 9.1.2.1. 1348 7.2. Looping, Mutual Recursion, Etc. 1350 Consider a packet destined for address X. Suppose a BGP UPDATE for 1351 address prefix X carries a Tunnel Encapsulation attribute that 1352 specifies a tunnel egress endpoint of Y, and suppose that a BGP 1353 UPDATE for address prefix Y carries a Tunnel Encapsulation attribute 1354 that specifies a tunnel egress endpoint of X. It is easy to see that 1355 this can have no good outcome. [RFC4271] describes an analogous case 1356 as mutually recursive routes. 1358 This could happen as a result of misconfiguration, either accidental 1359 or intentional. It could also happen if the Tunnel Encapsulation 1360 attribute were altered by a malicious agent. Implementations should 1361 be aware that such an attack will result in unresolvable BGP routes 1362 due to the mutually recursive relationship. This document does not 1363 specify a maximum number of recursions; that is an implementation- 1364 specific matter. 1366 Improper setting (or malicious altering) of the Tunnel Encapsulation 1367 attribute could also cause data packets to loop. Suppose a BGP 1368 UPDATE for address prefix X carries a Tunnel Encapsulation attribute 1369 that specifies a tunnel egress endpoint of Y. Suppose router R 1370 receives and processes the advertisement. When router R receives a 1371 packet destined for X, it will apply the encapsulation and send the 1372 encapsulated packet to Y. Y will decapsulate the packet and forward 1373 it further. If Y is further away from X than is router R, it is 1374 possible that the path from Y to X will traverse R. This would cause 1375 a long-lasting routing loop. The control plane itself cannot detect 1376 this situation, though a TTL field in the payload packets would 1377 prevent any given packet from looping infinitely. 1379 During the deployment of techniques as described in this document, 1380 operators are encouraged to avoid mutually recursive route and/or 1381 tunnel dependencies. There is greater potential for such scenarios 1382 to arise when the tunnel egress endpoint for a given prefix differs 1383 from the address of the next hop for that prefix. 1385 8. Recursive Next Hop Resolution 1387 Suppose that: 1389 o a given packet P must be forwarded by router R1; 1391 o the path along which P is to be forwarded is determined by BGP 1392 UPDATE U1; 1394 o UPDATE U1 does not have a Tunnel Encapsulation attribute; 1396 o the address of the next hop of UPDATE U1 is router R2; 1398 o the best route to router R2 is a BGP route that was advertised in 1399 UPDATE U2; 1401 o UPDATE U2 has a Tunnel Encapsulation attribute. 1403 Then packet P MUST be sent through one of the tunnels identified in 1404 the Tunnel Encapsulation attribute of UPDATE U2. See Section 6 for 1405 further details. 1407 However, suppose that one of the TLVs in U2's Tunnel Encapsulation 1408 attribute contains the Color Sub-TLV. In that case, packet P MUST 1409 NOT be sent through the tunnel contained in that TLV, unless U1 is 1410 carrying the Color Extended Community that is identified in U2's 1411 Color Sub-TLV. 1413 The procedures in this section presuppose that U1's address of the 1414 next hop resolves to a BGP route, and that U2's next hop resolves 1415 (perhaps after further recursion) to a non-BGP route. 1417 9. Use of Virtual Network Identifiers and Embedded Labels when Imposing 1418 a Tunnel Encapsulation 1420 If the TLV specifying a tunnel contains an MPLS Label Stack sub-TLV, 1421 then when sending a packet through that tunnel, the procedures of 1422 Section 3.6 are applied before the procedures of this section. 1424 If the TLV specifying a tunnel contains a Prefix-SID sub-TLV, the 1425 procedures of Section 3.7 are applied before the procedures of this 1426 section. If the TLV also contains an MPLS Label Stack sub-TLV, the 1427 procedures of Section 3.6 are applied before the procedures of 1428 Section 3.7. 1430 9.1. Tunnel Types without a Virtual Network Identifier Field 1432 If a Tunnel Encapsulation attribute is attached to an UPDATE of a 1433 labeled address family, there will be one or more labels specified in 1434 the UPDATE's NLRI. When a packet is sent through a tunnel specified 1435 in one of the attribute's TLVs, and that tunnel type does not contain 1436 a virtual network identifier field, the label or labels from the NLRI 1437 are pushed on the packet's label stack. The resulting MPLS packet is 1438 then further encapsulated, as specified by the TLV. 1440 9.2. Tunnel Types with a Virtual Network Identifier Field 1442 Three of the tunnel types that can be specified in a Tunnel 1443 Encapsulation TLV have virtual network identifier fields in their 1444 encapsulation headers. In the VXLAN encapsulation, this field is 1445 called the VNI (Virtual Network Identifier) field; in the NVGRE 1446 encapsulation, this field is called the VSID (Virtual Subnet 1447 Identifier) field. 1449 When one of these tunnel encapsulations is imposed on a packet, the 1450 setting of the virtual network identifier field in the encapsulation 1451 header depends upon the contents of the Encapsulation sub-TLV (if one 1452 is present). When the Tunnel Encapsulation attribute is being 1453 carried in a BGP UPDATE of a labeled address family, the setting of 1454 the virtual network identifier field also depends upon the contents 1455 of the Embedded Label Handling sub-TLV (if present). 1457 This section specifies the procedures for choosing the value to set 1458 in the virtual network identifier field of the encapsulation header. 1459 These procedures apply only when the Tunnel Type is VXLAN or NVGRE. 1461 9.2.1. Unlabeled Address Families 1463 This sub-section applies when: 1465 o the Tunnel Encapsulation attribute is carried in a BGP UPDATE of 1466 an unlabeled address family, and 1468 o at least one of the attribute's TLVs identifies a Tunnel Type that 1469 uses a virtual network identifier, and 1471 o it has been determined to send a packet through one of those 1472 tunnels. 1474 If the TLV identifying the tunnel contains an Encapsulation sub-TLV 1475 whose V bit is set, the virtual network identifier field of the 1476 encapsulation header is set to the value of the virtual network 1477 identifier field of the Encapsulation sub-TLV. 1479 Otherwise, the virtual network identifier field of the encapsulation 1480 header is set to a configured value; if there is no configured value, 1481 the tunnel cannot be used. 1483 9.2.2. Labeled Address Families 1485 This sub-section applies when: 1487 o the Tunnel Encapsulation attribute is carried in a BGP UPDATE of a 1488 labeled address family, and 1490 o at least one of the attribute's TLVs identifies a Tunnel Type that 1491 uses a virtual network identifier, and 1493 o it has been determined to send a packet through one of those 1494 tunnels. 1496 9.2.2.1. When a Valid VNI has been Signaled 1498 If the TLV identifying the tunnel contains an Encapsulation sub-TLV 1499 whose V bit is set, the virtual network identifier field of the 1500 encapsulation header is set to the value of the virtual network 1501 identifier field of the Encapsulation sub-TLV. However, the Embedded 1502 Label Handling sub-TLV will determine label processing as described 1503 below. 1505 o If the TLV contains an Embedded Label Handling sub-TLV whose value 1506 is 1, the embedded label (from the NLRI of the route that is 1507 carrying the Tunnel Encapsulation attribute) appears at the top of 1508 the MPLS label stack in the encapsulation payload. 1510 o If the TLV does not contain an Embedded Label Handling sub-TLV, or 1511 it contains an Embedded Label Handling sub-TLV whose value is 2, 1512 the embedded label is ignored entirely. 1514 9.2.2.2. When a Valid VNI has not been Signaled 1516 If the TLV identifying the tunnel does not contain an Encapsulation 1517 sub-TLV whose V bit is set, the virtual network identifier field of 1518 the encapsulation header is set as follows: 1520 o If the TLV contains an Embedded Label Handling sub-TLV whose value 1521 is 1, then the virtual network identifier field of the 1522 encapsulation header is set to a configured value. 1524 If there is no configured value, the tunnel cannot be used. 1526 The embedded label (from the NLRI of the route that is carrying 1527 the Tunnel Encapsulation attribute) appears at the top of the MPLS 1528 label stack in the encapsulation payload. 1530 o If the TLV does not contain an Embedded Label Handling sub-TLV, or 1531 if it contains an Embedded Label Handling sub-TLV whose value is 1532 2, the embedded label is copied into the lower 3 octets of the 1533 virtual network identifier field of the encapsulation header. 1535 In this case, the payload may or may not contain an MPLS label 1536 stack, depending upon other factors. If the payload does contain 1537 an MPLS label stack, the embedded label does not appear in that 1538 stack. 1540 10. Applicability Restrictions 1542 In a given UPDATE of a labeled address family, the label embedded in 1543 the NLRI is generally a label that is meaningful only to the router 1544 represented by the address of the next hop. Certain of the 1545 procedures of Section 9.2.2.1 or Section 9.2.2.2 cause the embedded 1546 label to be carried by a data packet to the router whose address 1547 appears in the Tunnel Egress Endpoint sub-TLV. If the Tunnel Egress 1548 Endpoint sub-TLV does not identify the same router represented by the 1549 address of the next hop, sending the packet through the tunnel may 1550 cause the label to be misinterpreted at the tunnel's egress endpoint. 1551 This may cause misdelivery of the packet. Avoidance of this 1552 unfortunate outcome is a matter of network planning and design, and 1553 is outside the scope of this document. 1555 Note that if the Tunnel Encapsulation attribute is attached to a VPN- 1556 IP route [RFC4364], and if Inter-AS "option b" (see section 10 of 1557 [RFC4364]) is being used, and if the Tunnel Egress Endpoint sub-TLV 1558 contains an IP address that is not in same AS as the router receiving 1559 the route, it is very likely that the embedded label has been 1560 changed. Therefore use of the Tunnel Encapsulation attribute in an 1561 "Inter-AS option b" scenario is not recommended. 1563 Other documents may define other ways to signal tunnel information in 1564 BGP. For example, [RFC6514] defines the "P-Multicast Service 1565 Interface Tunnel" (PMSI Tunnel) attribute. In this specification, we 1566 do not consider the effects of advertising the Tunnel Encapsulation 1567 Attribute in conjunction with other forms of signaling tunnels. Any 1568 document specifying such joint use should provide details as to how 1569 interactions should be handled. 1571 11. Scoping 1573 The Tunnel Encapsulation attribute is defined as a transitive 1574 attribute, so that it may be passed along by BGP speakers that do not 1575 recognize it. However, it is intended that the Tunnel Encapsulation 1576 attribute be used only within a well-defined scope, e.g., within a 1577 set of Autonomous Systems that belong to a single administrative 1578 entity. If the attribute is distributed beyond its intended scope, 1579 packets may be sent through tunnels in a manner that is not intended. 1581 To prevent the Tunnel Encapsulation attribute from being distributed 1582 beyond its intended scope, any BGP speaker that understands the 1583 attribute MUST be able to filter the attribute from incoming BGP 1584 UPDATE messages. When the attribute is filtered from an incoming 1585 UPDATE, the attribute is neither processed nor distributed. This 1586 filtering SHOULD be possible on a per-BGP-session basis; finer 1587 granularities (for example, per route and/or per attribute TLV) MAY 1588 be supported. For each external BGP (EBGP) session, filtering of the 1589 attribute on incoming UPDATEs MUST be enabled by default. 1591 In addition, any BGP speaker that understands the attribute MUST be 1592 able to filter the attribute from outgoing BGP UPDATE messages. This 1593 filtering SHOULD be possible on a per-BGP-session basis. For each 1594 EBGP session, filtering of the attribute on outgoing UPDATEs MUST be 1595 enabled by default. 1597 Since the Tunnel Encapsulation Extended Community provides a subset 1598 of the functionality of the Tunnel Encapsulation attribute, these 1599 considerations apply equally in its case: any BGP speaker that 1600 understands it MUST be able to filter it from incoming BGP UPDATE 1601 messages, it MUST be possible to filter the Tunnel Encapsulation 1602 Extended Community from outgoing messages, and in both cases this 1603 filtering MUST be enabled by default for EBGP sessions. 1605 12. Operational Considerations 1607 A potential operational difficulty arises when tunnels are used, if 1608 the size of packets entering the tunnel exceeds the maximum 1609 transmission unit (MTU) the tunnel is capable of supporting. This 1610 difficulty can be exacerbated by stacking multiple tunnels, since 1611 each stacked tunnel header further reduces the supportable MTU. This 1612 issue is long-standing and well-known. The tunnel signaling provided 1613 in this specification does nothing to address this issue, nor to 1614 aggravate it (except insofar as it may further increase the 1615 popularity of tunnelling). 1617 13. Validation and Error Handling 1619 The Tunnel Encapsulation attribute is a sequence of TLVs, each of 1620 which is a sequence of sub-TLVs. The final octet of a TLV is 1621 determined by its length field. Similarly, the final octet of a sub- 1622 TLV is determined by its length field. The final octet of a TLV MUST 1623 also be the final octet of its final sub-TLV. If this is not the 1624 case, the TLV MUST be considered to be malformed, and the "Treat-as- 1625 withdraw" procedure of [RFC7606] is applied. 1627 If a Tunnel Encapsulation attribute does not have any valid TLVs, or 1628 it does not have the transitive bit set, the "Treat-as-withdraw" 1629 procedure of [RFC7606] is applied. 1631 If a Tunnel Encapsulation attribute can be parsed correctly, but 1632 contains a TLV whose Tunnel Type is not recognized by a particular 1633 BGP speaker, that BGP speaker MUST NOT consider the attribute to be 1634 malformed. Rather, it MUST interpret the attribute as if that TLV 1635 had not been present. If the route carrying the Tunnel Encapsulation 1636 attribute is propagated with the attribute, the unrecognized TLV MUST 1637 remain in the attribute. 1639 The following sub-TLVs defined in this document MUST NOT occur more 1640 than once in a given Tunnel TLV: Tunnel Egress Endpoint (discussed 1641 below), Encapsulation, DS, UDP Destination Port, Embedded Label 1642 Handling, MPLS Label Stack, Prefix-SID. If a Tunnel TLV has more 1643 than one of any of these sub-TLVs, all but the first occurrence of 1644 each such sub-TLV type MUST be disregarded. However, the Tunnel TLV 1645 containing them MUST NOT be considered to be malformed, and all the 1646 sub-TLVs MUST be propagated if the route carrying the Tunnel 1647 Encapsulation attribute is propagated. 1649 The following sub-TLVs defined in this document may appear zero or 1650 more times in a given Tunnel TLV: Protocol Type, Color. Each 1651 occurrence of such sub-TLVs is meaningful. For example, the Color 1652 sub-TLV may appear multiple times to assign multiple colors to a 1653 tunnel. 1655 If a TLV of a Tunnel Encapsulation attribute contains a sub-TLV that 1656 is not recognized by a particular BGP speaker, the BGP speaker MUST 1657 process that TLV as if the unrecognized sub-TLV had not been present. 1658 If the route carrying the Tunnel Encapsulation attribute is 1659 propagated with the attribute, the unrecognized sub-TLV MUST remain 1660 in the attribute. 1662 In general, if a TLV contains a sub-TLV that is malformed, the sub- 1663 TLV MUST be treated as if it were an unrecognized sub-TLV. This 1664 document specifies one exception to this rule -- if a TLV contains a 1665 malformed Tunnel Egress Endpoint sub-TLV (as defined in Section 3.1), 1666 the entire TLV MUST be ignored, and MUST be removed from the Tunnel 1667 Encapsulation attribute before the route carrying that attribute is 1668 distributed. 1670 Within a Tunnel Encapsulation attribute that is carried by a BGP 1671 UPDATE whose AFI/SAFI is one of those explicitly listed in the second 1672 paragraph of Section 6, a TLV that does not contain exactly one 1673 Tunnel Egress Endpoint sub-TLV MUST be treated as if it contained a 1674 malformed Tunnel Egress Endpoint sub-TLV. 1676 A TLV identifying a particular Tunnel Type may contain a sub-TLV that 1677 is meaningless for that Tunnel Type. For example, perhaps the TLV 1678 contains a UDP Destination Port sub-TLV, but the identified tunnel 1679 type does not use UDP encapsulation at all, or a tunnel of the form 1680 "X-in-Y" contains a Protocol Type sub-TLV that specifies something 1681 other than "X". Sub-TLVs of this sort MUST be disregarded. That is, 1682 they MUST NOT affect the creation of the encapsulation header. 1683 However, the sub-TLV MUST NOT be considered to be malformed, and MUST 1684 NOT be removed from the TLV before the route carrying the Tunnel 1685 Encapsulation attribute is distributed. An implementation MAY log a 1686 message when it encounters such a sub-TLV. 1688 14. IANA Considerations 1690 This document makes the following requests of IANA. (All 1691 registration procedures listed below are per their definitions in 1692 [RFC8126].) 1694 14.1. Obsoleting RFC 5512 1696 Because this document obsoletes RFC 5512, change all registration 1697 information that references [RFC5512] to instead reference this 1698 document. 1700 14.2. Obsoleting Code Points Assigned by RFCs 5566 and 5640 1702 Since this document obsoletes RFCs 5566 and 5640, the code points 1703 assigned by those RFCs are similarly obsoleted. Specifically, the 1704 following code points should be marked as deprecated. 1706 In the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry: 1708 +-------+---------------------------------------------+ 1709 | Value | Name | 1710 +-------+---------------------------------------------+ 1711 | 3 | Transmit tunnel endpoint | 1712 | 4 | IPsec in Tunnel-mode | 1713 | 5 | IP in IP tunnel with IPsec Transport Mode | 1714 | 6 | MPLS-in-IP tunnel with IPsec Transport Mode | 1715 +-------+---------------------------------------------+ 1717 And in the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry: 1719 +-------+----------------------------+ 1720 | Value | Name | 1721 +-------+----------------------------+ 1722 | 3 | IPsec Tunnel Authenticator | 1723 | 5 | Load-Balancing Block | 1724 +-------+----------------------------+ 1726 14.3. BGP Tunnel Encapsulation Parameters Grouping 1728 Create a new registry grouping, to be named "BGP Tunnel Encapsulation 1729 Parameters". 1731 14.4. Subsequent Address Family Identifiers 1733 Modify the "Subsequent Address Family Identifiers" registry to 1734 indicate that the Encapsulation SAFI (value 7) is obsoleted. This 1735 document should be the reference. 1737 14.5. BGP Tunnel Encapsulation Attribute Sub-TLVs 1739 Relocate the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry 1740 to be under the "BGP Tunnel Encapsulation Parameters" grouping. 1742 Add the following note to the registry: 1744 If the Sub-TLV Type is in the range from 0 to 127 inclusive, the 1745 Sub-TLV Length field contains one octet. If the Sub-TLV Type is 1746 in the range from 128-255 inclusive, the Sub-TLV Length field 1747 contains two octets. 1749 Change the registration policy of the registry to the following: 1751 +----------+-------------------------+ 1752 | Value(s) | Registration Procedure | 1753 +----------+-------------------------+ 1754 | 0 | Reserved | 1755 | 1-63 | Standards Action | 1756 | 64-125 | First Come First Served | 1757 | 126-127 | Experimental Use | 1758 | 128-191 | Standards Action | 1759 | 192-252 | First Come First Served | 1760 | 253-254 | Experimental Use | 1761 | 255 | Reserved | 1762 +----------+-------------------------+ 1764 Rename the following entries within the registry: 1766 +-------+-----------------+------------------------+ 1767 | Value | Old Name | New Name | 1768 +-------+-----------------+------------------------+ 1769 | 6 | Remote Endpoint | Tunnel Egress Endpoint | 1770 | 7 | IPv4 DS Field | DS Field | 1771 +-------+-----------------+------------------------+ 1773 14.6. Flags Field of VXLAN Encapsulation sub-TLV 1775 Create a registry named "Flags Field of VXLAN Encapsulation sub-TLV" 1776 under the "BGP Tunnel Encapsulation Parameters" grouping. The 1777 registration policy for this registry is "Standards Action". 1779 The initial values for this new registry are indicated below. 1781 +--------------+--------------------------------+-----------------+ 1782 | Bit Position | Description | Reference | 1783 +--------------+--------------------------------+-----------------+ 1784 | 0 | V (Virtual Network Identifier) | (this document) | 1785 | 1 | M (MAC Address) | (this document) | 1786 +--------------+--------------------------------+-----------------+ 1788 14.7. Flags Field of NVGRE Encapsulation sub-TLV 1790 Create a registry named "Flags Field of NVGRE Encapsulation sub-TLV" 1791 under the "BGP Tunnel Encapsulation Parameters" grouping. The 1792 registration policy for this registry is "Standards Action". 1794 The initial values for this new registry are indicated below. 1796 +--------------+-----------------+-----------------+ 1797 | Bit Position | Description | Reference | 1798 +--------------+-----------------+-----------------+ 1799 | 0 | V (VN-ID) | (this document) | 1800 | 1 | M (MAC Address) | (this document) | 1801 +--------------+-----------------+-----------------+ 1803 14.8. Embedded Label Handling sub-TLV 1805 Create a registry named "Embedded Label Handling sub-TLV" under the 1806 "BGP Tunnel Encapsulation Parameters" grouping. The registration 1807 policy for this registry is "Standards Action". 1809 The initial values for this new registry are indicated below. 1811 +-------+-------------------------------------+-----------------+ 1812 | Value | Description | Reference | 1813 +-------+-------------------------------------+-----------------+ 1814 | 1 | Payload of MPLS with embedded label | (this document) | 1815 | 2 | no embedded label in payload | (this document) | 1816 +-------+-------------------------------------+-----------------+ 1818 14.9. Color Extended Community Flags 1820 Create a registry named "Color Extended Community Flags" under the 1821 "BGP Tunnel Encapsulation Parameters" grouping. The registration 1822 policy for this registry is "Standards Action". 1824 No initial values are to be registered. The format of the registry 1825 is shown below. 1827 +--------------+-------------+-----------+ 1828 | Bit Position | Description | Reference | 1829 +--------------+-------------+-----------+ 1830 +--------------+-------------+-----------+ 1832 15. Security Considerations 1834 As Section 11 discusses, it is intended that the Tunnel Encapsulation 1835 attribute be used only within a well-defined scope, e.g., within a 1836 set of Autonomous Systems that belong to a single administrative 1837 entity. As long as the filtering mechanisms discussed in that 1838 section are applied diligently, an attacker outside the scope would 1839 not be able to use the Tunnel Encapsulation attribute in an attack. 1840 This leaves open the questions of attackers within the scope (for 1841 example, a compromised router) and failures in filtering that allow 1842 an external attack to succeed. 1844 As [RFC4272] discusses, BGP is vulnerable to traffic diversion 1845 attacks. The Tunnel Encapsulation attribute adds a new means by 1846 which an attacker could cause traffic to be diverted from its normal 1847 path, especially when the Tunnel Egress Endpoint sub-TLV is used. 1848 Such an attack would differ from pre-existing vulnerabilities in that 1849 traffic could be tunneled to a distant target across intervening 1850 network infrastructure, allowing an attack to potentially succeed 1851 more easily, since less infrastructure would have to be subverted. 1852 Potential consequences include "hijacking" of traffic (insertion of 1853 an undesired node in the path) or denial of service (directing 1854 traffic to a node that doesn't desire to receive it). 1856 In order to further mitigate the risk of diversion of traffic from 1857 its intended destination, Section 3.1.1 provides an optional 1858 procedure to check that the destination given in a Tunnel Egress 1859 Endpoint sub-TLV is within the AS that was the source of the route. 1860 One then has some level of assurance that the tunneled traffic is 1861 going to the same destination AS that it would have gone to had the 1862 Tunnel Encapsulation attribute not been present. As RFC 4272 1863 discusses, it's possible for an attacker to announce an inaccurate 1864 AS_PATH, therefore an attacker with the ability to inject a Tunnel 1865 Egress Endpoint sub-TLV could equally craft an AS_PATH that would 1866 pass the validation procedures of Section 3.1.1. BGP Origin 1867 Validation [RFC6811] and BGPsec [RFC8205] provide means to increase 1868 assurance that the origins being validated have not been falsified. 1870 16. Acknowledgments 1872 This document contains text from RFC 5512, authored by Pradosh 1873 Mohapatra and Eric Rosen. The authors of the current document wish 1874 to thank them for their contribution. RFC 5512 itself built upon 1875 prior work by Gargi Nalawade, Ruchi Kapoor, Dan Tappan, David Ward, 1876 Scott Wainner, Simon Barber, Lili Wang, and Chris Metz, whom the 1877 authors also thank for their contributions. Eric Rosen was the 1878 principal author of earlier versions of this document. 1880 The authors wish to thank Lou Berger, Ron Bonica, Martin Djernaes, 1881 John Drake, Susan Hares, Satoru Matsushima, Thomas Morin, Dhananjaya 1882 Rao, Ravi Singh, Harish Sitaraman, Brian Trammell, Xiaohu Xu, and 1883 Zhaohui Zhang for their review, comments, and/or helpful discussions. 1884 Alvaro Retana provided an especially comprehensive review. 1886 17. Contributor Addresses 1888 Below is a list of other contributing authors in alphabetical order: 1890 Randy Bush 1891 Internet Initiative Japan 1892 5147 Crystal Springs 1893 Bainbridge Island, Washington 98110 1894 United States 1896 Email: randy@psg.com 1898 Robert Raszuk 1899 Bloomberg LP 1900 731 Lexington Ave 1901 New York City, NY 10022 1902 United States 1904 Email: robert@raszuk.net 1906 Eric C. Rosen 1908 18. References 1910 18.1. Normative References 1912 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1913 Requirement Levels", BCP 14, RFC 2119, 1914 DOI 10.17487/RFC2119, March 1997, 1915 . 1917 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1918 "Definition of the Differentiated Services Field (DS 1919 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1920 DOI 10.17487/RFC2474, December 1998, 1921 . 1923 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1924 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1925 DOI 10.17487/RFC2784, March 2000, 1926 . 1928 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 1929 RFC 2890, DOI 10.17487/RFC2890, September 2000, 1930 . 1932 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1933 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1934 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1935 . 1937 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 1938 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 1939 Protocol Label Switching (MPLS) Support of Differentiated 1940 Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, 1941 . 1943 [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., 1944 "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", 1945 RFC 3931, DOI 10.17487/RFC3931, March 2005, 1946 . 1948 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 1949 "Encapsulating MPLS in IP or Generic Routing Encapsulation 1950 (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, 1951 . 1953 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1954 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1955 DOI 10.17487/RFC4271, January 2006, 1956 . 1958 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1959 "Multiprotocol Extensions for BGP-4", RFC 4760, 1960 DOI 10.17487/RFC4760, January 2007, 1961 . 1963 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 1964 Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 1965 2008, . 1967 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 1968 "Special-Purpose IP Address Registries", BCP 153, 1969 RFC 6890, DOI 10.17487/RFC6890, April 2013, 1970 . 1972 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1973 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1974 eXtensible Local Area Network (VXLAN): A Framework for 1975 Overlaying Virtualized Layer 2 Networks over Layer 3 1976 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 1977 . 1979 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1980 Patel, "Revised Error Handling for BGP UPDATE Messages", 1981 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1982 . 1984 [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network 1985 Virtualization Using Generic Routing Encapsulation", 1986 RFC 7637, DOI 10.17487/RFC7637, September 2015, 1987 . 1989 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1990 Writing an IANA Considerations Section in RFCs", BCP 26, 1991 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1992 . 1994 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1995 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1996 May 2017, . 1998 [RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, 1999 A., and H. Gredler, "Segment Routing Prefix Segment 2000 Identifier Extensions for BGP", RFC 8669, 2001 DOI 10.17487/RFC8669, December 2019, 2002 . 2004 18.2. Informative References 2006 [Ethertypes] 2007 "IANA Ethertype Registry", 2008 . 2011 [I-D.ietf-bess-evpn-inter-subnet-forwarding] 2012 Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. 2013 Rabadan, "Integrated Routing and Bridging in EVPN", draft- 2014 ietf-bess-evpn-inter-subnet-forwarding-11 (work in 2015 progress), October 2020. 2017 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 2018 RFC 4272, DOI 10.17487/RFC4272, January 2006, 2019 . 2021 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 2022 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2023 2006, . 2025 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 2026 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 2027 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2028 2009, . 2030 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 2031 Subsequent Address Family Identifier (SAFI) and the BGP 2032 Tunnel Encapsulation Attribute", RFC 5512, 2033 DOI 10.17487/RFC5512, April 2009, 2034 . 2036 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 2037 Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, 2038 . 2040 [RFC5566] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel 2041 Encapsulation Attribute", RFC 5566, DOI 10.17487/RFC5566, 2042 June 2009, . 2044 [RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load- 2045 Balancing for Mesh Softwires", RFC 5640, 2046 DOI 10.17487/RFC5640, August 2009, 2047 . 2049 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 2050 Encodings and Procedures for Multicast in MPLS/BGP IP 2051 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 2052 . 2054 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 2055 Austein, "BGP Prefix Origin Validation", RFC 6811, 2056 DOI 10.17487/RFC6811, January 2013, 2057 . 2059 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 2060 "Encapsulating MPLS in UDP", RFC 7510, 2061 DOI 10.17487/RFC7510, April 2015, 2062 . 2064 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 2065 Specification", RFC 8205, DOI 10.17487/RFC8205, September 2066 2017, . 2068 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 2069 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 2070 . 2072 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 2073 Uttaro, J., and W. Henderickx, "A Network Virtualization 2074 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 2075 DOI 10.17487/RFC8365, March 2018, 2076 . 2078 Appendix A. Impact on RFC 8365 2080 [RFC8365] references RFC 5512 for its definition of the BGP 2081 Encapsulation Extended Community. That extended community is now 2082 defined in this document, in a way consistent with its previous 2083 definition. 2085 RFC 8365 talks in Section 6 about the use of the Encapsulation 2086 Extended Community to allow Network Virtualization Edge devices 2087 (NVEs) to signal their supported encapsulations. We note that with 2088 the introduction of this specification, the Tunnel Encapsulation 2089 Attribute can also be used for this purpose. For purposes where RFC 2090 8365 talks about "advertising supported encapsulations" (for example, 2091 in the second paragraph of Section 6), encapsulations advertised 2092 using the Tunnel Encapsulation Attribute should be considered equally 2093 with those advertised using the Encapsulation Extended Community. 2095 In particular, a review of Section 8.3.1 of RFC 8365 is called for, 2096 to consider whether the introduction of the Tunnel Encapsulation 2097 Attribute creates a need for any revisions to the split horizon 2098 procedures. 2100 RFC 8365 also refers to a draft version of this specification in the 2101 final paragraph of section 5.1.3. That paragraph references 2102 Section 8.2.2.2 of the draft. In this version of the document the 2103 correct reference would be Section 9.2.2.2. There are no substantive 2104 differences between the section in the referenced draft, and that in 2105 this document. 2107 Authors' Addresses 2109 Keyur Patel 2110 Arrcus, Inc 2111 2077 Gateway Pl 2112 San Jose, CA 95110 2113 United States 2115 Email: keyur@arrcus.com 2117 Gunter Van de Velde 2118 Nokia 2119 Copernicuslaan 50 2120 Antwerpen 2018 2121 Belgium 2123 Email: gunter.van_de_velde@nokia.com 2124 Srihari R. Sangli 2125 Juniper Networks 2127 Email: ssangli@juniper.net 2129 John Scudder 2130 Juniper Networks 2132 Email: jgs@juniper.net