idnits 2.17.1 draft-ietf-idr-tunnel-encaps-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (December 21, 2015) is 3042 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) ** Obsolete normative reference: RFC 5512 (Obsoleted by RFC 9012) == Outdated reference: A later version (-27) exists of draft-ietf-idr-bgp-prefix-sid-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group E. Rosen, Ed. 3 Internet-Draft Juniper Networks, Inc. 4 Obsoletes: 5512 (if approved) K. Patel 5 Intended status: Standards Track Cisco Systems 6 Expires: June 23, 2016 G. Van de Velde 7 Alcatel-Lucent 8 December 21, 2015 10 The BGP Tunnel Encapsulation Attribute 11 draft-ietf-idr-tunnel-encaps-01 13 Abstract 15 RFC 5512 defines a BGP Path Attribute known as the "Tunnel 16 Encapsulation Attribute". This attribute allows one to specify a set 17 of tunnels. For each such tunnel, the attribute can provide the 18 information needed to create the tunnel and the corresponding 19 encapsulation header. The attribute can also provide information 20 that aids in choosing whether a particular packet is to be sent 21 through a particular tunnel. RFC 5512 states that the attribute is 22 only carried in BGP UPDATEs that have the "Encapsulation Subsequent 23 Address Family (Encapsulation SAFI)". This document deprecates the 24 Encapsulation SAFI (which has never been used), and specifies 25 semantics for the attribute when it is carried in UPDATEs of certain 26 other SAFIs. This document adds support for additional tunnel types, 27 and allows a remote tunnel endpoint address to be specified for each 28 tunnel. This document also provides support for specifying fields of 29 any inner or outer encapsulations that may be used by a particular 30 tunnel. 32 This document obsoletes RFC 5512. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on June 23, 2016. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Brief Summary of RFC 5512 . . . . . . . . . . . . . . . . 4 69 1.2. Deficiencies in RFC 5512 . . . . . . . . . . . . . . . . 4 70 1.3. Brief Summary of Changes from RFC 5512 . . . . . . . . . 5 71 2. The Tunnel Encapsulation Attribute . . . . . . . . . . . . . 6 72 3. Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . . . . . 7 73 3.1. The Remote Endpoint Sub-TLV . . . . . . . . . . . . . . . 7 74 3.2. Encapsulation Sub-TLVs for Particular Tunnel Types . . . 10 75 3.2.1. VXLAN . . . . . . . . . . . . . . . . . . . . . . . . 10 76 3.2.2. VXLAN-GPE . . . . . . . . . . . . . . . . . . . . . . 11 77 3.2.3. NVGRE . . . . . . . . . . . . . . . . . . . . . . . . 12 78 3.2.4. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . 13 79 3.2.5. GTP . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 3.2.6. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 3.2.7. MPLS-in-GRE . . . . . . . . . . . . . . . . . . . . . 15 82 3.3. Outer Encapsulation Sub-TLVs . . . . . . . . . . . . . . 16 83 3.3.1. IPv4 DS Field . . . . . . . . . . . . . . . . . . . . 17 84 3.3.2. UDP Destination Port . . . . . . . . . . . . . . . . 17 85 3.4. Sub-TLVs for Aiding Tunnel Selection . . . . . . . . . . 17 86 3.4.1. Protocol Type Sub-TLV . . . . . . . . . . . . . . . . 17 87 3.4.2. Color Sub-TLV . . . . . . . . . . . . . . . . . . . . 18 88 3.5. Embedded Label Handling Sub-TLV . . . . . . . . . . . . . 18 89 3.6. MPLS Label Stack Sub-TLV . . . . . . . . . . . . . . . . 19 90 3.7. Prefix-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 20 91 4. Extended Communities Related to the Tunnel Encapsulation 92 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 21 93 4.1. Encapsulation Extended Community . . . . . . . . . . . . 21 94 4.2. Router's MAC Extended Community . . . . . . . . . . . . . 22 95 4.3. Color Extended Community . . . . . . . . . . . . . . . . 22 97 5. Semantics and Usage of the Tunnel Encapsulation 98 attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 22 99 6. Routing Considerations . . . . . . . . . . . . . . . . . . . 26 100 6.1. No Impact on BGP Decision Process . . . . . . . . . . . . 26 101 6.2. Looping, Infinite Stacking, Etc. . . . . . . . . . . . . 26 102 7. Recursive Next Hop Resolution . . . . . . . . . . . . . . . . 27 103 8. Use of Virtual Network Identifiers and Embedded Labels 104 when Imposing a Tunnel Encapsulation . . . . . . . . . . . . 28 105 8.1. Tunnel Types without a Virtual Network Identifier 106 Field . . . . . . . . . . . . . . . . . . . . . . . . . . 28 107 8.2. Tunnel Types with a Virtual Network Identifier Field . . 28 108 8.2.1. Unlabeled Address Families . . . . . . . . . . . . . 29 109 8.2.2. Labeled Address Families . . . . . . . . . . . . . . 29 110 8.2.2.1. When a Valid VNI has been Signaled . . . . . . . 29 111 8.2.2.2. When a Valid VNI has not been Signaled . . . . . 30 112 9. Applicability Restrictions . . . . . . . . . . . . . . . . . 30 113 10. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 114 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 31 115 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 116 12.1. Subsequent Address Family Identifiers . . . . . . . . . 33 117 12.2. BGP Path Attributes . . . . . . . . . . . . . . . . . . 33 118 12.3. Extended Communities . . . . . . . . . . . . . . . . . . 33 119 12.4. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . 33 120 12.5. Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 34 121 13. Security Considerations . . . . . . . . . . . . . . . . . . . 34 122 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 123 15. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 36 124 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 125 16.1. Normative References . . . . . . . . . . . . . . . . . . 36 126 16.2. Informative References . . . . . . . . . . . . . . . . . 37 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 129 1. Introduction 131 This document obsoletes RFC 5512. The deficiencies of RFC 5512, and 132 a summary of the changes made, are discussed in Sections 1.1-1.3. 133 The material from RFC 5512 that is retained has been incorporated 134 into this document. 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL", when and only when appearing in all capital letters, are 139 to be interpreted as described in [RFC2119]. 141 1.1. Brief Summary of RFC 5512 143 [RFC5512] defines a BGP Path Attribute known as the Tunnel 144 Encapsulation attribute. This attribute consists of one or more 145 TLVs. Each TLV identifies a particular type of tunnel. Each TLV 146 also contains one or more sub-TLVs. Some of the sub-TLVs, e.g., the 147 "Encapsulation sub-TLV", contain information that may be used to form 148 the encapsulation header for the specified tunnel type. Other sub- 149 TLVs, e.g., the "color sub-TLV" and the "protocol sub-TLV", contain 150 information that aids in determining whether particular packets 151 should be sent through the tunnel that the TLV identifies. 153 [RFC5512] only allows the Tunnel Encapsulation attribute to be 154 attached to BGP UPDATE messages that have the "Encapsulation SAFI" 155 (i.e., UPDATE messages with AFI/SAFI 1/7 or 2/7). In an UPDATE of 156 the Encapsulation SAFI, the NLRI is an address of the BGP speaker 157 originating the UPDATE. Consider the following scenario: 159 o BGP speaker R1 has received and installed UPDATE U; 161 o UPDATE U's SAFI is the Encapsulation SAFI; 163 o UPDATE U has the address R2 as its NLRI; 165 o UPDATE U has a Tunnel Encapsulation attribute. 167 o R1 has a packet, P, to transmit to destination D; 169 o R1's best path to D is a BGP route that has R2 as its next hop; 171 In this scenario, when R1 transmits packet P, it should transmit it 172 to R2 through one of the tunnels specified in U's Tunnel 173 Encapsulation attribute. The IP address of the remote endpoint of 174 each such tunnel is R2. Packet P is known as the tunnel's "payload". 176 1.2. Deficiencies in RFC 5512 178 While the ability to specify tunnel information in a BGP UPDATE is 179 useful, the procedures of [RFC5512] have certain limitations: 181 o The requirement to use the "Encapsulation SAFI" presents an 182 unfortunate operational cost, as each BGP session that may need to 183 carry tunnel encapsulation information needs to be reconfigured to 184 support the Encapsulation SAFI. The Encapsulation SAFI has never 185 been used, and this requirement has served only to discourage the 186 use of the Tunnel Encapsulation attribute. 188 o There is no way to use the Tunnel Encapsulation attribute to 189 specify the remote endpoint address of a given tunnel; [RFC5512] 190 assumes that the remote endpoint of each tunnel is specified as 191 the NLRI of an UPDATE of the Encapsulation-SAFI. 193 o If the respective best paths to two different address prefixes 194 have the same next hop, [RFC5512] does not provide a 195 straightforward method to associate each prefix with a different 196 tunnel. 198 o If a particular tunnel type requires an outer IP or UDP 199 encapsulation, there is no way to signal the values of any of the 200 fields of the outer encapsulation. 202 1.3. Brief Summary of Changes from RFC 5512 204 In this document we address these deficiencies by: 206 o Deprecating the Encapsulation SAFI. 208 o Defining a new "Remote Endpoint Address sub-TLV" that can be 209 included in any of the TLVs contained in the Tunnel Encapsulation 210 attribute. This sub-TLV can be used to specify the remote 211 endpoint address of a particular tunnel. 213 o Allowing the Tunnel Encapsulation attribute to be carried by BGP 214 UPDATEs of additional AFI/SAFIs. Appropriate semantics are 215 provided for this way of using the attribute. 217 o Defining a number of new sub-TLVs that provide additional 218 information that is useful when forming the encapsulation header 219 used to send a packet through a particular tunnel. 221 One of the sub-TLVs defined in [RFC5512] is the "Encapsulation sub- 222 TLV". For a given tunnel, the encapsulation sub-TLV specifies some 223 of the information needed to construct the encapsulation header used 224 when sending packets through that tunnel. This document defines 225 encapsulation sub-TLVs for a number of tunnel types not discussed in 226 [RFC5512]: VXLAN, VXLAN-GPE, NVGRE, GTP, and MPLS-in-GRE. MPLS-in- 227 UDP [RFC7510] is also supported, but an Encapsulation sub-TLV for it 228 is not needed. 230 Some of the encapsulations mentioned in the previous paragraph need 231 to be further encapsulated inside UDP and/or IP. [RFC5512] provides 232 no way to specify that certain information is to appear in these 233 outer IP and/or UDP encapsulations. This document provides a 234 framework for including such information in the TLVs of the Tunnel 235 Encapsulation attribute. 237 When the Tunnel Encapsulation attribute is attached to a BGP UPDATE 238 whose AFI/SAFI identifies one of the labeled address families, it is 239 not always obvious whether the label embedded in the NLRI is to 240 appear somewhere in the tunnel encapsulation header (and if so, 241 where), or whether it is to appear in the payload, or whether it can 242 be omitted altogether. This is especially true if the tunnel 243 encapsulation header itself contains a "virtual network identifier". 244 This document provides a mechanism that allows one to signal (by 245 using sub-TLVs of the Tunnel Encapsulation attribute) how one wants 246 to use the embedded label when the tunnel encapsulation has its own 247 virtual network identifier field. 249 [RFC5512] defines a Tunnel Encapsulation Extended Community, that can 250 be used instead of the Tunnel Encapsulation attribute under certain 251 circumstances. This document addresses the issue of how to handle a 252 BGP UPDATE that carries both a Tunnel Encapsulation attribute and one 253 or more Tunnel Encapsulation Extended Communities. 255 2. The Tunnel Encapsulation Attribute 257 The Tunnel Encapsulation attribute is an optional transitive BGP Path 258 attribute. IANA has assigned the value 23 as the type code of the 259 attribute. The attribute is composed of a set of Type-Length-Value 260 (TLV) encodings. Each TLV contains information corresponding to a 261 particular tunnel type. A TLV is structured as follows: 263 0 1 2 3 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Tunnel Type (2 Octets) | Length (2 Octets) | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | | 269 | Value | 270 | | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 Figure 1: Tunnel Encapsulation TLV Value Field 275 o Tunnel Type (2 octets): identifies a type of tunnel. The field 276 contains values from the IANA Registry "BGP Tunnel Encapsulation 277 Attribute Tunnel Types". 279 Note that for tunnel types whose names are of the form "X-in-Y", 280 e.g., "MPLS-in-GRE", only packets of the specified payload type 281 "X" are to be carried through the tunnel of type "Y". This is the 282 equivalent of specifying a tunnel type "Y" and including in its 283 TLV a Protocol Type sub-TLV (see Section 3.4.1 specifying protocol 284 "X". 286 o Length (2 octets): the total number of octets of the value field. 288 o Value (variable): comprised of multiple sub-TLVs. 290 Each sub-TLV consists of three fields: a 1-octet type, 1-octet 291 length, and zero or more octets of value. A sub-TLV is structured as 292 follows: 294 +-----------------------------------+ 295 | Sub-TLV Type (1 Octet) | 296 +-----------------------------------+ 297 | Sub-TLV Length (1 Octet) | 298 +-----------------------------------+ 299 | Sub-TLV Value (Variable) | 300 | | 301 +-----------------------------------+ 303 Figure 2: Tunnel Encapsulation Sub-TLV Format 305 o Sub-TLV Type (1 octet): each sub-TLV type defines a certain 306 property about the tunnel TLV that contains this sub-TLV. 308 o Sub-TLV Length (1 octet): the total number of octets of the sub- 309 TLV value field. 311 o Sub-TLV Value (variable): encodings of the value field depend on 312 the sub-TLV type as enumerated above. The following sub-sections 313 define the encoding in detail. 315 3. Tunnel Encapsulation Attribute Sub-TLVs 317 In this section, we specify a number of sub-TLVs. These sub-TLVs can 318 be included in a TLV of the Tunnel Encapsulation attribute. 320 3.1. The Remote Endpoint Sub-TLV 322 The Remote Endpoint sub-TLV is a sub-TLV whose value field contains 323 three sub-fields: 325 1. a four-octet Autonomous System (AS) number sub-field 327 2. a two-octet Address Family sub-field 329 3. an address sub-field, whose length depends upon the Address 330 Family. 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Autonomous System Number | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Address Family | Address ~ 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 339 ~ ~ 340 | | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Figure 3: Remote Endpoint Sub-TLV Value Field 345 The Address Family subfield contains a value from IANA's "Address 346 Family Numbers" registry. In this document, we assume that the 347 Address Family is either IPv4 or IPv6; use of other address families 348 is outside the scope of this document. 350 If the Address Family subfield contains the value for IPv4, the 351 address subfield must contain an IPv4 address (a /32 IPv4 prefix). 352 In this case, the length field of Remote Endpoint sub-TLV must 353 contain the value 10 (0xa). IPv4 broadcast addresses are not valid 354 values of this field. 356 If the Address Family subfield contains the value for IPv6, the 357 address sub-field must contain an IPv6 address (a /128 IPv6 prefix). 358 In this case, the length field of Remote Endpoint sub-TLV must 359 contain the value 22 (0x16). IPv6 link local addresses are not valid 360 values of the IP address field. 362 In a given BGP UPDATE, the address family (IPv4 or IPv6) of a Remote 363 Endpoint sub-TLV is independent of the address family of the UPDATE 364 itself. For example, an UPDATE whose NLRI is an IPv4 address may 365 have a Tunnel Encapsulation attribute containing Remote Endpoint sub- 366 TLVs that contain IPv6 addresses. Also, different tunnels 367 represented in the Tunnel Encapsulation attribute may have Remote 368 Endpoints of different address families. 370 A two-octet AS number can be carried in the AS number field by 371 setting the two high order octets to zero, and carrying the number in 372 the two low order octets of the field. 374 The AS number in the sub-TLV MUST be the number of the AS to which 375 the IP address in the sub-TLV belongs. 377 There is one special case: the Remote Endpoint sub-TLV MAY have a 378 value field whose Address Family subfield contains 0. This means 379 that the tunnel's remote endpoint is the UPDATE's BGP next hop. If 380 the Address Family subfield contains 0, the Address subfield is 381 omitted, and the Autonomous System number field is set to 0. 383 If any of the following conditions hold, the Remote Endpoint sub-TLV 384 is considered to be "malformed": 386 o The sub-TLV contains the value for IPv4 in its Address Family 387 subfield, but the length of the sub-TLV's value field is other 388 than 10 (0xa). 390 o The sub-TLV contains the value for IPv6 in its Address Family 391 subfield, but the length of the sub-TLV's value field is other 392 than 22 (0x16). 394 o The sub-TLV contains the value zero in its Address Family field, 395 but the length of the sub-TLV's value field is other than 6, or 396 the Autonomous System subfield is not set to zero. 398 o The IP address in the sub-TLV's address subfield is not a valid IP 399 address (e.g., it's an IPv4 broadcast address). 401 o It can be determined that the IP address in the sub-TLV's address 402 subfield does not belong to the non-zero AS whose number is in the 403 its Autonomous System subfield. (See section Section 13 for 404 discussion of one way to determine this.) 406 If the Remote Endpoint sub-TLV is malformed, the TLV containing it is 407 also considered to be malformed, and the entire TLV MUST be ignored. 408 However, the Tunnel Encapsulation attribute SHOULD NOT be considered 409 to be malformed in this case; other TLVs in the attribute SHOULD be 410 processed (if they can be parsed correctly). 412 When redistributing a route that is carrying a Tunnel Encapsulation 413 attribute containing a TLV that itself contains a malformed Remote 414 Endpoint sub-TLV, the TLV SHOULD be removed from the attribute before 415 redistribution. 417 See Section 11 for further discussion of how to handle errors that 418 are encountered when parsing the Tunnel Encapsulation attribute. 420 If the Remote Endpoint sub-TLV contains an IPv4 or IPv6 address that 421 is valid but not reachable, the sub-TLV is NOT considered to be 422 malformed, and the containing TLV SHOULD NOT be removed from the 423 attribute before redistribution. However, the tunnel identified by 424 the TLV containing that sub-TLV cannot be used until such time as the 425 address becomes reachable. See Section 5. 427 3.2. Encapsulation Sub-TLVs for Particular Tunnel Types 429 This section defines Tunnel Encapsulation sub-TLVs for the following 430 tunnel types: VXLAN ([RFC7348]), VXLAN-GPE ([VXLAN-GPE]), NVGRE 431 ([RFC7637]), GTP ([GTP-U]), MPLS-in-GRE ([RFC2784], [RFC2890], 432 [RFC4023]), L2TPv3 ([RFC3931]), and GRE ([RFC2784], [RFC2890], 433 [RFC4023]). 435 Rules for forming the encapsulation based on the information in a 436 given TLV are given in Section 8. For some tunnel types, the rules 437 are obvious and not mentioned in this document. There are also 438 tunnel types for which it is not necessary to define an Encapsulation 439 sub-TLV. 441 3.2.1. VXLAN 443 This document defines an encapsulation sub-TLV for VXLAN tunnels. 444 When the tunnel type is VXLAN, the following is the structure of the 445 value field in the encapsulation sub-TLV: 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 |V|M|R|R|R|R|R|R| VN-ID (3 Octets) | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | MAC Address (4 Octets) | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | MAC Address (2 Octets) | Reserved | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 Figure 4: VXLAN Encapsulation Sub-TLV 459 V: This bit is set to 1 to indicate that a "valid" VN-ID is 460 present in the encapsulation sub-TLV. Please see Section 8. 462 M: This bit is set to 1 to indicate that a valid MAC Address is 463 present in the encapsulation sub-TLV. 465 R: The remaining bits in the 8-bit flags field are reserved for 466 further use. They SHOULD always be set to 0. 468 VN-ID: If the V bit is set, the VN-id field contains a 3 octet VN- 469 ID value. If the V bit is not set, the VN-id field SHOULD be set 470 to zero. 472 MAC Address: If the M bit is set, this field contains a 6 octet 473 Ethernet MAC address. If the M bit is not set, this field SHOULD 474 be set to all zeroes. 476 Note that, strictly speaking, VXLAN tunnels only carry ethernet 477 frames. To send an IP packet or an MPLS packet through a VXLAN 478 tunnel, it is necessary to form an IP-in-ethernet-in-VXLAN or an 479 MPLS-in-ethernet-in-VXLAN tunnel. 481 When forming the VXLAN encapsulation header: 483 o The values of the V, M, and R bits are NOT copied into the flags 484 field of the VXLAN header. The flags field of the VXLAN header is 485 set as per [RFC7348]. 487 o If the M bit is set, the MAC Address is copied into the Inner 488 Destination MAC Address field of the Inner Ethernet Header (see 489 section 5 of [RFC7348]. 491 If the M bit is not set, and the payload being sent through the 492 VXLAN tunnel is an ethernet frame, the Destination MAC Address 493 field of the Inner Ethernet Header is just the Destination MAC 494 Address field of the payload's ethernet header. 496 If the M bit is not set, and the payload being sent through the 497 VXLAN tunnel is an IP or MPLS packet, the Inner Destination MAC 498 address field is set to a configured value; if there is no 499 configured value, the VXLAN tunnel cannot be used. 501 o See Section 8 to see how the VNI field of the VXLAN encapsulation 502 header is set. 504 3.2.2. VXLAN-GPE 506 This document defines an encapsulation sub-TLV for VXLAN tunnels. 507 When the tunnel type is VXLAN-GPE, the following is the structure of 508 the value field in the encapsulation sub-TLV: 510 0 1 2 3 511 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 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 |Ver|V|R|R|R|R|R| Reserved | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | VN-ID | Reserved | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 Figure 5: VXLAN GPE Encapsulation Sub-TLV 520 V: This bit is set to 1 to indicate that a "valid" VN-ID is 521 present in the encapsulation sub-TLV. Please see Section 8. 523 R: The bits designated "R" above are reserved for future use. 524 They SHOULD always be set to zero. 526 Version (Ver): Indicates VXLAN GPE protocol version. If the 527 indicated version is not supported, the TLV that contains this 528 Encapsulation sub-TLV MUST be treated as specifying an unsupported 529 tunnel type. The value of this field will be copied into the 530 corresponding field of the VXLAN encapsulation header. 532 VN-ID: If the V bit is set, this field contains a 3 octet VN-ID 533 value. If the V bit is not set, this field SHOULD be set to zero. 535 When forming the VXLAN-GPE encapsulation header: 537 o The values of the V and R bits are NOT copied into the flags field 538 of the VXLAN-GPE header. However, the values of the Ver bits are 539 copied into the VXLAN-GPE header. Other bits in the flags field 540 of the VXLAN-GPE header are set as per [VXLAN-GPE]. 542 o See Section 8 to see how the VNI field of the VXLAN-GPE 543 encapsulation header is set. 545 3.2.3. NVGRE 547 This document defines an encapsulation sub-TLV for NVGRE tunnels. 548 When the tunnel type is NVGRE, the following is the structure of the 549 value field in the encapsulation sub-TLV: 551 0 1 2 3 552 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 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 |V|M|R|R|R|R|R|R| VN-ID (3 Octets) | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | MAC Address (4 Octets) | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | MAC Address (2 Octets) | Reserved | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 Figure 6: NVGRE Encapsulation Sub-TLV 563 V: This bit is set to 1 to indicate that a "valid" VN-ID is 564 present in the encapsulation sub-TLV. Please see Section 8. 566 M: This bit is set to 1 to indicate that a valid MAC Address is 567 present in the encapsulation sub-TLV. 569 R: The remaining bits in the 8-bit flags field are reserved for 570 further use. They SHOULD always be set to 0. 572 VN-ID: If the V bit is set, the VN-id field contains a 3 octet VN- 573 ID value. If the V bit is not set, the VN-id field SHOULD be set 574 to zero. 576 MAC Address: If the M bit is set, this field contains a 6 octet 577 Ethernet MAC address. If the M bit is not set, this field SHOULD 578 be set to all zeroes. 580 When forming the NVGRE encapsulation header: 582 o The values of the V, M, and R bits are NOT copied into the flags 583 field of the NVGRE header. The flags field of the VXLAN header is 584 set as per [RFC7637]. 586 o If the M bit is set, the MAC Address is copied into the Inner 587 Destination MAC Address field of the Inner Ethernet Header (see 588 section 3.2 of [RFC7637]. 590 If the M bit is not set, and the payload being sent through the 591 NVGRE tunnel is an ethernet frame, the Destination MAC Address 592 field of the Inner Ethernet Header is just the Destination MAC 593 Address field of the payload's ethernet header. 595 If the M bit is not set, and the payload being sent through the 596 NVGRE tunnel is an IP or MPLS packet, the Inner Destination MAC 597 address field is set to a configured value; if there is no 598 configured value, the NVGRE tunnel cannot be used. 600 o See Section 8 to see how the VSID field of the NVGRE encapsulation 601 header is set. 603 3.2.4. L2TPv3 605 When the tunnel type of the TLV is L2TPv3 over IP, the following is 606 the structure of the value field of the encapsulation sub-TLV: 608 0 1 2 3 609 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 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Session ID (4 octets) | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | | 614 | Cookie (Variable) | 615 | | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 Figure 7: L2TPv3 Encapsulation Sub-TLV 620 Session ID: a non-zero 4-octet value locally assigned by the 621 advertising router that serves as a lookup key in the incoming 622 packet's context. 624 Cookie: an optional, variable length (encoded in octets -- 0 to 8 625 octets) value used by L2TPv3 to check the association of a 626 received data message with the session identified by the Session 627 ID. Generation and usage of the cookie value is as specified in 628 [RFC3931]. 630 The length of the cookie is not encoded explicitly, but can be 631 calculated as (sub-TLV length - 4). 633 3.2.5. GTP 635 When the tunnel type is GTP [GTP-U], the Encapsulation sub-TLV 636 contains information needed to send data packets through a GTP 637 tunnel, and also contains information needed by the tunnel's remote 638 endpoint to create a "reverse" tunnel back to the transmitter. This 639 allows a bidirectional control connection to be created. The format 640 of the Encapsulation Sub-TLV is: 642 0 1 2 3 643 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 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Remote TEID (4 Octets) | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Local TEID (4 Octets) | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Local Endpoint Address (4/16 Octets (IPv4/IPv6)) | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 Figure 8: GTP Encapsulation Sub-TLV 654 Remote TEID: Contains the 32-bit Tunnel Endpoint Identifier of the 655 GTP tunnel through which data packets are to be sent. When data 656 packets are sent through the tunnel, the Remote TEID is carried in 657 the GTP encapsulation header. The GTP header is itself 658 encapsulation within an IP header, whose IP destination address 659 field is set to the value of the Remote Endpoint sub-TLV. 661 Local TEID: Contains a 32-bit Tunnel Endpoint Identifier of a GTP 662 tunnel assigned by EPC ([vEPC]). 664 Local Endpoint Address: Contains an IPv4 or IPv6 anycast address. 665 This is used, along with the Local TEID, to set up a tunnel in the 666 reverse direction. See [vEPC] for details. 668 3.2.6. GRE 670 When the tunnel type of the TLV is GRE, the following is the 671 structure of the value field of the encapsulation sub-TLV: 673 0 1 2 3 674 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 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | GRE Key (4 octets) | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 Figure 9: GRE Encapsulation Sub-TLV 681 GRE Key: 4-octet field [RFC2890] that is generated by the 682 advertising router. The actual method by which the key is 683 obtained is beyond the scope of this document. The key is 684 inserted into the GRE encapsulation header of the payload packets 685 sent by ingress routers to the advertising router. It is intended 686 to be used for identifying extra context information about the 687 received payload. 689 Note that the key is optional. Unless a key value is being 690 advertised, the GRE encapsulation sub-TLV MUST NOT be present. 692 3.2.7. MPLS-in-GRE 694 When the tunnel type is MPLS-in-GRE, the following is the structure 695 of the value field in an optional encapsulation sub-TLV: 697 0 1 2 3 698 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 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | GRE-Key (4 Octets) | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 Figure 10: MPLS-in-GRE Encapsulation Sub-TLV 705 GRE-Key: 4-octet field [RFC2890] that is generated by the 706 advertising router. The actual method by which the key is 707 obtained is beyond the scope of this document. The key is 708 inserted into the GRE encapsulation header of the payload packets 709 sent by ingress routers to the advertising router. It is intended 710 to be used for identifying extra context information about the 711 received payload. Note that the key is optional. Unless a key 712 value is being advertised, the MPLS-in-GRE encapsulation sub-TLV 713 MUST NOT be present. 715 Note that the GRE tunnel type defined in Section 3.2.6 can be used 716 instead of the MPLS-in-GRE tunnel type when it is necessary to 717 encapsulate MPLS in GRE. Including a TLV of the MPLS-in-GRE tunnel 718 type is equivalent to including a TLV of the GRE tunnel type that 719 also includes a Protocol Type sub-TLV ([RFC5512]) specifying MPLS as 720 the protocol to be encapsulated. That is, if a TLV specifies MPLS- 721 in-GRE or if it includes a Protocol Type sub-TLV specifying MPLS, the 722 GRE tunnel advertised in that TLV MUST NOT be used for carrying IP 723 packets. 725 While it is not really necessary to have both the GRE and MPLS-in-GRE 726 tunnel types, both are included for reasons of backwards 727 compatibility. 729 3.3. Outer Encapsulation Sub-TLVs 731 The Encapsulation sub-TLV for a particular tunnel type allows one to 732 specify the values that are to be placed in certain fields of the 733 encapsulation header for that tunnel type. However, some tunnel 734 types require an outer IP encapsulation, and some also require an 735 outer UDP encapsulation. The Encapsulation sub-TLV for a given 736 tunnel type does not usually provide a way to specify values for 737 fields of the outer IP and/or UDP encapsulations. If it is necessary 738 to specify values for fields of the outer encapsulation, additional 739 sub-TLVs must be used. This document defines two such sub-TLVs. 741 If an outer encapsulation sub-TLV occurs in a TLV for a tunnel type 742 that does not use the corresponding outer encapsulation, the sub-TLV 743 is treated as if it were an unknown type of sub-TLV. 745 3.3.1. IPv4 DS Field 747 Most of the tunnel types that can be specified in the Tunnel 748 Encapsulation attribute require an outer IP encapsulation. The IPv4 749 DS Field sub-TLV can be carried in the TLV of any such tunnel type. 750 It specifies the setting of one-octet Differentiated Services field 751 in the outer IP encapsulation (see [RFC2474]). The value field is 752 always a single octet. 754 3.3.2. UDP Destination Port 756 Some of the tunnel types that can be specified in the Tunnel 757 Encapsulation attribute require an outer UDP encapsulation. 758 Generally there is a standard UDP Destination Port value for a 759 particular tunnel type. However, sometimes it is useful to be able 760 to use a non-standard UDP destination port. If a particular tunnel 761 type requires an outer UDP encapsulation, and it is desired to use a 762 UDP destination port other than the standard one, the port to be used 763 can be specified by including a UDP Destination Port sub-TLV. The 764 value field of this sub-TLV is always a two-octet field, containing 765 the port value. 767 3.4. Sub-TLVs for Aiding Tunnel Selection 769 3.4.1. Protocol Type Sub-TLV 771 The protocol type sub-TLV MAY be included in a given TLV to indicate 772 the type of the payload packets that may be encapsulated with the 773 tunnel parameters that are being signaled in the TLV. The value 774 field of the sub-TLV contains a 2-octet value from IANA's ethertype 775 registry [Ethertypes]. 777 For example, if we want to use three L2TPv3 sessions, one carrying 778 IPv4 packets, one carrying IPv6 packets, and one carrying MPLS 779 packets, the egress router will include three TLVs of L2TPv3 780 encapsulation type, each specifying a different Session ID and a 781 different payload type. The protocol type sub-TLV for these will be 782 IPv4 (protocol type = 0x0800), IPv6 (protocol type = 0x86dd), and 783 MPLS (protocol type = 0x8847), respectively. This informs the 784 ingress routers of the appropriate encapsulation information to use 785 with each of the given protocol types. Insertion of the specified 786 Session ID at the ingress routers allows the egress to process the 787 incoming packets correctly, according to their protocol type. 789 3.4.2. Color Sub-TLV 791 The color sub-TLV MAY be encoded as a way to "color" the 792 corresponding tunnel TLV. The value field of the sub-TLV consists of 793 a Color Extended Community, as defined in Section 4.3. For the use 794 of this sub-TLV and Extended Community, please see Section 7. 796 3.5. Embedded Label Handling Sub-TLV 798 Certain BGP address families (corresponding to particular AFI/SAFI 799 pairs, e.g., 1/4, 2/4, 1/128, 2/128) have MPLS labels embedded in 800 their NLRIs. We will use the term "embedded label" to refer to the 801 MPLS label that is embedded in an NLRI, and the term "labeled address 802 family" to refer to any AFI/SAFI that has embedded labels. 804 Some of the tunnel types (e.g., VXLAN, VXLAN-GPE, and NVGRE) that can 805 be specified in the Tunnel Encapsulation attribute have an 806 encapsulation header containing "Virtual Network" identifier of some 807 sort. The Encapsulation sub-TLVs for these tunnel types may 808 optionally specify a value for the virtual network identifier. 810 Suppose a Tunnel Encapsulation attribute is attached to an UPDATE of 811 an embedded address family, and it is decided to use a particular 812 tunnel (specified in one of the attribute's TLVs) for transmitting a 813 packet that is being forwarded according to that UPDATE. When 814 forming the encapsulation header for that packet, different 815 deployment scenarios require different handling of the embedded label 816 and/or the virtual network identifier. The Embedded Label Handling 817 sub-TLV can be used to control the placement of the embedded label 818 and/or the virtual network identifier in the encapsulation. 820 The Embedded Label Handling sub-TLV may be included in any TLV of the 821 Tunnel Encapsulation attribute. If the Tunnel Encapsulation 822 attribute is attached to an UPDATE of a non-labeled address family, 823 the sub-TLV is treated as a no-op. If the sub-TLV is contained in a 824 TLV whose tunnel type does not have a virtual network identifier in 825 its encapsulation header, the sub-TLV is treated as a no-op. In 826 those cases where the sub-TLV is treated as a no-op, it SHOULD NOT be 827 stripped from the TLV before the UPDATE is forwarded. 829 The sub-TLV's Length field always contains the value 1, and its value 830 field consists of a single octet. The following values are defined: 832 1: The payload will be an MPLS packet with the embedded label at the 833 top of its label stack. 835 2: The embedded label is not carried in the payload, but is carried 836 either in the virtual network identifier field of the 837 encapsulation header, or else is ignored entirely. 839 Please see Section 8 for the details of how this sub-TLV is used when 840 it is carried by an UPDATE of a labeled address family. 842 3.6. MPLS Label Stack Sub-TLV 844 This sub-TLV allows an MPLS label stack to be associated with a 845 particular tunnel. 847 The value field of this sub-TLV is a sequence of MPLS label stack 848 entries. The first entry in the sequence is the "topmost" label, the 849 final entry in the sequence is the "bottommost" label. When this 850 label stack is pushed onto a packet, this ordering MUST be preserved. 852 Each label stack entry has the following format: 854 0 1 2 3 855 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 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Label | ToS |S| TTL | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 Figure 11: MPLS Label Stack Sub-TLV 862 If a packet is to be sent through the tunnel identified in a 863 particular TLV, and if that TLV contains an MPLS Label Stack sub-TLV, 864 then the label stack appearing in the sub-TLV MUST be pushed onto the 865 packet. This label stack MUST be pushed onto the packet before any 866 other labels are pushed onto the packet. 868 In particular, if the Tunnel Encapsulation attribute is attached to a 869 BGP UPDATE of a labeled address family, the contents of the MPLS 870 Label Stack sub-TLV MUST be pushed onto the packet before the label 871 embedded in the NLRI is pushed onto the packet. 873 If the MPLS label stack sub-TLV is included in a TLV identifying a 874 tunnel type that uses virtual network identifiers (see Section 8), 875 the contents of the MPLS label stack sub-TLV MUST be pushed onto the 876 packet before the procdures of Section 8 are applied. 878 The number of label stack entries in the sub-TLV MUST be determined 879 from the sub-TLV length field. Thus it is not necessary to set the S 880 bit in any of the label stack entries of the sub-TLV, and the setting 881 of the S bit is ignored when parsing the sub-TLV. When the label 882 stack entries are pushed onto a packet that already has a label 883 stack, the S bits of all the entries MUST be cleared. When the label 884 stack entries are pushed onto a packet that does not already have a 885 label stack, the S bit of the bottommost label stack entry MUST be 886 set, and the S bit of all the other label stack entries MUST be 887 cleared.. 889 By default, the ToS field of each label stack entry is set to 0. 890 This may of course be changed by policy at the originator of the sub- 891 TLV. When pushing the label stack onto a packet, the ToS of the 892 label stack entries is preserved by default. However, local policy 893 at the router that is pushing on the stack MAY cause modification of 894 the ToS values. 896 By default, the TTL field of each label stack entry is set to 255. 897 This may be changed by policy at the originator of the sub-TLV. When 898 pushing the label stack onto a packet, the TTL of the label stack 899 entries is preserved by default. However, local policy at the router 900 that is pushing on the stack MAY cause modification of the TTL 901 values. If any label stack entry in the sub-TLV has a TTL value of 902 zero, the router that is pushing the stack on a packet MUST change 903 the value to a non-zero value. 905 Note that this sub-TLV can be appear within a TLV identifying any 906 type of tunnel, not just within a TLV identifying an MPLS tunnel. 907 However, if this sub-TLV appears within a TLV identifying an MPLS 908 tunnel (or an MPLS-in-X tunnel), this sub-TLV plays the same role 909 that would be played by an MPLS Encapsulation sub-TLV. Therefore, an 910 MPLS Encapsulation sub-TLV is not defined. 912 3.7. Prefix-SID Sub-TLV 914 [Prefix-SID-Attribute] defines a BGP Path attribute known as the 915 "Prefix-SID Attribute". This attribute is defined to contain a 916 sequence of one or more TLVs, where each TLV is either a "Label- 917 Index" TLV, an "IPv6 SID" TLV, or an "Originator SRGB" TLV. 919 In this document, we define a Prefix-SID sub-TLV. The value field of 920 the Prefix-SID sub-TLV can be set to any valid value of the value 921 field of a BGP Prefix-SID attribute, as defined in 922 [Prefix-SID-Attribute]. 924 The Prefix-SID sub-TLV can occur in a TLV identifying any type of 925 tunnel. If an Originator SRGB is specified in the sub-TLV, the SRGB 926 MUST be interpreted to be the SRGB used by the tunnel's Remote 927 Endpoint. The Label-Index, if present, is the Segment Routing SID 928 that the tunnel's Remote Endpoint uses to represent the prefix 929 appearing in the NLRI field of the BGP UPDATE to which the Tunnel 930 Encapsulation attribute is attached. 932 If a Label-Index is present in the prefix-SID sub-TLV, then when a 933 packet is sent through the tunnel identified by the TLV, the 934 corresponding MPLS label MUST be pushed on the packet's label stack. 935 If the Originator SRGB is present, the corresponding MPLS label is 936 computed from the combination of the Label-Index and the Originator 937 SRGB (see [Prefix-SID-Attribute]). If the Originator SRGB is not 938 present, the corresponding MPLS label is just the Label-Index value 939 itself. The corresponding MPLS label is pushed on after the 940 processing of the MPLS Label Stack sub-TLV, if present, as specified 941 in Section 3.6. It is pushed on before any other labels (e.g., a 942 label embedded in UPDATE's NLRI, or a label determined by the 943 procedures of Section 8 are pushed on the stack. 945 The Prefix-SID sub-TLV has slightly different semantics than the 946 Prefix-SID attribute. When the Prefix-SID attribute is attached to a 947 given route, the BGP speaker that originally attached the attribute 948 is expected to be in the same Segment Routing domain as the BGP 949 speakers who receive the route with the attached attribute. The 950 Label-Index tells the receiving BGP speakers that the prefix-SID is 951 for the advertised prefix in that Segment Routing domain. When the 952 Prefix-SID sub-TLV is used, the BGP speaker at the head end of the 953 tunnel need even not be in the same Segment Routing Domain as the 954 tunnel's Remote Endpoint, and there is no implication that the 955 prefix-SID for the advertised prefix is the same in the Segment 956 Routing domains of the BGP speaker that originated the sub-TLV and 957 the BGP speaker that received it. 959 4. Extended Communities Related to the Tunnel Encapsulation Attribute 961 4.1. Encapsulation Extended Community 963 The Encapsulation Extended Community is a Transitive Opaque Extended 964 Community. This Extended Community may be attached to a route of any 965 AFI/SAFI to which the Tunnel Encapsulation attribute may be attached. 966 Each such Extended Community identifies a particular tunnel type. If 967 the Encapsulation Extended Community identifies a particular tunnel 968 type, its semantics are exactly equivalent to the semantics of a 969 Tunnel Encapsulation attribute TLV that: 971 o identifies the same tunnel type, and 973 o has a Remote Endpoint sub-TLV whose IP address field contains the 974 address of the BGP next hop of the route to which it is attached, 975 and 977 o has no other sub-TLVs. 979 The Encapsulation Extended Community was first defined in [RFC5512]. 980 It provides a small subset of the functionality of the Tunnel 981 Encapsulation attribute, and, strictly speaking, is no longer needed. 982 However, it is included here for backwards compatibility. 984 Note that for tunnel types of the form "X-in-Y", e.g., MPLS-in-GRE, 985 the Encapsulation Extended Community implies that only packets of the 986 specified payload type "X" are to be carried through the tunnel of 987 type "Y". 989 In the remainder of this specification, when we speak of a route as 990 containing a Tunnel Encapsulation attribute with a TLV identifying a 991 particular tunnel type, we are implicitly including the case where 992 the route contains a Tunnel Encapsulation Extended Community 993 identifying that tunnel type. 995 4.2. Router's MAC Extended Community 997 [EVPN-Inter-Subnet] defines a Router's MAC Extended Community. This 998 Extended Community provides information that may conflict with 999 information in one or more of the Encapsulation Sub-TLVs of a Tunnel 1000 Encapsulation attribute. In case of such a conflict, the information 1001 in the Encapsulation Sub-TLV takes precedence. 1003 4.3. Color Extended Community 1005 The Color Extended Community is a Transitive Opaque Extended 1006 Community with the following encoding: 1008 0 1 2 3 1009 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 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | 0x03 | 0x0b | Reserved | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | Color Value | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 Figure 12: Color Extended Community 1018 For the use of this Extended Community please see Section 7. 1020 5. Semantics and Usage of the Tunnel Encapsulation attribute 1022 [RFC5512] specifies the use of the Tunnel Encapsulation attribute in 1023 BGP UPDATE messages of AFI/SAFI 1/7 and 2/7. That document restricts 1024 the use of this attribute to UPDATE messsages of those SAFIs. This 1025 document removes that restriction. 1027 The BGP Tunnel Encapsulation attribute MAY be carried in any BGP 1028 UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6 1029 Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast), 1030 1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast), 1031 or 25/70 (EVPN). Use of the Tunnel Encapsulation attribute in BGP 1032 UPDATE messages of other AFI/SAFIs is outside the scope of this 1033 document. 1035 It has been suggested that it may sometimes be useful to attach a 1036 Tunnel Encapsulation attribute to a BGP UPDATE message that is also 1037 carrying a PMSI (Provider Multicast Service Interface) Tunnel 1038 attribute [RFC6514]. If the PMSI Tunnel attribute specifies an IP 1039 tunnel, the Tunnel Encapsulation attribute could be used to provide 1040 additional information about the IP tunnel. The usage of the Tunnel 1041 Encapsulation attribute in combination with the PMSI Tunnel attribute 1042 is outside the scope of this document. 1044 The decision to attach a Tunnel Encapsulation attribute to a given 1045 BGP UPDATE is determined by policy. The set of TLVs and sub-TLVs 1046 contained in the attribute is also determined by policy. 1048 When the Tunnel Encapsulation attribute is carried in an UPDATE of 1049 one of the AFI/SAFIs specifies in the previous paragraph, each TLV 1050 MUST have a Remote Endpoint sub-TLV. If a TLV that does not have a 1051 Remote Endpoint sub-TLV, that TLV should be treated as if it had a 1052 malformed Remote Endpoint sub-TLV (see Section 3.1). 1054 Suppose that: 1056 o a given packet P must be forwarded by router R; 1058 o the path along which P is to be forwarded is determined by BGP 1059 UPDATE U; 1061 o UPDATE U has a Tunnel Encapsulation attribute, containing at least 1062 one TLV that identifies a "feasible tunnel" for packet P. A 1063 tunnel is considered feasible if it has the following two 1064 properties: 1066 * The tunnel type is supported (i.e., router R knows how to set 1067 up tunnels of that type, how to create the encapsulation header 1068 for tunnels of that type, etc.) 1070 * The tunnel is of a type that can be used to carry packet P 1071 (e.g., an MPLS-in-UDP tunnel would not be a feasible tunnel for 1072 carrying an IP packet, UNLESS the IP packet can first be 1073 converted to an MPLS packet). 1075 * The tunnel is specified in a TLV whose Remote Endpoint sub-TLV 1076 identifies an IP address that is reachable. 1078 Then router R SHOULD send packet P through one of the feasible 1079 tunnels identified in the Tunnel Encapsulation attribute of UPDATE U. 1081 If the Tunnel Encapsulation attribute contains several TLVs (i.e., if 1082 it specifies several tunnels), router R may choose any one of those 1083 tunnels, based upon local policy. If any of tunnels' TLVs contain 1084 the Color sub-TLV(Section 3.4.2) and/or the Protocol Type sub-TLV 1085 (Section 3.4.1, the choice of tunnel may be influenced by these sub- 1086 TLVs. 1088 Note that if none of the TLVs specifies the MPLS tunnel type, a Label 1089 Switched Path SHOULD NOT be used unless none of the TLVs specifies a 1090 feasible tunnel. 1092 If a particular tunnel is not feasible at some moment because its 1093 Remote Endpoint cannot be reached at that moment, the tunnel may 1094 become feasible at a later time. When this happens, router R SHOULD 1095 reconsider its choice of tunnel to use, and MAY choose to now use the 1096 tunnel. 1098 A TLV specifying a non-feasible tunnel is not considered to be 1099 malformed or erroneous in any way, and the TLV SHOULD NOT be stripped 1100 from the Tunnel Encapsulation attribute before redistribution. 1102 In addition to the sub-TLVs already defined, additional sub-TLVs may 1103 be defined that affect the choice of tunnel to be used, or that 1104 affect the contents of the tunnel encapsulation header. The 1105 documents that define any such additional sub-TLVs must specify the 1106 effect that including the sub-TLV is to have. 1108 If it is determined to send a packet through the tunnel specified in 1109 a particular TLV of a particular Tunnel Encapsulation attribute, then 1110 the tunnel's remote endpoint address is the IP address contained in 1111 the sub-TLV. If the TLV contains a Remote Endpoint sub-TLV whose 1112 value field is all zeroes, then the tunnel's remote endpoint is the 1113 IP address specified as the Next Hop of the BGP Update containing the 1114 Tunnel Encapsulation attribute. 1116 The procedure for sending a packet through a particular tunnel type 1117 to a particular remote endpoint depends upon the tunnel type, and is 1118 outside the scope of this document. The contents of the tunnel 1119 encapsulation header MAY be influenced by the Encapsulation sub-TLV. 1121 Note that some tunnel types may require the execution of an explicit 1122 tunnel setup protocol before they can be used for carrying data. 1124 Other tunnel types may not require any tunnel setup protocol. 1125 Whenever a new Tunnel Type TLV is defined, the specification of that 1126 TLV must describe (or reference) the procedures for creating the 1127 encapsulation header used to forward packets through that tunnel 1128 type. 1130 If a Tunnel Encapsulation attribute specifies several tunnels, the 1131 way in which a router chooses which one to use is a matter of policy, 1132 subject to the following constraint: if a router can determine that a 1133 given tunnel is not functional, it MUST NOT use that tunnel. In 1134 particular, if the tunnel is identified in a TLV that has a Remote 1135 Endpoint sub-TLV, and if the IP address specified in the sub-TLV is 1136 not reachable from router R, then the tunnel SHOULD be considered 1137 non-functional. Other means of determining whether a given tunnel is 1138 functional MAY be used; specification of such means is outside the 1139 scope of this specification. Of course, if a non-functional tunnel 1140 later becomes functional, router R SHOULD reevaluate its choice of 1141 tunnels. 1143 If router R determines that it cannot use any of the tunnels 1144 specified in the Tunnel Encapsulation attribute, it MAY either drop 1145 packet P, or it MAY transmit packet P as it would had the Tunnel 1146 Encapsulation attribute not been present. This is a matter of local 1147 policy. By default, the packet SHOULD be transmitted as if the 1148 Tunnel Encapsulation attribute had not been present. 1150 A Tunnel Encapsulation attribute may contain several TLVs that all 1151 specify the same tunnel type. Each TLV should be considered as 1152 specifying a different tunnel. Two tunnels of the same type may have 1153 different Remote Endpoint sub-TLVs, different Encapsulation sub-TLVs, 1154 etc. Choosing between two such tunnels is a matter of local policy. 1156 Once router R has decided to send packet P through a particular 1157 tunnel, it encapsulates packet P appropriately and then forwards it 1158 according to the route that leads to the tunnel's remote endpoint. 1159 This route may itself be a BGP route with a Tunnel Encapsulation 1160 attribute. If so, the encapsulated packet is treated as the payload 1161 and is encapsulated according to the Tunnel Encapsulation attribute 1162 of that route. That is, tunnels may be "stacked". 1164 Notwithstanding anything said in this document, a BGP speaker MAY 1165 have local policy that influences the choice of tunnel, and the way 1166 the encapsulation is formed. A BGP speaker MAY also have a local 1167 policy that tells it to ignore the Tunnel Encapsulation attribute 1168 entirely or in part. Of course, interoperability issues must be 1169 considered when such policies are put into place. 1171 6. Routing Considerations 1173 6.1. No Impact on BGP Decision Process 1175 The presence of the Tunnel Encapsulation attribute does not affect 1176 the BGP bestpath selection algorithm. 1178 Under certain circumstances, this may lead to counter-intuitive 1179 consequences. For example, suppose: 1181 o router R1 receives a BGP UPDATE message from router R2, such that 1183 * the NLRI of that UPDATE is prefix X, 1185 * the UPDATE contains a Tunnel Encapsulation attribute specifying 1186 two tunnels, T1 and T2, 1188 * R1 cannot use tunnel T1 or tunnel T2, either because the tunnel 1189 remote endpoint is not reachable or because R1 does not support 1190 that kind of tunnel 1192 o router R1 receives a BGP UPDATE message from router R3, such that 1194 * the NLRI of that UPDATE is prefix X, 1196 * the UPDATE contains a Tunnel Encapsulation attribute specifying 1197 two tunnels, T3 and T4, 1199 * R1 can use at least one of the two tunnels 1201 Since the Tunnel Encapsulation attribute does not affect bestpath 1202 selection, R1 may well install the route from R2 rather than the 1203 route from R3, even though R2's route contains no usable tunnels. 1205 This possibility must be kept in mind whenever a Remote Endpoint sub- 1206 TLV carried by a given UPDATE specifies an IP address that is 1207 different than the next hop of that UPDATE. 1209 6.2. Looping, Infinite Stacking, Etc. 1211 Consider a packet destined for address X. Suppose a BGP UPDATE for 1212 address prefix X carries a Tunnel Encapsulation attribute that 1213 specifies a remote tunnel endpoint of Y. And suppose that a BGP 1214 UPDATE for address prefix Y carries a Tunnel Encapsulation attribute 1215 that specifies a Remote Endpoint of X. It is easy to see that this 1216 will cause an infinite number of encapsulation headers to be put on 1217 the given packet. 1219 This could happen as a result of misconfiguration, either accidental 1220 or intentional. It could also happen if the Tunnel Encapsulation 1221 attribute were altered by a malicious agent. Implementations should 1222 be aware of this. 1224 Improper setting (or malicious altering) of the Tunnel Encapsulation 1225 attribute could also cause data packets to loop. Suppose a BGP 1226 UPDATE for address prefix X carries a Tunnel Encapsulation attribute 1227 that specifies a remote tunnel endpoint of Y. Suppose router R 1228 receives and processes the update. When router R receives a packet 1229 destined for X, it will apply the encapsulation and send the 1230 encapsulated packet to Y. Y will decapsulate the packet and forward 1231 it further. If Y is further away from X than is router R, it is 1232 possible that the path from Y to X will traverse R. This would cause 1233 a long-lasting routing loop. 1235 These possibilities must also be kept in mind whenever the Remote 1236 Endpoint for a given prefix differs from the BGP next hop for that 1237 prefix. 1239 7. Recursive Next Hop Resolution 1241 Suppose that: 1243 o a given packet P must be forwarded by router R1; 1245 o the path along which P is to be forwarded is determined by BGP 1246 UPDATE U1; 1248 o UPDATE U1 does not have a Tunnel Encapsulation attribute; 1250 o the next hop of UPDATE U1 is router R2; 1252 o the best path to router R2 is a BGP route that was advertised in 1253 UPDATE U2; 1255 o UPDATE U2 has a Tunnel Encapsulation attribute. 1257 Then packet P SHOULD be sent through one of the tunnels identified in 1258 the Tunnel Encapsulation attribute of UPDATE U2. See Section 5 for 1259 further details. 1261 However, suppose that one of the TLVs in U2's Tunnel Encapsulation 1262 attribute contains the Color Sub-TLV. In that case, packet P SHOULD 1263 NOT be sent through the tunnel identified in that TLV, unless U1 is 1264 carrying the Color Extended Community that is identified in U2's 1265 Color Sub-TLV. 1267 Note that if UPDATE U1 and UPDATE U2 both have Tunnel Encapsulation 1268 attributes, packet P will be carried through a pair of nested 1269 tunnels. P will first be encapsulated based on the Tunnel 1270 Encapsulation attribute of U1. This encapsulated packet then becomes 1271 the payload, and is encapsulated based on the Tunnel Encapsulation 1272 attribute of U2. This is another way of "stacking" tunnels (see also 1273 Section 5. 1275 The procedures in this section presuppose that U1's next hop resolves 1276 to a BGP route, and that U2's next hop resolves (perhaps after 1277 further recursion) to a non-BGP route. 1279 8. Use of Virtual Network Identifiers and Embedded Labels when Imposing 1280 a Tunnel Encapsulation 1282 If the TLV specifying a tunnel contains an MPLS Label Stack sub-TLV, 1283 then when sending a packet through that tunnel, the procedures of 1284 Section 3.6 are applied before the procedures of this section. 1286 If the TLV specifying a tunnel contains a Prefix-SID sub-TLV, the 1287 procedures of Section 3.7 are applied before the procedures of this 1288 section. If the TLV also contains an MPLS Label Stack sub-TLV, the 1289 procedures of Section 3.6 are applied before the procedures of 1290 Section 3.7. 1292 8.1. Tunnel Types without a Virtual Network Identifier Field 1294 If a Tunnel Encapsulation attribute is attached to an UPDATE of a 1295 labeled address family, there will be one or more labels specified in 1296 the UPDATE's NLRI. When a packet is sent through a tunnel specified 1297 in one of the attribute's TLVs, and that tunnel type does not contain 1298 a virtual network identifier field, the label or labels from the NLRI 1299 are pushed on the packet's label stack. The resulting MPLS packet is 1300 then further encapsulated, as specified by the TLV. 1302 8.2. Tunnel Types with a Virtual Network Identifier Field 1304 Three of the tunnel types that can be specified in a Tunnel 1305 Encapsulation TLV have virtual network identifier fields in their 1306 encapsulation headers. In the VXLAN and VXLAN-GPE encapsulations, 1307 this field is called the VNI field; in the NVGRE encapsulation, this 1308 field is called the VSID field. 1310 When one of these tunnel encapsulations is imposed on a packet, the 1311 setting of the virtual network identifier field in the encapsulation 1312 header depends upon the contents of the Encapsulation sub-TLV (if one 1313 is present). When the Tunnel Encapsulation attribute is being 1314 carried on a BGP UPDATE of a labeled address family, the setting of 1315 the virtual network identifier field also depends upon the contents 1316 of the Embedded Label Handling sub-TLV (if present). 1318 This section specifies the procedures for choosing the value to set 1319 in the virtual network identifier field of the encapsulation header. 1320 These procedures apply only when the tunnel type is VXLAN, VXLAN-GPE, 1321 or NVGRE. 1323 8.2.1. Unlabeled Address Families 1325 This sub-section applies when: 1327 o the Tunnel Encapsulation attribute is carried on a BGP UPDATE of 1328 an unlabeled address family, and 1330 o at least one of the attribute's TLVs identifies a tunnel type that 1331 uses a virtual network identifier, and 1333 o it has been determined to send a packet through one of those 1334 tunnels. 1336 If the TLV identifying the tunnel contains an Encapsulation sub-TLV 1337 whose V bit is set, the virtual network identifier field of the 1338 encapsulation header is set to the value of the virtual network 1339 identifier field of the Encapsulation sub-TLV. 1341 Otherwise, the virtual network identifier field of the encapsulation 1342 header is set to a configured value; if there is no configured value, 1343 the tunnel cannot be used. 1345 8.2.2. Labeled Address Families 1347 This sub-section applies when: 1349 o the Tunnel Encapsulation attribute is carried on a BGP UPDATE of a 1350 labeled address family, and 1352 o at least one of the attribute's TLVs identifies a tunnel type that 1353 uses a virtual network identifier, and 1355 o it has been determined to send a packet through one of those 1356 tunnels. 1358 8.2.2.1. When a Valid VNI has been Signaled 1360 If the TLV identifying the tunnel contains an Encapsulation sub-TLV 1361 whose V bit is set, the virtual network identifier field of the 1362 encapsulation header is set as follows: 1364 o If the TLV contains an Embedded Label Handling sub-TLV whose value 1365 is 1, then the virtual network identifier field of the 1366 encapsulation header is set to the value of the virtual network 1367 identifier field of the Encapsulation sub-TLV. 1369 The embedded label (from the NLRI of the route that is carrying 1370 the Tunnel Encapsulation attribute) appears at the top of the MPLS 1371 label stack in the encapsulation payload. 1373 o If the TLV does not contain an Embedded Label Handling sub-TLV, or 1374 if contains an Embedded Label Handling sub-TLV whose value is 2, 1375 the embedded label is ignored entirely, and the virtual network 1376 identifier field of the encapsulation header is set to the value 1377 of the virtual network identifier field of the Encapsulation sub- 1378 TLV. 1380 8.2.2.2. When a Valid VNI has not been Signaled 1382 If the TLV identifying the tunnel does not contain an Encapsulation 1383 sub-TLV whose V bit is set, the virtual network identifier field of 1384 the encapsulation header is set as follows: 1386 o If the TLV contains an Embedded Label Handling sub-TLV whose value 1387 is 1, then the virtual network identifier field of the 1388 encapsulation header is set to a configured value. 1390 If there is no configured value, the tunnel cannot be used. 1392 The embedded label (from the NLRI of the route that is carrying 1393 the Tunnel Encapsulation attribute) appears at the top of the MPLS 1394 label stack in the encapsulation payload. 1396 o If the TLV does not contain an Embedded Label Handling sub-TLV, or 1397 if it contains an Embedded Label Handling sub-TLV whose value is 1398 2, the embedded label is copied into the virtual network 1399 identifier field of the encapsulation header. 1401 The embedded label does not appear in the MPLS label stack of the 1402 payload. 1404 9. Applicability Restrictions 1406 In a given UPDATE of a labeled address family, the label embedded in 1407 the NLRI is generally a label that is meaningful only to the router 1408 whose address appears as the next hop. Certain of the procedures of 1409 Section 8.2.2.1 or Section 8.2.2.2 cause the embedded label to be 1410 carried by a data packet to the router whose address appears in the 1411 Remote Endpoint sub-TLV. If the Remote Endpoint sub-TLV does not 1412 identify the same router that is the next hop, sending the packet 1413 through the tunnel may cause the label to be misinterpreted at the 1414 tunnel's remote endpoint. This may cause misdelivery of the packet. 1416 Therefore the embedded label MUST NOT be carried by a data packet 1417 traveling through a tunnel unless it is known that the label will be 1418 properly interpreted at the tunnel's remote endpoint. How this is 1419 known is outside the scope of this document. 1421 Note that if the Tunnel Encapsulation attribute is attached to a VPN- 1422 IP route [RFC4364], and if Inter-AS "option b" (see section 10 of 1423 [RFC4364] is being used, and if the Remote Endpoint sub-TLV contains 1424 an IP address that is not in same AS as the router receiving the 1425 route, it is very likely that the embedded label has been changed. 1426 Therefore use of the Tunnel Encapsulation attribute in an "Inter-AS 1427 option b" scenario is not supported. 1429 10. Scoping 1431 The Tunnel Encapsulation attribute is defined as a transitive 1432 attribute, so that it may be passed along by BGP speakers that do not 1433 recognize it. However, it is intended that the Tunnel Encapsulation 1434 attribute be used only within a well-defined scope, e.g., within a 1435 set of Autonomous Systems that belong to a single administrative 1436 entity. If the attribute is distributed beyond its intended scope, 1437 packets may be sent through tunnels in a manner that is not intended. 1439 To prevent the Tunnel Encapsulation attribute from being distributed 1440 beyond its intended scope, any BGP speaker that understands the 1441 attribute MUST be able to filter the attribute from incoming BGP 1442 UPDATE messages. When the attribute is filtered from an incoming 1443 UPDATE, the attribute is neither processed nor redistributed. This 1444 filtering SHOULD be possible on a per-BGP-session basis. For each 1445 session, filtering of the attribute on incoming UPDATEs MUST be 1446 enabled by default. 1448 In addition, any BGP speaker that understands the attribute MUST be 1449 able to filter the attribute from outgoing BGP UPDATE messages. This 1450 filtering SHOULD be possible on a per-BGP-session basis. For each 1451 session, filtering of the attribute on outgoing UPDATEs MUST be 1452 enabled by default. 1454 11. Error Handling 1456 The Tunnel Encapsulation attribute is a sequence of TLVs, each of 1457 which is a sequence of sub-TLVs. The final octet of a TLV is 1458 determined by its length field. Similarly, the final octet of a sub- 1459 TLV is determined by its length field. The final octet of a TLV MUST 1460 also be the final octet of its final sub-TLV. If this is not the 1461 case, the TLV MUST be considered to be malformed. A TLV that is 1462 found to be malformed for this reason MUST NOT be processed, and MUST 1463 be stripped from the Tunnel Encapsulation attribute before the 1464 attribute is propagated. Subsequent TLVs in the Tunnel Encapsulation 1465 attribute may still be valid, in which case they MUST be processed 1466 and redistributed normally. 1468 If a Tunnel Encapsulation attribute does not have any valid TLVs, or 1469 it does not have the transitive bit set, the "Attribute Discard" 1470 procedure of [RFC7606] is applied. 1472 If a Tunnel Encapsulation attribute can be parsed correctly, but 1473 contains a TLV whose tunnel type is not recognized by a particular 1474 BGP speaker, that BGP speaker MUST NOT consider the attribute to be 1475 malformed. Rather, the TLV with the unrecognized tunnel type MUST be 1476 ignored, and the BGP speaker MUST interpret the attribute as if that 1477 TLV had not been present. If the route carrying the Tunnel 1478 Encapsulation attribute is propagated with the attribute, the 1479 unrecognized TLV SHOULD remain in the attribute. 1481 If a TLV of a Tunnel Encapsulation attribute contains a sub-TLV that 1482 is not recognized by a particular BGP speaker, the BGP speaker SHOULD 1483 process that TLV as if the unrecognized sub-TLV had not been present. 1484 If the route carrying the Tunnel Encapsulation attribute is 1485 propagated with the attribute, the unrecognized TLV SHOULD remain in 1486 the attribute. 1488 In general, if a TLV contains a sub-TLV that is malformed (e.g., 1489 contains a length field whose value is not legal for that sub-TLV), 1490 the sub-TLV should be treated as if it were an unrecognized sub-TLV. 1491 This document specifies one exception to this rule -- if a TLV 1492 contains a malformed Remote Endpoint sub-TLV (as defined in 1493 Section 3.1, the entire TLV MUST be ignored, and SHOULD be removed 1494 from the Tunnel Encapsulation attribute before the route carrying 1495 that attribute is redistributed. 1497 A TLV that does not contain the Remote Endpoint sub-TLV MUST be 1498 treated as if it contained a malformed Remote Endpoint sub-TLV. 1500 A TLV identifying a particular tunnel type may contain a sub-TLV that 1501 is meaningless for that tunnel type. For example, perhaps the TLV 1502 contains a "UDP Destination Port" sub-TLV, but the identified tunnel 1503 type does not use UDP encapsulation at all. Sub-TLVs of this sort 1504 SHOULD be treated as no-ops. That is, they SHOULD NOT affect the 1505 creation of the encapsulation header. However, the sub-TLV MUST NOT 1506 be considered to be malformed, and MUST NOT be removed from the TLV 1507 before the route carrying the Tunnel Encapsulation attribute is 1508 redistributed. (This allows for the possibility that such sub-TLVs 1509 may be given a meaning, in the context of the specified tunnel type, 1510 in the future.) 1512 There is no significance to the order in which the TLVs occur within 1513 the Tunnel Encapsulation attribute. Multiple TLVs may occur for a 1514 given tunnel type; each such TLV is regarded as describing a 1515 different tunnel. 1517 12. IANA Considerations 1519 12.1. Subsequent Address Family Identifiers 1521 IANA is requested to modify the "Subsequent Address Family 1522 Identifiers" registry to indicate that the Encapsulation SAFI is 1523 deprecated. This document should be the reference. 1525 12.2. BGP Path Attributes 1527 IANA has assigned value 23 from the "BGP Path Attributes" Registry, 1528 to "Tunnel Encapsulation Attribute". IANA is requested to add this 1529 document as a reference. 1531 12.3. Extended Communities 1533 IANA has assigned values from the "Transitive Opaque Extended 1534 Community" type Registry to the "Color Extended Community" (sub-type 1535 0x0b), and to the "Encapsulation Extended Community"(0x030c). IANA 1536 is requested to add this document as a reference for both 1537 assignments. 1539 12.4. BGP Tunnel Encapsulation Attribute Sub-TLVs 1541 IANA is requested to change the registration policy of the "BGP 1542 Tunnel Encapsulation Attribute Sub-TLVs" registry to the following: 1544 o The values 0 and 255 are reserved. 1546 o The values in the range 1-127 are to be allocated using the 1547 "Standards Action" registration procedure. 1549 o The values in the range 128-251 are to be allocated using the 1550 "First Come, First Served" registration procedure. 1552 o The values in the range 252-254 are reserved for experimental use; 1553 IANA shall not allocate values from this range. 1555 IANA is requested to assign a codepoint from the "BGP Tunnel 1556 Encapsulation Attribute Sub-TLVs" registry for "Remote Endpoint", 1557 with this document being the reference. 1559 IANA is requested to assign a codepoint from the "BGP Tunnel 1560 Encapsulation Attribute Sub-TLVs" registry for "IPv4 DS Field", with 1561 this document being the reference. 1563 IANA is requested to assign a codepoint from the "BGP Tunnel 1564 Encapsulation Attribute Sub-TLVs" registry for "UDP Destination 1565 Port", with this document being the reference. 1567 IANA is requested to assign a codepoint from the "BGP Tunnel 1568 Encapsulation Attribute Sub-TLVs" registry for "Embedded Label 1569 Handling", with this document being the reference. 1571 IANA is requested to assign a codepoint from the "BGP Tunnel 1572 Encapsulation Attribute Sub-TLVs" registry for "MPLS Label Stack", 1573 with this document being the reference. 1575 IANA is requested to assign a codepoint from the "BGP Tunnel 1576 Encapsulation Attribute Sub-TLVs" registry for "Prefix SID", with 1577 this document being the reference. 1579 IANA has assigned codepoints from the "BGP Tunnel Encapsulation 1580 Attribute Sub-TLVs" registry for "Encapsulation", "Protocol Type", 1581 and "Color". IANA is requested to add this document as a reference. 1583 12.5. Tunnel Types 1585 IANA is requested to add this document as a reference for tunnel 1586 types 8 (VXLAN), 9 (NVGRE), 11 (MPLS-in-GRE), and 12 (VXLAN-GPE) in 1587 the "BGP Tunnel Encapsulation Tunnel Types" registry. 1589 IANA is requested to assign a codepoint from the "BGP Tunnel 1590 Encapsulation Tunnel Types" registry for "GTP". 1592 IANA is requested to add this document as a reference for tunnel 1593 types 1 (L2TPv3), 2 (GRE), and 7 (IP in IP) in the "BGP Tunnel 1594 Encapsulation Tunnel Types" registry. 1596 13. Security Considerations 1598 The Tunnel Encapsulation attribute can cause traffic to be diverted 1599 from its normal path, especially when the Remote Endpoint sub-TLV is 1600 used. This can have serious consequences if the attribute is added 1601 or modified illegitimately, as it enables traffic to be "hijacked". 1603 The Remote Endpoint sub-TLV contains both an IP address and an AS 1604 number. BGP Origin Validation [RFC6811] can be used to obtain 1605 assurance that the given IP address belongs to the given AS. While 1606 this provides some protection against misconfiguration, it does not 1607 prevent a malicious agent from inserting a sub-TLV that will appear 1608 valid. 1610 Before sending a packet through the tunnel identified in a particular 1611 TLV of a Tunnel Encapsulation attribute, it may be advisable to use 1612 BGP Origin Validation to obtain the following additional assurances: 1614 o the origin AS of the route carrying the Tunnel Encapsulation 1615 attribute is correct; 1617 o the origin AS of the route to the IP address specified in the 1618 Remote Endpoint sub-TLV is correct, and is the same AS that is 1619 specified in the Remote Endpoint sub-TLV. 1621 One then has some level of assurance that the tunneled traffic is 1622 going to the same destination AS that it would have gone to had the 1623 Tunnel Encapsulation attribute not been present. However, this may 1624 not suit all use cases, and in any event is not very strong 1625 protection against hijacking. 1627 For these reasons, BGP Origin Validation should not be relied upon 1628 exclusively, and the filtering procedures of Section 10 should always 1629 be in place. 1631 Increased protection can be obtained by using BGP Path Validation 1632 [BGPSEC] to ensure that the route carrying the Tunnel Encapsulation 1633 attribute, and the routes to the Remote Endpoint of each specified 1634 tunnel, have not been altered illegitimately. 1636 If BGP Origin Validation is used as specified above, and the tunnel 1637 specified in a particular TLV of a Tunnel Encapsulation attribute is 1638 therefore regarded as "suspicious", that tunnel should not be used. 1639 Other tunnels specified in (other TLVs of) the Tunnel Encapsulation 1640 attribute may still be used. 1642 14. Acknowledgments 1644 This document contains text from RFC5512, co-authored by Pradosh 1645 Mohapatra. The authors of the current document wish to thank Pradosh 1646 for his contribution. RFC5512 itself built upon prior work by Gargi 1647 Nalawade, Ruchi Kapoor, Dan Tappan, David Ward, Scott Wainner, Simon 1648 Barber, and Chris Metz, whom we also thank for their contributions. 1650 The authors wish to think Ron Bonica, John Drake, Satoru Matsushima, 1651 Dhananjaya Rao, John Scudder, Ravi Singh, Thomas Morin, Xiaohu Xu, 1652 and Zhaohui Zhang for their review, comments, and/or helpful 1653 discussions. 1655 15. Contributor Addresses 1657 Below is a list of other contributing authors in alphabetical order: 1659 Randy Bush 1660 Internet Initiative Japan 1661 5147 Crystal Springs 1662 Bainbridge Island, Washington 98110 1663 United States 1665 Email: randy@psg.com 1667 Robert Raszuk 1668 Bloomberg LP 1669 731 Lexington Ave 1670 New York City, NY 10022 1671 United States 1673 Email: robert@raszuk.net 1675 16. References 1677 16.1. Normative References 1679 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1680 Requirement Levels", BCP 14, RFC 2119, 1681 DOI 10.17487/RFC2119, March 1997, 1682 . 1684 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 1685 Subsequent Address Family Identifier (SAFI) and the BGP 1686 Tunnel Encapsulation Attribute", RFC 5512, 1687 DOI 10.17487/RFC5512, April 2009, 1688 . 1690 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1691 Patel, "Revised Error Handling for BGP UPDATE Messages", 1692 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1693 . 1695 16.2. Informative References 1697 [BGPSEC] Lepinski, M. and S. Turner, "An Overview of BGPsec", 1698 internet-draft draft-ietf-sidr-bgpsec-overview, June 2015. 1700 [Ethertypes] 1701 "IANA Ethertype Registry", 1702 . 1705 [EVPN-Inter-Subnet] 1706 Sajassi, A., Salem, S., Thoria, S., Rekhter, Y., Drake, 1707 J., Yong, L., Dunbar, L., Henderickx, W., Rabadan, J., 1708 Balus, F., and D. Cai, "Integrated Routing and Bridging in 1709 EVPN", internet-draft draft-ietf-bess-evpn-inter-subnet- 1710 forwarding, October 2015. 1712 [GTP-U] 3GPP, "GPRS Tunneling Protocol User Plane, TS 29.281", 1713 2014. 1715 [Prefix-SID-Attribute] 1716 Previdi, S., Filsfils, C., Lindem, A., Patel, K., 1717 Sreekantiah, A., Ray, S., and H. Gredler, "Segment Routing 1718 Prefix SID extensions for BGP", internet-draft draft-ietf- 1719 idr-bgp-prefix-sid-02, October 2015. 1721 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1722 "Definition of the Differentiated Services Field (DS 1723 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1724 DOI 10.17487/RFC2474, December 1998, 1725 . 1727 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1728 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1729 DOI 10.17487/RFC2784, March 2000, 1730 . 1732 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 1733 RFC 2890, DOI 10.17487/RFC2890, September 2000, 1734 . 1736 [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., 1737 "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", 1738 RFC 3931, DOI 10.17487/RFC3931, March 2005, 1739 . 1741 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 1742 "Encapsulating MPLS in IP or Generic Routing Encapsulation 1743 (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, 1744 . 1746 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1747 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1748 2006, . 1750 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 1751 Encodings and Procedures for Multicast in MPLS/BGP IP 1752 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 1753 . 1755 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 1756 Austein, "BGP Prefix Origin Validation", RFC 6811, 1757 DOI 10.17487/RFC6811, January 2013, 1758 . 1760 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1761 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1762 eXtensible Local Area Network (VXLAN): A Framework for 1763 Overlaying Virtualized Layer 2 Networks over Layer 3 1764 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 1765 . 1767 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 1768 "Encapsulating MPLS in UDP", RFC 7510, 1769 DOI 10.17487/RFC7510, April 2015, 1770 . 1772 [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network 1773 Virtualization Using Generic Routing Encapsulation", 1774 RFC 7637, DOI 10.17487/RFC7637, September 2015, 1775 . 1777 [vEPC] Matsushima, S. and R. Wakikawa, "Stateless User-Plane 1778 Architecture for Virtualized EPC", internet-draft draft- 1779 matsushima-stateless-uplane-vepc-04, March 2015. 1781 [VXLAN-GPE] 1782 Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., 1783 Smith, M., Agarwal, P., Xu, X., Elzur, U., Garg, P., 1784 Melman, D., and R. Manur, "Generic Protocol Extension for 1785 VXLAN", internet-draft draft-ietf-nvo3-vxlan-gpe, May 1786 2015. 1788 Authors' Addresses 1790 Eric C. Rosen (editor) 1791 Juniper Networks, Inc. 1792 10 Technology Park Drive 1793 Westford, Massachusetts 01886 1794 United States 1796 Email: erosen@juniper.net 1798 Keyur Patel 1799 Cisco Systems 1800 170 W. Tasman Drive 1801 San Jose, CA 95134 1802 United States 1804 Email: keyupate@cisco.com 1806 Gunter Van de Velde 1807 Alcatel-Lucent 1808 Copernicuslaan 50 1809 Antwerpen 2018 1810 Belgium 1812 Email: gunter.van_de_velde@alcatel-lucent.com