idnits 2.17.1 draft-ietf-idr-tunnel-encaps-18.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- 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 (September 11, 2020) is 1316 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) == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-10 ** Downref: Normative reference to an Informational draft: draft-ietf-nvo3-vxlan-gpe (ref. 'I-D.ietf-nvo3-vxlan-gpe') ** 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-10 -- 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: 3 errors (**), 0 flaws (~~), 4 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: March 15, 2021 J. Scudder 8 Juniper Networks 9 September 11, 2020 11 The BGP Tunnel Encapsulation Attribute 12 draft-ietf-idr-tunnel-encaps-18 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 March 15, 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 2. The Tunnel Encapsulation Attribute . . . . . . . . . . . . . 7 76 3. Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . . . . . 9 77 3.1. The Tunnel Egress Endpoint Sub-TLV . . . . . . . . . . . 9 78 3.1.1. Validating the Address Field . . . . . . . . . . . . 11 79 3.2. Encapsulation Sub-TLVs for Particular Tunnel Types . . . 12 80 3.2.1. VXLAN . . . . . . . . . . . . . . . . . . . . . . . . 12 81 3.2.2. VXLAN GPE . . . . . . . . . . . . . . . . . . . . . . 14 82 3.2.3. NVGRE . . . . . . . . . . . . . . . . . . . . . . . . 15 83 3.2.4. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . 16 84 3.2.5. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 3.2.6. MPLS-in-GRE . . . . . . . . . . . . . . . . . . . . . 17 86 3.3. Outer Encapsulation Sub-TLVs . . . . . . . . . . . . . . 18 87 3.3.1. DS Field . . . . . . . . . . . . . . . . . . . . . . 18 88 3.3.2. UDP Destination Port . . . . . . . . . . . . . . . . 18 89 3.4. Sub-TLVs for Aiding Tunnel Selection . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . 22 95 4. Extended Communities Related to the Tunnel Encapsulation 96 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 23 97 4.1. Encapsulation Extended Community . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . . . 28 103 7.1. Impact on the BGP Decision Process . . . . . . . . . . . 28 104 7.2. Looping, Mutual Recursion, Etc. . . . . . . . . . . . . . 29 105 8. Recursive Next Hop Resolution . . . . . . . . . . . . . . . . 29 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 . 30 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 114 12. Validation and Error Handling . . . . . . . . . . . . . . . . 34 115 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 116 13.1. Obsoleting Code Points Assigned by RFCs 5566 and 5640 . 36 117 13.2. BGP Tunnel Encapsulation Parameters Grouping . . . . . . 36 118 13.3. Subsequent Address Family Identifiers . . . . . . . . . 36 119 13.4. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . 36 120 13.5. Flags Field of VXLAN Encapsulation sub-TLV . . . . . . . 37 121 13.6. Flags Field of VXLAN GPE Encapsulation sub-TLV . . . . . 38 122 13.7. Flags Field of NVGRE Encapsulation sub-TLV . . . . . . . 38 123 13.8. Embedded Label Handling sub-TLV . . . . . . . . . . . . 38 124 13.9. Color Extended Community Flags . . . . . . . . . . . . . 39 125 14. Security Considerations . . . . . . . . . . . . . . . . . . . 39 126 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 127 16. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 40 128 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 129 17.1. Normative References . . . . . . . . . . . . . . . . . . 41 130 17.2. Informative References . . . . . . . . . . . . . . . . . 43 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 133 1. Introduction 135 This document obsoletes RFC 5512. The deficiencies of RFC 5512, and 136 a summary of the changes made, are discussed in Sections 1.1-1.3. 137 The material from RFC 5512 that is retained has been incorporated 138 into this document. Since [RFC5566] and [RFC5640] rely on RFC 5512, 139 they are likewise obsoleted. 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in BCP 144 14 [RFC2119] [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 1.1. Brief Summary of RFC 5512 149 [RFC5512] defines a BGP Path Attribute known as the Tunnel 150 Encapsulation attribute. This attribute consists of one or more 151 TLVs. Each TLV identifies a particular type of tunnel. Each TLV 152 also contains one or more sub-TLVs. Some of the sub-TLVs, e.g., the 153 "Encapsulation sub-TLV", contain information that may be used to form 154 the encapsulation header for the specified Tunnel Type. Other sub- 155 TLVs, e.g., the "color sub-TLV" and the "protocol sub-TLV", contain 156 information that aids in determining whether particular packets 157 should be sent through the tunnel that the TLV identifies. 159 [RFC5512] only allows the Tunnel Encapsulation attribute to be 160 attached to BGP UPDATE messages of the Encapsulation Address Family. 161 These UPDATE messages have an AFI (Address Family Identifier) of 1 or 162 2, and a SAFI of 7. In an UPDATE of the Encapsulation SAFI, the NLRI 163 (Network Layer Reachability Information) is an address of the BGP 164 speaker originating the UPDATE. Consider the following scenario: 166 o BGP speaker R1 has received and selected UPDATE U for local use; 168 o UPDATE U's SAFI is the Encapsulation SAFI; 170 o UPDATE U has the address R2 as its NLRI; 172 o UPDATE U has a Tunnel Encapsulation attribute. 174 o R1 has a packet, P, to transmit to destination D; 176 o R1's best route to D is a BGP route that has R2 as its next hop; 178 In this scenario, when R1 transmits packet P, it should transmit it 179 to R2 through one of the tunnels specified in U's Tunnel 180 Encapsulation attribute. The IP address of the tunnel egress 181 endpoint of each such tunnel is R2. Packet P is known as the 182 tunnel's "payload". 184 1.2. Deficiencies in RFC 5512 186 While the ability to specify tunnel information in a BGP UPDATE is 187 useful, the procedures of [RFC5512] have certain limitations: 189 o The requirement to use the "Encapsulation SAFI" presents an 190 unfortunate operational cost, as each BGP session that may need to 191 carry tunnel encapsulation information needs to be reconfigured to 192 support the Encapsulation SAFI. The Encapsulation SAFI has never 193 been used, and this requirement has served only to discourage the 194 use of the Tunnel Encapsulation attribute. 196 o There is no way to use the Tunnel Encapsulation attribute to 197 specify the tunnel egress endpoint address of a given tunnel; 198 [RFC5512] assumes that the tunnel egress endpoint of each tunnel 199 is specified as the NLRI of an UPDATE of the Encapsulation SAFI. 201 o If the respective best routes to two different address prefixes 202 have the same next hop, [RFC5512] does not provide a 203 straightforward method to associate each prefix with a different 204 tunnel. 206 o If a particular Tunnel Type requires an outer IP or UDP 207 encapsulation, there is no way to signal the values of any of the 208 fields of the outer encapsulation. 210 o In [RFC5512]'s specification of the sub-TLVs, each sub-TLV has 211 one-octet length field. In some cases, a two-octet length field 212 may be needed. 214 1.3. Use Case for The Tunnel Encapsulation Attribute 216 Consider the case of a router R1 forwarding an IP packet P. Let D be 217 P's IP destination address. R1 must look up D in its forwarding 218 table. Suppose that the "best match" route for D is route Q, where Q 219 is a BGP-distributed route whose "BGP next hop" is router R2. And 220 suppose further that the routers along the path from R1 to R2 have 221 entries for R2 in their forwarding tables, but do NOT have entries 222 for D in their forwarding tables. For example, the path from R1 to 223 R2 may be part of a "BGP-free core", where there are no BGP- 224 distributed routes at all in the core. Or, as in [RFC5565], D may be 225 an IPv4 address while the intermediate routers along the path from R1 226 to R2 may support only IPv6. 228 In cases such as this, in order for R1 to properly forward packet P, 229 it must encapsulate P and send P "through a tunnel" to R2. For 230 example, R1 may encapsulate P using GRE, L2TPv3, IP in IP, etc., 231 where the destination IP address of the encapsulation header is the 232 address of R2. 234 In order for R1 to encapsulate P for transport to R2, R1 must know 235 what encapsulation protocol to use for transporting different sorts 236 of packets to R2. R1 must also know how to fill in the various 237 fields of the encapsulation header. With certain encapsulation 238 types, this knowledge may be acquired by default or through manual 239 configuration. Other encapsulation protocols have fields such as 240 session id, key, or cookie that must be filled in. It would not be 241 desirable to require every BGP speaker to be manually configured with 242 the encapsulation information for every one of its BGP next hops. 244 This document specifies a way in which BGP itself can be used by a 245 given BGP speaker to tell other BGP speakers, "if you need to 246 encapsulate packets to be sent to me, here's the information you need 247 to properly form the encapsulation header". A BGP speaker signals 248 this information to other BGP speakers by using a new BGP attribute 249 type value, the BGP Tunnel Encapsulation Attribute. This attribute 250 specifies the encapsulation protocols that may be used as well as 251 whatever additional information (if any) is needed in order to 252 properly use those protocols. Other attributes, e.g., communities or 253 extended communities, may also be included. 255 1.4. Brief Summary of Changes from RFC 5512 257 This document addresses these deficiencies by: 259 o Deprecating the Encapsulation SAFI. 261 o Defining a new "Tunnel Egress Endpoint sub-TLV" (Section 3.1) that 262 can be included in any of the TLVs contained in the Tunnel 263 Encapsulation attribute. This sub-TLV can be used to specify the 264 remote endpoint address of a particular tunnel. 266 o Allowing the Tunnel Encapsulation attribute to be carried by BGP 267 UPDATEs of additional AFI/SAFIs. Appropriate semantics are 268 provided for this way of using the attribute. 270 o Defining a number of new sub-TLVs that provide additional 271 information that is useful when forming the encapsulation header 272 used to send a packet through a particular tunnel. 274 o Defining the sub-TLV type field so that a sub-TLV whose type is in 275 the range from 0 to 127 inclusive has a one-octet length field, 276 but a sub-TLV whose type is in the range from 128 to 255 inclusive 277 has a two-octet length field. 279 One of the sub-TLVs defined in [RFC5512] is the "Encapsulation sub- 280 TLV". For a given tunnel, the Encapsulation sub-TLV specifies some 281 of the information needed to construct the encapsulation header used 282 when sending packets through that tunnel. This document defines 283 Encapsulation sub-TLVs for a number of tunnel types not discussed in 284 [RFC5512]: VXLAN (Virtual Extensible Local Area Network, [RFC7348]), 285 VXLAN GPE (Generic Protocol Extension for VXLAN, 286 [I-D.ietf-nvo3-vxlan-gpe]), NVGRE (Network Virtualization Using 287 Generic Routing Encapsulation [RFC7637]), and MPLS-in-GRE (MPLS in 288 Generic Routing Encapsulation [RFC4023]). MPLS-in-UDP [RFC7510] is 289 also supported, but an Encapsulation sub-TLV for it is not needed. 291 Some of the encapsulations mentioned in the previous paragraph need 292 to be further encapsulated inside UDP and/or IP. [RFC5512] provides 293 no way to specify that certain information is to appear in these 294 outer IP and/or UDP encapsulations. This document provides a 295 framework for including such information in the TLVs of the Tunnel 296 Encapsulation attribute. 298 When the Tunnel Encapsulation attribute is attached to a BGP UPDATE 299 whose AFI/SAFI identifies one of the labeled address families, it is 300 not always obvious whether the label embedded in the NLRI is to 301 appear somewhere in the tunnel encapsulation header (and if so, 302 where), or whether it is to appear in the payload, or whether it can 303 be omitted altogether. This is especially true if the tunnel 304 encapsulation header itself contains a "virtual network identifier". 305 This document provides a mechanism that allows one to signal (by 306 using sub-TLVs of the Tunnel Encapsulation attribute) how one wants 307 to use the embedded label when the tunnel encapsulation has its own 308 virtual network identifier field. 310 [RFC5512] defines a Tunnel Encapsulation Extended Community that can 311 be used instead of the Tunnel Encapsulation attribute under certain 312 circumstances. This document describes (Section 4.1) how the Tunnel 313 Encapsulation Extended Community can be used in a backwards- 314 compatible fashion. It is possible to combine Tunnel Encapsulation 315 Extended Communities and Tunnel Encapsulation attributes in the same 316 BGP UPDATE in this manner. 318 2. The Tunnel Encapsulation Attribute 320 The Tunnel Encapsulation attribute is an optional transitive BGP Path 321 attribute. IANA has assigned the value 23 as the type code of the 322 attribute. The attribute is composed of a set of Type-Length-Value 323 (TLV) encodings. Each TLV contains information corresponding to a 324 particular Tunnel Type. A Tunnel Encapsulation TLV, also known as 325 Tunnel TLV, is structured as shown in Figure 1: 327 0 1 2 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Tunnel Type (2 Octets) | Length (2 Octets) | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | | 333 | Value | 334 | | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Figure 1: Tunnel Encapsulation TLV Value Field 339 o Tunnel Type (2 octets): identifies a type of tunnel. The field 340 contains values from the IANA Registry "BGP Tunnel Encapsulation 341 Attribute Tunnel Types". See Section 3.4.1 for discussion of 342 special treatment of tunnel types with names of the form "X-in-Y". 344 o Length (2 octets): the total number of octets of the value field. 346 o Value (variable): comprised of multiple sub-TLVs. 348 Each sub-TLV consists of three fields: a 1-octet type, a 1-octet or 349 2-octet length field (depending on the type), and zero or more octets 350 of value. A sub-TLV is structured as shown in Figure 2: 352 +--------------------------------+ 353 | Sub-TLV Type (1 Octet) | 354 +--------------------------------+ 355 | Sub-TLV Length (1 or 2 Octets) | 356 +--------------------------------+ 357 | Sub-TLV Value (Variable) | 358 +--------------------------------+ 360 Figure 2: Encapsulation Sub-TLV Value Field 362 o Sub-TLV Type (1 octet): each sub-TLV type defines a certain 363 property about the Tunnel TLV that contains this sub-TLV. The 364 field contains values from the IANA Registry "BGP Tunnel 365 Encapsulation Attribute Sub-TLVs". 367 o Sub-TLV Length (1 or 2 octets): the total number of octets of the 368 sub-TLV value field. The Sub-TLV Length field contains 1 octet if 369 the Sub-TLV Type field contains a value in the range from 0-127. 370 The Sub-TLV Length field contains two octets if the Sub-TLV Type 371 field contains a value in the range from 128-255. 373 o Sub-TLV Value (variable): encodings of the value field depend on 374 the sub-TLV type as enumerated above. The following sub-sections 375 define the encoding in detail. 377 3. Tunnel Encapsulation Attribute Sub-TLVs 379 This section specifies a number of sub-TLVs. These sub-TLVs can be 380 included in a TLV of the Tunnel Encapsulation attribute. 382 3.1. The Tunnel Egress Endpoint Sub-TLV 384 The Tunnel Egress Endpoint sub-TLV, whose value is 6, specifies the 385 address of the egress endpoint of the tunnel, that is, the address of 386 the router that will decapsulate the payload. Its value field 387 contains three subfields: 389 1. a reserved subfield 391 2. a two-octet Address Family subfield 393 3. an Address subfield, whose length depends upon the Address 394 Family. 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Reserved | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Address Family | Address ~ 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 403 ~ ~ 404 | | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 Figure 3: Tunnel Egress Endpoint Sub-TLV Value Field 409 The Reserved subfield SHOULD be originated as zero. It MUST be 410 disregarded on receipt, and it MUST be propagated unchanged. 412 The Address Family subfield contains a value from IANA's "Address 413 Family Numbers" registry. This document assumes that the Address 414 Family is either IPv4 or IPv6; use of other address families is 415 outside the scope of this document. 417 If the Address Family subfield contains the value for IPv4, the 418 address subfield MUST contain an IPv4 address (a /32 IPv4 prefix). 420 If the Address Family subfield contains the value for IPv6, the 421 address subfield MUST contain an IPv6 address (a /128 IPv6 prefix). 423 In a given BGP UPDATE, the address family (IPv4 or IPv6) of a Tunnel 424 Egress Endpoint sub-TLV is independent of the address family of the 425 UPDATE itself. For example, an UPDATE whose NLRI is an IPv4 address 426 may have a Tunnel Encapsulation attribute containing Tunnel Egress 427 Endpoint sub-TLVs that contain IPv6 addresses. Also, different 428 tunnels represented in the Tunnel Encapsulation attribute may have 429 tunnel egress endpoints of different address families. 431 There is one special case: the Tunnel Egress Endpoint sub-TLV MAY 432 have a value field whose Address Family subfield contains 0. This 433 means that the tunnel's egress endpoint is the address of the next 434 hop. If the Address Family subfield contains 0, the Address subfield 435 is omitted. In this case, the length field of Tunnel Egress Endpoint 436 sub-TLV MUST contain the value 6 (0x06). 438 When the Tunnel Encapsulation attribute is carried in an UPDATE 439 message of one of the AFI/SAFIs specified above, each TLV MUST have 440 one, and one only, Tunnel Egress Endpoint sub-TLV. If a TLV does not 441 have a Tunnel Egress Endpoint sub-TLV, that TLV should be treated as 442 if it had a malformed Tunnel Egress Endpoint sub-TLV (see below). 444 If the Address Family subfield has any value other than IPv4 or IPv6, 445 the Tunnel Egress Endpoint sub-TLV is considered "unrecognized" (see 446 Section 12). If any of the following conditions hold, the Tunnel 447 Egress Endpoint sub-TLV is considered to be "malformed": 449 o The length of the sub-TLV's Value field is other than 6 plus the 450 defined length for the address family given in its Address Family 451 subfield. Therefore, for address family behaviors defined in this 452 document, the permitted values are: 454 * 10, if the Address Family subfield contains the value for IPv4. 456 * 22, if the Address Family subfield contains the value for IPv6. 458 * 6, if the Address Family subfield contains the value zero. 460 o The IP address in the sub-TLV's address subfield lies within a 461 block listed in the relevant Special-Purpose IP Address Registry 462 [RFC6890] with either a "destination" attribute value or a 463 "forwardable" attribute value of "false". (Such routes are 464 sometimes colloquially known as "Martians".) 466 o It can be determined according to the procedures below 467 (Section 3.1.1) that the IP address in the sub-TLV's address 468 subfield does not belong to the Autonomous System (AS) that 469 originated the route that contains the attribute. 471 Error Handling is detailed in Section 12. 473 If the Tunnel Egress Endpoint sub-TLV contains an IPv4 or IPv6 474 address that is valid but not reachable, the sub-TLV is not 475 considered to be malformed. 477 3.1.1. Validating the Address Field 479 This section details a procedure that MAY be applied to validate that 480 the IP address in the sub-TLV's address subfield belongs to the AS 481 that originated the route that contains the attribute. (The notion 482 of "belonging to" an AS is expanded on below.) Doing this is thought 483 to increase confidence that when traffic is sent to the IP address 484 depicted in the Address Field, it will go to the same AS as it would 485 go to if the Tunnel Encapsulation Attribute were not present, 486 although of course it cannot guarantee it. See Section 14 for 487 discussion of the limitations of this procedure. 489 The Route Origin ASN (Autonomous System Number) of a BGP route that 490 includes a Tunnel Encapsulation Attribute can be determined by 491 inspection of the AS_PATH attribute, according to the procedure 492 specified in [RFC6811] Section 2. Call this value Route_AS. 494 In order to determine the Route Origin ASN of the address depicted in 495 the Address Field of the Tunnel Egress Endpoint sub-TLV, it is 496 necessary to consider the forwarding route, that is, the route that 497 will be used to forward traffic toward that address. This route is 498 determined by a recursive route lookup operation for that address, as 499 discussed in [RFC4271] Section 5.1.3. The relevant AS Path to 500 consider is the last one encountered while performing the recursive 501 lookup; the procedures of RFC6811 Section 2 are applied to that AS 502 Path to determine the Route Origin ASN. If no AS Path is encountered 503 at all, for example if that route's source is a protocol other than 504 BGP, the Route Origin ASN is the BGP speaker's own AS number. Call 505 this value Egress_AS. 507 If Route_AS does not equal Egress_AS, then the Tunnel Egress Endpoint 508 sub-TLV is considered not to be valid. In some cases a network 509 operator who controls a set of Autonomous Systems might wish to allow 510 a Tunnel Egress Endpoint to reside in an AS other than Route_AS; 511 configuration MAY allow for such a case, in which case the check 512 becomes, if Egress_AS is not within the configured set of permitted 513 AS numbers, then the Tunnel Egress Endpoint sub-TLV is considered to 514 be "malformed". 516 Note that if the forwarding route changes, this procedure MUST be 517 reapplied. As a result, a sub-TLV that was formerly considered valid 518 might become not valid, or vice-versa. 520 3.2. Encapsulation Sub-TLVs for Particular Tunnel Types 522 This section defines Encapsulation sub-TLVs for the following tunnel 523 types: VXLAN ([RFC7348]), VXLAN GPE ([I-D.ietf-nvo3-vxlan-gpe]), 524 NVGRE ([RFC7637]), MPLS-in-GRE ([RFC4023]), L2TPv3 ([RFC3931]), and 525 GRE ([RFC2784]). 527 Rules for forming the encapsulation based on the information in a 528 given TLV are given in Section 6 and Section 9 530 Recall that the Tunnel Type itself is identified by the Tunnel Type 531 field in the attribute header (Section 2); the Encapsulation sub- 532 TLV's structure is inferred from this. Regardless of the Tunnel 533 Type, the sub-TLV type of the Encapsulation sub-TLV is 1. There are 534 also tunnel types for which it is not necessary to define an 535 Encapsulation sub-TLV, because there are no fields in the 536 encapsulation header whose values need to be signaled from the tunnel 537 egress endpoint. 539 3.2.1. VXLAN 541 This document defines an Encapsulation sub-TLV for VXLAN tunnels. 542 When the Tunnel Type is VXLAN (value 8), the length of the sub-TLV is 543 12 octets. The following is the structure of the value field in the 544 Encapsulation sub-TLV: 546 0 1 2 3 547 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 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 |V|M|R|R|R|R|R|R| VN-ID (3 Octets) | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | MAC Address (4 Octets) | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | MAC Address (2 Octets) | Reserved | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 Figure 4: VXLAN Encapsulation Sub-TLV 558 V: This bit is set to 1 to indicate that a VN-ID (Virtual Network 559 Identifier) is present in the Encapsulation sub-TLV. If set to 0, 560 the VN-ID field is disregarded. Please see Section 9. 562 M: This bit is set to 1 to indicate that a MAC Address is present 563 in the Encapsulation sub-TLV. If set to 0, the MAC Address field 564 is disregarded. 566 R: The remaining bits in the 8-bit flags field are reserved for 567 further use. They MUST always be set to 0 by the originator of 568 the sub-TLV. Intermediate routers MUST propagate them without 569 modification. Any receiving routers MUST ignore these bits upon a 570 receipt of the sub-TLV. 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 MUST be set to 574 zero on transmission and disregarded on receipt. 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 MUST be 578 set to all zeroes on transmission and disregarded on receipt. 580 Reserved: MUST be set to zero on transmission and disregarded on 581 receipt. 583 When forming the VXLAN encapsulation header: 585 o The values of the V, M, and R bits are NOT copied into the flags 586 field of the VXLAN header. The flags field of the VXLAN header is 587 set as per [RFC7348]. 589 o If the M bit is set, the MAC Address is copied into the Inner 590 Destination MAC Address field of the Inner Ethernet Header (see 591 section 5 of [RFC7348]). 593 If the M bit is not set, and the payload being sent through the 594 VXLAN tunnel is an Ethernet frame, the Destination MAC Address 595 field of the Inner Ethernet Header is just the Destination MAC 596 Address field of the payload's Ethernet header. 598 If the M bit is not set, and the payload being sent through the 599 VXLAN tunnel is an IP or MPLS packet, the Inner Destination MAC 600 address field is set to a configured value; if there is no 601 configured value, the VXLAN tunnel cannot be used. 603 o If the V bit is not set, and the BGP UPDATE message has AFI/SAFI 604 other than Ethernet VPNs (EVPN) then the VXLAN tunnel cannot be 605 used. 607 o Section 9 describes how the VNI field of the VXLAN encapsulation 608 header is set. 610 Note that in order to send an IP packet or an MPLS packet through a 611 VXLAN tunnel, the packet must first be encapsulated in an Ethernet 612 header, which becomes the "inner Ethernet header" described in 613 [RFC7348]. The VXLAN Encapsulation sub-TLV may contain information 614 (e.g.,the MAC address) that is used to form this Ethernet header. 616 3.2.2. VXLAN GPE 618 This document defines an Encapsulation sub-TLV for VXLAN GPE tunnels. 619 When the Tunnel Type is VXLAN GPE (value 12), the length of the sub- 620 TLV is 8 octets and following is the structure of the value field in 621 the Encapsulation sub-TLV: 623 0 1 2 3 624 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 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 |Ver|V|R|R|R|R|R| Reserved | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | VN-ID | Reserved | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 Figure 5: VXLAN GPE Encapsulation Sub-TLV 633 Version (Ver): Indicates VXLAN GPE protocol version. (See the 634 "Version Bits" section of [I-D.ietf-nvo3-vxlan-gpe].) If the 635 indicated version is not supported, the TLV that contains this 636 Encapsulation sub-TLV MUST be treated as specifying an unsupported 637 Tunnel Type. The value of this field will be copied into the 638 corresponding field of the VXLAN encapsulation header. 640 V: This bit is set to 1 to indicate that a VN-ID is present in the 641 Encapsulation sub-TLV. If set to 0, the VN-ID field is 642 disregarded. Please see Section 9. 644 R: The bits designated "R" above are reserved for future use. 645 They MUST always be set to 0 by the originator of the sub-TLV. 646 Intermediate routers MUST propagate them without modification. 647 Any receiving routers MUST ignore these bits upon a receipt. 649 VN-ID: If the V bit is set, this field contains a 3 octet VN-ID 650 value. If the V bit is not set, this field MUST be set to zero on 651 transmission and disregarded on receipt. 653 Reserved (two fields): MUST be set to zero on transmission and 654 disregarded on receipt. 656 When forming the VXLAN GPE encapsulation header: 658 o The values of the V and R bits are NOT copied into the flags field 659 of the VXLAN GPE header. However, the values of the Ver bits are 660 copied into the VXLAN GPE header. Other bits in the flags field 661 of the VXLAN GPE header are set as per [I-D.ietf-nvo3-vxlan-gpe]. 663 o Section 9 describes how the VNI field of the VXLAN GPE 664 encapsulation header is set. 666 3.2.3. NVGRE 668 This document defines an Encapsulation sub-TLV for NVGRE tunnels. 669 When the Tunnel Type is NVGRE (value 9), the length of the sub-TLV is 670 12 octets. The following is the structure of the value field in the 671 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 |V|M|R|R|R|R|R|R| VN-ID (3 Octets) | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | MAC Address (4 Octets) | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | MAC Address (2 Octets) | Reserved | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 Figure 6: NVGRE Encapsulation Sub-TLV 685 V: This bit is set to 1 to indicate that a VN-ID is present in the 686 Encapsulation sub-TLV. If set to 0, the VN-ID field is 687 disregarded. Please see Section 9. 689 M: This bit is set to 1 to indicate that a MAC Address is present 690 in the Encapsulation sub-TLV. If set to 0, the MAC Address field 691 is disregarded. 693 R: The remaining bits in the 8-bit flags field are reserved for 694 further use. They MUST always be set to 0 by the originator of 695 the sub-TLV. Intermediate routers MUST propagate them without 696 modification. Any receiving routers MUST ignore these bits upon 697 receipt. 699 VN-ID: If the V bit is set, the VN-ID field contains a 3 octet VN- 700 ID value. If the V bit is not set, the VN-ID field MUST be set to 701 zero on transmission and disregarded on receipt. 703 MAC Address: If the M bit is set, this field contains a 6 octet 704 Ethernet MAC address. If the M bit is not set, this field MUST be 705 set to all zeroes on transmission and disregarded on receipt. 707 Reserved (two fields): MUST be set to zero on transmission and 708 disregarded on receipt. 710 When forming the NVGRE encapsulation header: 712 o The values of the V, M, and R bits are NOT copied into the flags 713 field of the NVGRE header. The flags field of the VXLAN header is 714 set as per [RFC7637]. 716 o If the M bit is set, the MAC Address is copied into the Inner 717 Destination MAC Address field of the Inner Ethernet Header (see 718 section 3.2 of [RFC7637]). 720 If the M bit is not set, and the payload being sent through the 721 NVGRE tunnel is an Ethernet frame, the Destination MAC Address 722 field of the Inner Ethernet Header is just the Destination MAC 723 Address field of the payload's Ethernet header. 725 If the M bit is not set, and the payload being sent through the 726 NVGRE tunnel is an IP or MPLS packet, the Inner Destination MAC 727 address field is set to a configured value; if there is no 728 configured value, the NVGRE tunnel cannot be used. 730 o If the V bit is not set, and the BGP UPDATE message has AFI/SAFI 731 other than Ethernet VPNs (EVPN) then the NVGRE tunnel cannot be 732 used. 734 o Section 9 describes how the VSID (Virtual Subnet Identifier) field 735 of the NVGRE encapsulation header is set. 737 3.2.4. L2TPv3 739 When the Tunnel Type of the TLV is L2TPv3 over IP (value 1), the 740 length of the sub-TLV is between 4 and 12 octets, depending on the 741 length of the cookie. The following is the structure of the value 742 field of the Encapsulation sub-TLV: 744 0 1 2 3 745 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 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Session ID (4 octets) | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | | 750 | Cookie (Variable) | 751 | | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 Figure 7: L2TPv3 Encapsulation Sub-TLV 756 Session ID: a non-zero 4-octet value locally assigned by the 757 advertising router that serves as a lookup key for the incoming 758 packet's context. 760 Cookie: an optional, variable length (encoded in octets -- 0 to 8 761 octets) value used by L2TPv3 to check the association of a 762 received data message with the session identified by the Session 763 ID. Generation and usage of the cookie value is as specified in 764 [RFC3931]. 766 The length of the cookie is not encoded explicitly, but can be 767 calculated as (sub-TLV length - 4). 769 3.2.5. GRE 771 When the Tunnel Type of the TLV is GRE (value 2), the length of the 772 sub-TLV is 4 octets. The following is the structure of the value 773 field of the Encapsulation sub-TLV: 775 0 1 2 3 776 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 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | GRE Key (4 octets) | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 Figure 8: GRE Encapsulation Sub-TLV 783 GRE Key: 4-octet field [RFC2890] that is generated by the 784 advertising router. Note that the key is optional. Unless a key 785 value is being advertised, the GRE Encapsulation sub-TLV MUST NOT 786 be present. 788 3.2.6. MPLS-in-GRE 790 When the Tunnel Type is MPLS-in-GRE (value 11), the length of the 791 sub-TLV is 4 octets. The following is the structure of the value 792 field of the Encapsulation sub-TLV: 794 0 1 2 3 795 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 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | GRE-Key (4 Octets) | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 Figure 9: MPLS-in-GRE Encapsulation Sub-TLV 802 GRE-Key: 4-octet field [RFC2890] that is generated by the 803 advertising router. Note that the key is optional. Unless a key 804 value is being advertised, the MPLS-in-GRE Encapsulation sub-TLV 805 MUST NOT be present. 807 Note that the GRE Tunnel Type defined in Section 3.2.5 can be used 808 instead of the MPLS-in-GRE Tunnel Type when it is necessary to 809 encapsulate MPLS in GRE. Including a TLV of the MPLS-in-GRE tunnel 810 type is equivalent to including a TLV of the GRE Tunnel Type that 811 also includes a Protocol Type sub-TLV (Section 3.4.1) specifying MPLS 812 as the protocol to be encapsulated. 814 While it is not really necessary to have both the GRE and MPLS-in-GRE 815 tunnel types, both are included for reasons of backwards 816 compatibility. 818 3.3. Outer Encapsulation Sub-TLVs 820 The Encapsulation sub-TLV for a particular Tunnel Type allows one to 821 specify the values that are to be placed in certain fields of the 822 encapsulation header for that Tunnel Type. However, some tunnel 823 types require an outer IP encapsulation, and some also require an 824 outer UDP encapsulation. The Encapsulation sub-TLV for a given 825 Tunnel Type does not usually provide a way to specify values for 826 fields of the outer IP and/or UDP encapsulations. If it is necessary 827 to specify values for fields of the outer encapsulation, additional 828 sub-TLVs must be used. This document defines two such sub-TLVs. 830 If an outer Encapsulation sub-TLV occurs in a TLV for a Tunnel Type 831 that does not use the corresponding outer encapsulation, the sub-TLV 832 MUST be treated as if it were an unknown type of sub-TLV. 834 3.3.1. DS Field 836 Most of the tunnel types that can be specified in the Tunnel 837 Encapsulation attribute require an outer IP encapsulation. The 838 Differentiated Services (DS) Field sub-TLV, whose type code is 7, can 839 be carried in the TLV of any such Tunnel Type. It specifies the 840 setting of the one-octet Differentiated Services field in the outer 841 IPv4 or IPv6 encapsulation (see [RFC2474]). The value field is 842 always a single octet. 844 3.3.2. UDP Destination Port 846 Some of the tunnel types that can be specified in the Tunnel 847 Encapsulation attribute require an outer UDP encapsulation. 848 Generally there is a standard UDP Destination Port value for a 849 particular Tunnel Type. However, sometimes it is useful to be able 850 to use a non-standard UDP destination port. If a particular tunnel 851 type requires an outer UDP encapsulation, and it is desired to use a 852 UDP destination port other than the standard one, the port to be used 853 can be specified by including a UDP Destination Port sub-TLV, whose 854 type code is 8. The value field of this sub-TLV is always a two- 855 octet field, containing the port value. 857 3.4. Sub-TLVs for Aiding Tunnel Selection 859 3.4.1. Protocol Type Sub-TLV 861 The Protocol Type sub-TLV, whose type code is 2, MAY be included in a 862 given TLV to indicate the type of the payload packets that are 863 allowed to be encapsulated with the tunnel parameters that are being 864 signaled in the TLV. Packets with other payload types MUST NOT be 865 encapsulated in the relevant tunnel. The value field of the sub-TLV 866 contains a 2-octet value from IANA's "ETHER TYPES" registry 867 [Ethertypes]. 869 For example, if there are three L2TPv3 sessions, one carrying IPv4 870 packets, one carrying IPv6 packets, and one carrying MPLS packets, 871 the egress router will include three TLVs of L2TPv3 encapsulation 872 type, each specifying a different Session ID and a different payload 873 type. The Protocol Type sub-TLV for these will be IPv4 (protocol 874 type = 0x0800), IPv6 (protocol type = 0x86dd), and MPLS (protocol 875 type = 0x8847), respectively. This informs the ingress routers of 876 the appropriate encapsulation information to use with each of the 877 given protocol types. Insertion of the specified Session ID at the 878 ingress routers allows the egress to process the incoming packets 879 correctly, according to their protocol type. 881 Note that for tunnel types whose names are of the form "X-in-Y", 882 e.g., "MPLS-in-GRE", only packets of the specified payload type "X" 883 are to be carried through the tunnel of type "Y". This is the 884 equivalent of specifying a Tunnel Type "Y" and including in its TLV a 885 Protocol Type sub-TLV (see Section 3.4.1) specifying protocol "X". 886 If the Tunnel Type is "X-in-Y", it is unnecessary, though harmless, 887 to explicitly include a Protocol Type sub-TLV specifying "X". Also, 888 for "X-in-Y" type tunnels, a Protocol Type sub-TLV specifying 889 anything other than "X" MUST be ignored; this is discussed further in 890 Section 12. 892 3.4.2. Color Sub-TLV 894 The Color sub-TLV, whose type code is 4, MAY be used as a way to 895 "color" the corresponding Tunnel TLV. The value field of the sub-TLV 896 is eight octets long, and consists of a Color Extended Community, as 897 defined in Section 4.3. For the use of this sub-TLV and Extended 898 Community, please see Section 8. 900 If the Length field of a Color sub-TLV has a value other than 8, or 901 the first two octets of its value field are not 0x030b, the sub-TLV 902 MUST be treated as if it were an unrecognized sub-TLV (see 903 Section 12). 905 3.5. Embedded Label Handling Sub-TLV 907 Certain BGP address families (corresponding to particular AFI/SAFI 908 pairs, e.g., 1/4, 2/4, 1/128, 2/128) have MPLS labels embedded in 909 their NLRIs. The term "embedded label" is used to refer to the MPLS 910 label that is embedded in an NLRI, and the term "labeled address 911 family" to refer to any AFI/SAFI that has embedded labels. 913 Some of the tunnel types (e.g., VXLAN, VXLAN GPE, and NVGRE) that can 914 be specified in the Tunnel Encapsulation attribute have an 915 encapsulation header containing a "Virtual Network" identifier of 916 some sort. The Encapsulation sub-TLVs for these tunnel types may 917 optionally specify a value for the virtual network identifier. 919 Suppose a Tunnel Encapsulation attribute is attached to an UPDATE of 920 a labeled address family, and it is decided to use a particular 921 tunnel (specified in one of the attribute's TLVs) for transmitting a 922 packet that is being forwarded according to that UPDATE. When 923 forming the encapsulation header for that packet, different 924 deployment scenarios require different handling of the embedded label 925 and/or the virtual network identifier. The Embedded Label Handling 926 sub-TLV can be used to control the placement of the embedded label 927 and/or the virtual network identifier in the encapsulation. 929 The Embedded Label Handling sub-TLV, whose type code is 9, may be 930 included in any TLV of the Tunnel Encapsulation attribute. If the 931 Tunnel Encapsulation attribute is attached to an UPDATE of a non- 932 labeled address family, then the sub-TLV MUST be disregarded. If the 933 sub-TLV is contained in a TLV whose Tunnel Type does not have a 934 virtual network identifier in its encapsulation header, the sub-TLV 935 MUST be disregarded. In those cases where the sub-TLV is ignored, it 936 SHOULD NOT be stripped from the TLV before the route is propagated. 938 The sub-TLV's Length field always contains the value 1, and its value 939 field consists of a single octet. The following values are defined: 941 1: The payload will be an MPLS packet with the embedded label at 942 the top of its label stack. 944 2: The embedded label is not carried in the payload, but is carried 945 either in the virtual network identifier field of the 946 encapsulation header, or else is ignored entirely. 948 Please see Section 9 for the details of how this sub-TLV is used when 949 it is carried by an UPDATE of a labeled address family. 951 3.6. MPLS Label Stack Sub-TLV 953 This sub-TLV, whose type code is 10, allows an MPLS label stack 954 ([RFC3032]) to be associated with a particular tunnel. 956 The length of the sub-TLV is a multiple of 4 octets and the value 957 field of this sub-TLV is a sequence of MPLS label stack entries. The 958 first entry in the sequence is the "topmost" label, the final entry 959 in the sequence is the "bottommost" label. When this label stack is 960 pushed onto a packet, this ordering MUST be preserved. 962 Each label stack entry has the following format: 964 0 1 2 3 965 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 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | Label | TC |S| TTL | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 Figure 10: MPLS Label Stack Sub-TLV 972 The fields are as defined in [RFC3032], [RFC5462]. 974 If a packet is to be sent through the tunnel identified in a 975 particular TLV, and if that TLV contains an MPLS Label Stack sub-TLV, 976 then the label stack appearing in the sub-TLV MUST be pushed onto the 977 packet before any other labels are pushed onto the packet. 979 In particular, if the Tunnel Encapsulation attribute is attached to a 980 BGP UPDATE of a labeled address family, the contents of the MPLS 981 Label Stack sub-TLV MUST be pushed onto the packet before the label 982 embedded in the NLRI is pushed onto the packet. 984 If the MPLS Label Stack sub-TLV is included in a TLV identifying a 985 Tunnel Type that uses virtual network identifiers (see Section 9), 986 the contents of the MPLS Label Stack sub-TLV MUST be pushed onto the 987 packet before the procedures of Section 9 are applied. 989 The number of label stack entries in the sub-TLV MUST be determined 990 from the sub-TLV length field. Thus it is not necessary to set the S 991 bit in any of the label stack entries of the sub-TLV, and the setting 992 of the S bit is ignored when parsing the sub-TLV. When the label 993 stack entries are pushed onto a packet that already has a label 994 stack, the S bits of all the entries being pushed MUST be cleared. 995 When the label stack entries are pushed onto a packet that does not 996 already have a label stack, the S bit of the bottommost label stack 997 entry MUST be set, and the S bit of all the other label stack entries 998 MUST be cleared. 1000 The TC (Traffic Class) field ([RFC3270], [RFC5129]) of each label 1001 stack entry SHOULD be set to 0, unless changed by policy at the 1002 originator of the sub-TLV. When pushing the label stack onto a 1003 packet, the TC of each label stack SHOULD be preserved, unless local 1004 policy results in a modification. 1006 The TTL (Time to Live) field of each label stack entry SHOULD be set 1007 to 255, unless changed to some other non-zero value by policy at the 1008 originator of the sub-TLV. When pushing the label stack onto a 1009 packet, the TTL of each label stack entry SHOULD be preserved, unless 1010 local policy results in a modification to some other non-zero value. 1011 If any label stack entry in the sub-TLV has a TTL value of zero, the 1012 router that is pushing the stack on a packet MUST change the value to 1013 a non-zero value, either 255 or some other value as determined by 1014 policy as discussed above. 1016 Note that this sub-TLV can appear within a TLV identifying any type 1017 of tunnel, not just within a TLV identifying an MPLS tunnel. 1018 However, if this sub-TLV appears within a TLV identifying an MPLS 1019 tunnel (or an MPLS-in-X tunnel), this sub-TLV plays the same role 1020 that would be played by an MPLS Encapsulation sub-TLV. Therefore, an 1021 MPLS Encapsulation sub-TLV is not defined. 1023 3.7. Prefix-SID Sub-TLV 1025 [RFC8669] defines a BGP Path attribute known as the "Prefix-SID 1026 Attribute". This attribute is defined to contain a sequence of one 1027 or more TLVs, where each TLV is either a "Label-Index" TLV, or an 1028 "Originator SRGB (Source Routing Global Block)" TLV. 1030 This document defines a Prefix-SID sub-TLV, whose type code is 11. 1031 The value field of the Prefix-SID sub-TLV can be set to any permitted 1032 value of the value field of a BGP Prefix-SID attribute [RFC8669]. 1034 [RFC8669] only defines behavior when the Prefix-SID Attribute is 1035 attached to routes of type IPv4/IPv6 Labeled Unicast ([RFC4760], 1036 [RFC8277]), and it only defines values of the Prefix-SID Attribute 1037 for those cases. Therefore, similar limitations exist for the 1038 Prefix-SID sub-TLV: it SHOULD only be included in a BGP UPDATE 1039 message for one of the address families defined in [RFC8669]. If 1040 included in a BGP UPDATE for any other address family then it MUST be 1041 ignored. 1043 The Prefix-SID sub-TLV can occur in a TLV identifying any type of 1044 tunnel. If an Originator SRGB is specified in the sub-TLV, that SRGB 1045 MUST be interpreted to be the SRGB used by the tunnel's egress 1046 endpoint. The Label-Index, if present, is the Segment Routing SID 1047 that the tunnel's egress endpoint uses to represent the prefix 1048 appearing in the NLRI field of the BGP UPDATE to which the Tunnel 1049 Encapsulation attribute is attached. 1051 If a Label-Index is present in the Prefix-SID sub-TLV, then when a 1052 packet is sent through the tunnel identified by the TLV, the 1053 corresponding MPLS label MUST be pushed on the packet's label stack. 1054 The corresponding MPLS label is computed from the Label-Index value 1055 and the SRGB of the route's originator, as specified in section 4.1 1056 of [RFC8669]. 1058 The corresponding MPLS label is pushed on after the processing of the 1059 MPLS Label Stack sub-TLV, if present, as specified in Section 3.6. 1060 It is pushed on before any other labels (e.g., a label embedded in 1061 UPDATE's NLRI, or a label determined by the procedures of Section 9, 1062 are pushed on the stack. 1064 The Prefix-SID sub-TLV has slightly different semantics than the 1065 Prefix-SID attribute. When the Prefix-SID attribute is attached to a 1066 given route, the BGP speaker that originally attached the attribute 1067 is expected to be in the same Segment Routing domain as the BGP 1068 speakers who receive the route with the attached attribute. The 1069 Label-Index tells the receiving BGP speakers what the prefix-SID is 1070 for the advertised prefix in that Segment Routing domain. When the 1071 Prefix-SID sub-TLV is used, the receiving BGP speaker need not even 1072 be in the same Segment Routing Domain as the tunnel's egress 1073 endpoint, and there is no implication that the prefix-SID for the 1074 advertised prefix is the same in the Segment Routing domains of the 1075 BGP speaker that originated the sub-TLV and the BGP speaker that 1076 received it. 1078 4. Extended Communities Related to the Tunnel Encapsulation Attribute 1080 4.1. Encapsulation Extended Community 1082 The Encapsulation Extended Community is a Transitive Opaque Extended 1083 Community. 1085 The Encapsulation Extended Community encoding is as shown below 1086 0 1 2 3 1087 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 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 | 0x03 | 0x0c | Reserved | 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 | Reserved | Tunnel Type | 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 Figure 11: Encapsulation Extended Community 1096 The value of the high-order octet of the extended type field is 0x03, 1097 which indicates it's transitive. The value of the low-order octet of 1098 the extended type field is 0x0c. 1100 The last two octets of the value field encode a tunnel type. 1102 This Extended Community may be attached to a route of any AFI/SAFI to 1103 which the Tunnel Encapsulation attribute may be attached. Each such 1104 Extended Community identifies a particular Tunnel Type, its semantics 1105 are the same as semantics of a Tunnel Encapsulation attribute Tunnel 1106 TLV for which the following three conditions all hold: 1108 1. it identifies the same Tunnel Type, 1110 2. it has a Tunnel Egress Endpoint sub-TLV for which one of the 1111 following two conditions holds: 1113 A. its "Address Family" subfield contains zero, or 1115 B. its "Address" subfield contains the address of the next hop 1116 field of the route to which the Tunnel Encapsulation 1117 attribute is attached 1119 3. it has no other sub-TLVs. 1121 Such a Tunnel TLV is called a "barebones" Tunnel TLV. 1123 The Encapsulation Extended Community was first defined in [RFC5512]. 1124 While it provides only a small subset of the functionality of the 1125 Tunnel Encapsulation attribute, it is used in a number of deployed 1126 applications, and is still needed for backwards compatibility. In 1127 situations where a tunnel could be encoded using a barebones TLV, it 1128 MUST be encoded using the corresponding Encapsulation Extended 1129 Community. 1131 Note that for tunnel types of the form "X-in-Y", e.g., MPLS-in-GRE, 1132 the Encapsulation Extended Community implies that only packets of the 1133 specified payload type "X" are to be carried through the tunnel of 1134 type "Y". Packets with other payload types MUST NOT be carried 1135 through such tunnels. See also Section 2. 1137 In the remainder of this specification, when a route is referred to 1138 as containing a Tunnel Encapsulation attribute with a TLV identifying 1139 a particular Tunnel Type, it implicitly includes the case where the 1140 route contains a Tunnel Encapsulation Extended Community identifying 1141 that Tunnel Type. 1143 4.2. Router's MAC Extended Community 1145 [I-D.ietf-bess-evpn-inter-subnet-forwarding] defines a Router's MAC 1146 Extended Community. This Extended Community, as its name implies, 1147 carries the MAC address of the advertising router. Since the VXLAN 1148 and NVGRE Encapsulation Sub-TLVs can also optionally carry a router's 1149 MAC, a conflict can arise if both the Router's MAC Extended Community 1150 and such an Encapsulation Sub-TLV are present at the same time but 1151 have different values. In case of such a conflict, the information 1152 in the Router's MAC Extended Community MUST be used. 1154 4.3. Color Extended Community 1156 The Color Extended Community is a Transitive Opaque Extended 1157 Community with the following encoding: 1159 0 1 2 3 1160 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 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 | 0x03 | 0x0b | Flags | 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 | Color Value | 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 Figure 12: Color Extended Community 1169 The value of the high-order octet of the extended type field is 0x03, 1170 which indicates it is transitive. The value of the low-order octet 1171 of the extended type field for this community is 0x0b. The color 1172 value is user defined and configured locally. No flags are defined 1173 in this document; this field MUST be set to zero by the originator 1174 and ignored by the receiver; the value MUST NOT be changed when 1175 propagating this Extended Community. The Color Value field is 1176 encoded as 4 octet value by the administrator and is outside the 1177 scope of this document. For the use of this Extended Community 1178 please see Section 8. 1180 5. Special Considerations for IP-in-IP Tunnels 1182 In certain situations with an IP fabric underlay, one could have a 1183 tunnel overlay with the tunnel type IP-in-IP. The egress BGP speaker 1184 can advertise the IP-in-IP tunnel endpoint address in the Tunnel 1185 Egress Endpoint sub-TLV. When the Tunnel type of the TLV is IP-in- 1186 IP, it will not have a Virtual Network Identifier. However, the 1187 tunnel egress endpoint address can be used in identifying the 1188 forwarding table to use for making the forwarding decisions to 1189 forward the payload. 1191 6. Semantics and Usage of the Tunnel Encapsulation attribute 1193 [RFC5512] specifies the use of the Tunnel Encapsulation attribute in 1194 BGP UPDATE messages of AFI/SAFI 1/7 and 2/7. That document restricts 1195 the use of this attribute to UPDATE messages of those SAFIs. This 1196 document removes that restriction. 1198 The BGP Tunnel Encapsulation attribute MAY be carried in any BGP 1199 UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6 1200 Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast), 1201 1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast), 1202 or 25/70 (Ethernet VPN, usually known as EVPN)). Use of the Tunnel 1203 Encapsulation attribute in BGP UPDATE messages of other AFI/SAFIs is 1204 outside the scope of this document. 1206 There is no significance to the order in which the TLVs occur within 1207 the Tunnel Encapsulation attribute. Multiple TLVs may occur for a 1208 given Tunnel Type; each such TLV is regarded as describing a 1209 different tunnel. (This also applies if the Tunnel Encapsulation 1210 Extended Community encoding is used.) 1212 The decision to attach a Tunnel Encapsulation attribute to a given 1213 BGP UPDATE is determined by policy. The set of TLVs and sub-TLVs 1214 contained in the attribute is also determined by policy. 1216 Suppose that: 1218 o a given packet P must be forwarded by router R; 1220 o the path along which P is to be forwarded is determined by BGP 1221 UPDATE U; 1223 o UPDATE U has a Tunnel Encapsulation attribute, containing at least 1224 one TLV that identifies a "feasible tunnel" for packet P. A 1225 tunnel is considered feasible if it has the following four 1226 properties: 1228 * The Tunnel Type is supported (i.e., router R knows how to set 1229 up tunnels of that type, how to create the encapsulation header 1230 for tunnels of that type, etc.) 1232 * The tunnel is of a type that can be used to carry packet P 1233 (e.g., an MPLS-in-UDP tunnel would not be a feasible tunnel for 1234 carrying an IP packet, unless the IP packet can first be 1235 encapsulated in a MPLS packet). 1237 * The tunnel is specified in a TLV whose Tunnel Egress Endpoint 1238 sub-TLV identifies an IP address that is reachable. This IP 1239 address may be reachable via one or more forwarding tables. 1240 Local policy may determine these forwarding tables and is 1241 outside the scope of this document. The reachability condition 1242 is evaluated as per [RFC4271], but the essence is that if the 1243 router could forward a packet addressed to the IP address, the 1244 IP address is "reachable". 1246 * There is no local policy that prevents the use of the tunnel. 1248 Then router R MUST send packet P through one of the feasible tunnels 1249 identified in the Tunnel Encapsulation attribute of UPDATE U. 1251 If the Tunnel Encapsulation attribute contains several TLVs (i.e., if 1252 it specifies several feasible tunnels), router R may choose any one 1253 of those tunnels, based upon local policy. If any Tunnel TLV 1254 contains one or more Color sub-TLVs (Section 3.4.2) and/or the 1255 Protocol Type sub-TLV (Section 3.4.1), the choice of tunnel may be 1256 influenced by these sub-TLVs. 1258 The reachability to the address of the egress endpoint of the tunnel 1259 may change over time, directly impacting the feasibility of the 1260 tunnel. A tunnel that is not feasible at some moment, may become 1261 feasible at a later time when its egress endpoint address is 1262 reachable. The router may start using the newly feasible tunnel 1263 instead of an existing one. How this decision is made is outside the 1264 scope of this document. 1266 Once it is determined to send a packet through the tunnel specified 1267 in a particular Tunnel TLV of a particular Tunnel Encapsulation 1268 attribute, then the tunnel's egress endpoint address is the IP 1269 address contained in the sub-TLV. If the Tunnel TLV contains a 1270 Tunnel Egress Endpoint sub-TLV whose value field is all zeroes, then 1271 the tunnel's egress endpoint is the address of the Next Hop of the 1272 BGP Update containing the Tunnel Encapsulation attribute. The 1273 address of the tunnel egress endpoint generally appears in a 1274 "destination address" field of the encapsulation. 1276 The full set of procedures for sending a packet through a particular 1277 Tunnel Type to a particular tunnel egress endpoint depends upon the 1278 tunnel type, and is outside the scope of this document. Note that 1279 some tunnel types may require the execution of an explicit tunnel 1280 setup protocol before they can be used for carrying data. Other 1281 tunnel types may not require any tunnel setup protocol. 1283 Sending a packet through a tunnel always requires that the packet be 1284 encapsulated, with an encapsulation header that is appropriate for 1285 the Tunnel Type. The contents of the tunnel encapsulation header may 1286 be influenced by the Encapsulation sub-TLV. If there is no 1287 Encapsulation sub-TLV present, the router transmitting the packet 1288 through the tunnel must have a priori knowledge (e.g., by 1289 provisioning) of how to fill in the various fields in the 1290 encapsulation header. 1292 A Tunnel Encapsulation attribute may contain several TLVs that all 1293 specify the same Tunnel Type. Each TLV should be considered as 1294 specifying a different tunnel. Two tunnels of the same type may have 1295 different Tunnel Egress Endpoint sub-TLVs, different Encapsulation 1296 sub-TLVs, etc. Choosing between two such tunnels is a matter of 1297 local policy. 1299 Once router R has decided to send packet P through a particular 1300 tunnel, it encapsulates packet P appropriately and then forwards it 1301 according to the route that leads to the tunnel's egress endpoint. 1302 This route may itself be a BGP route with a Tunnel Encapsulation 1303 attribute. If so, the encapsulated packet is treated as the payload 1304 and is encapsulated according to the Tunnel Encapsulation attribute 1305 of that route. That is, tunnels may be "stacked". 1307 Notwithstanding anything said in this document, a BGP speaker MAY 1308 have local policy that influences the choice of tunnel, and the way 1309 the encapsulation is formed. A BGP speaker MAY also have a local 1310 policy that tells it to ignore the Tunnel Encapsulation attribute 1311 entirely or in part. Of course, interoperability issues must be 1312 considered when such policies are put into place. 1314 See also Section 12, which provides further specification regarding 1315 validation and exception cases. 1317 7. Routing Considerations 1319 7.1. Impact on the BGP Decision Process 1321 The presence of the Tunnel Encapsulation attribute affects the BGP 1322 best route selection algorithm. If a route includes the Tunnel 1323 Encapsulation attribute, and if that attribute includes no tunnel 1324 which is feasible, then that route MUST NOT be considered resolvable 1325 for the purposes of Route Resolvability Condition [RFC4271] section 1326 9.1.2.1. 1328 7.2. Looping, Mutual Recursion, Etc. 1330 Consider a packet destined for address X. Suppose a BGP UPDATE for 1331 address prefix X carries a Tunnel Encapsulation attribute that 1332 specifies a tunnel egress endpoint of Y, and suppose that a BGP 1333 UPDATE for address prefix Y carries a Tunnel Encapsulation attribute 1334 that specifies a tunnel egress endpoint of X. It is easy to see that 1335 this can have no good outcome. [RFC4271] describes an analogous case 1336 as mutually recursive routes. 1338 This could happen as a result of misconfiguration, either accidental 1339 or intentional. It could also happen if the Tunnel Encapsulation 1340 attribute were altered by a malicious agent. Implementations should 1341 be aware that such an attack will result in unresolvable BGP routes 1342 due to the mutually recursive relationship. This document does not 1343 specify a maximum number of recursions; that is an implementation- 1344 specific matter. 1346 Improper setting (or malicious altering) of the Tunnel Encapsulation 1347 attribute could also cause data packets to loop. Suppose a BGP 1348 UPDATE for address prefix X carries a Tunnel Encapsulation attribute 1349 that specifies a tunnel egress endpoint of Y. Suppose router R 1350 receives and processes the advertisement. When router R receives a 1351 packet destined for X, it will apply the encapsulation and send the 1352 encapsulated packet to Y. Y will decapsulate the packet and forward 1353 it further. If Y is further away from X than is router R, it is 1354 possible that the path from Y to X will traverse R. This would cause 1355 a long-lasting routing loop. The control plane itself cannot detect 1356 this situation, though a TTL field in the payload packets would 1357 prevent any given packet from looping infinitely. 1359 During the deployment of techniques as described in this document, 1360 operators are encouraged to avoid mutually recursive route and/or 1361 tunnel dependencies. There is greater potential for such scenarios 1362 to arise when the tunnel egress endpoint for a given prefix differs 1363 from the address of the next hop for that prefix. 1365 8. Recursive Next Hop Resolution 1367 Suppose that: 1369 o a given packet P must be forwarded by router R1; 1370 o the path along which P is to be forwarded is determined by BGP 1371 UPDATE U1; 1373 o UPDATE U1 does not have a Tunnel Encapsulation attribute; 1375 o the address of the next hop of UPDATE U1 is router R2; 1377 o the best route to router R2 is a BGP route that was advertised in 1378 UPDATE U2; 1380 o UPDATE U2 has a Tunnel Encapsulation attribute. 1382 Then packet P MUST be sent through one of the tunnels identified in 1383 the Tunnel Encapsulation attribute of UPDATE U2. See Section 6 for 1384 further details. 1386 However, suppose that one of the TLVs in U2's Tunnel Encapsulation 1387 attribute contains the Color Sub-TLV. In that case, packet P MUST 1388 NOT be sent through the tunnel contained in that TLV, unless U1 is 1389 carrying the Color Extended Community that is identified in U2's 1390 Color Sub-TLV. 1392 The procedures in this section presuppose that U1's address of the 1393 next hop resolves to a BGP route, and that U2's next hop resolves 1394 (perhaps after further recursion) to a non-BGP route. 1396 9. Use of Virtual Network Identifiers and Embedded Labels when Imposing 1397 a Tunnel Encapsulation 1399 If the TLV specifying a tunnel contains an MPLS Label Stack sub-TLV, 1400 then when sending a packet through that tunnel, the procedures of 1401 Section 3.6 are applied before the procedures of this section. 1403 If the TLV specifying a tunnel contains a Prefix-SID sub-TLV, the 1404 procedures of Section 3.7 are applied before the procedures of this 1405 section. If the TLV also contains an MPLS Label Stack sub-TLV, the 1406 procedures of Section 3.6 are applied before the procedures of 1407 Section 3.7. 1409 9.1. Tunnel Types without a Virtual Network Identifier Field 1411 If a Tunnel Encapsulation attribute is attached to an UPDATE of a 1412 labeled address family, there will be one or more labels specified in 1413 the UPDATE's NLRI. When a packet is sent through a tunnel specified 1414 in one of the attribute's TLVs, and that tunnel type does not contain 1415 a virtual network identifier field, the label or labels from the NLRI 1416 are pushed on the packet's label stack. The resulting MPLS packet is 1417 then further encapsulated, as specified by the TLV. 1419 9.2. Tunnel Types with a Virtual Network Identifier Field 1421 Three of the tunnel types that can be specified in a Tunnel 1422 Encapsulation TLV have virtual network identifier fields in their 1423 encapsulation headers. In the VXLAN and VXLAN GPE encapsulations, 1424 this field is called the VNI (Virtual Network Identifier) field; in 1425 the NVGRE encapsulation, this field is called the VSID (Virtual 1426 Subnet Identifier) field. 1428 When one of these tunnel encapsulations is imposed on a packet, the 1429 setting of the virtual network identifier field in the encapsulation 1430 header depends upon the contents of the Encapsulation sub-TLV (if one 1431 is present). When the Tunnel Encapsulation attribute is being 1432 carried in a BGP UPDATE of a labeled address family, the setting of 1433 the virtual network identifier field also depends upon the contents 1434 of the Embedded Label Handling sub-TLV (if present). 1436 This section specifies the procedures for choosing the value to set 1437 in the virtual network identifier field of the encapsulation header. 1438 These procedures apply only when the Tunnel Type is VXLAN, VXLAN GPE, 1439 or NVGRE. 1441 9.2.1. Unlabeled Address Families 1443 This sub-section applies when: 1445 o the Tunnel Encapsulation attribute is carried in a BGP UPDATE of 1446 an unlabeled address family, and 1448 o at least one of the attribute's TLVs identifies a Tunnel Type that 1449 uses a virtual network identifier, and 1451 o it has been determined to send a packet through one of those 1452 tunnels. 1454 If the TLV identifying the tunnel contains an Encapsulation sub-TLV 1455 whose V bit is set, the virtual network identifier field of the 1456 encapsulation header is set to the value of the virtual network 1457 identifier field of the Encapsulation sub-TLV. 1459 Otherwise, the virtual network identifier field of the encapsulation 1460 header is set to a configured value; if there is no configured value, 1461 the tunnel cannot be used. 1463 9.2.2. Labeled Address Families 1465 This sub-section applies when: 1467 o the Tunnel Encapsulation attribute is carried in a BGP UPDATE of a 1468 labeled address family, and 1470 o at least one of the attribute's TLVs identifies a Tunnel Type that 1471 uses a virtual network identifier, and 1473 o it has been determined to send a packet through one of those 1474 tunnels. 1476 9.2.2.1. When a Valid VNI has been Signaled 1478 If the TLV identifying the tunnel contains an Encapsulation sub-TLV 1479 whose V bit is set, the virtual network identifier field of the 1480 encapsulation header is set to the value of the virtual network 1481 identifier field of the Encapsulation sub-TLV. However, the Embedded 1482 Label Handling sub-TLV will determine label processing as described 1483 below. 1485 o If the TLV contains an Embedded Label Handling sub-TLV whose value 1486 is 1, the embedded label (from the NLRI of the route that is 1487 carrying the Tunnel Encapsulation attribute) appears at the top of 1488 the MPLS label stack in the encapsulation payload. 1490 o If the TLV does not contain an Embedded Label Handling sub-TLV, or 1491 it contains an Embedded Label Handling sub-TLV whose value is 2, 1492 the embedded label is ignored entirely. 1494 9.2.2.2. When a Valid VNI has not been Signaled 1496 If the TLV identifying the tunnel does not contain an Encapsulation 1497 sub-TLV whose V bit is set, the virtual network identifier field of 1498 the encapsulation header is set as follows: 1500 o If the TLV contains an Embedded Label Handling sub-TLV whose value 1501 is 1, then the virtual network identifier field of the 1502 encapsulation header is set to a configured value. 1504 If there is no configured value, the tunnel cannot be used. 1506 The embedded label (from the NLRI of the route that is carrying 1507 the Tunnel Encapsulation attribute) appears at the top of the MPLS 1508 label stack in the encapsulation payload. 1510 o If the TLV does not contain an Embedded Label Handling sub-TLV, or 1511 if it contains an Embedded Label Handling sub-TLV whose value is 1512 2, the embedded label is copied into the lower 3 octets of the 1513 virtual network identifier field of the encapsulation header. 1515 In this case, the payload may or may not contain an MPLS label 1516 stack, depending upon other factors. If the payload does contain 1517 an MPLS label stack, the embedded label does not appear in that 1518 stack. 1520 10. Applicability Restrictions 1522 In a given UPDATE of a labeled address family, the label embedded in 1523 the NLRI is generally a label that is meaningful only to the router 1524 represented by the address of the next hop. Certain of the 1525 procedures of Section 9.2.2.1 or Section 9.2.2.2 cause the embedded 1526 label to be carried by a data packet to the router whose address 1527 appears in the Tunnel Egress Endpoint sub-TLV. If the Tunnel Egress 1528 Endpoint sub-TLV does not identify the same router represented by the 1529 address of the next hop, sending the packet through the tunnel may 1530 cause the label to be misinterpreted at the tunnel's egress endpoint. 1531 This may cause misdelivery of the packet. Avoidance of this 1532 unfortunate outcome is a matter of network planning and design, and 1533 is outside the scope of this document. 1535 Note that if the Tunnel Encapsulation attribute is attached to a VPN- 1536 IP route [RFC4364], and if Inter-AS "option b" (see section 10 of 1537 [RFC4364]) is being used, and if the Tunnel Egress Endpoint sub-TLV 1538 contains an IP address that is not in same AS as the router receiving 1539 the route, it is very likely that the embedded label has been 1540 changed. Therefore use of the Tunnel Encapsulation attribute in an 1541 "Inter-AS option b" scenario is not recommended. 1543 11. Scoping 1545 The Tunnel Encapsulation attribute is defined as a transitive 1546 attribute, so that it may be passed along by BGP speakers that do not 1547 recognize it. However, it is intended that the Tunnel Encapsulation 1548 attribute be used only within a well-defined scope, e.g., within a 1549 set of Autonomous Systems that belong to a single administrative 1550 entity. If the attribute is distributed beyond its intended scope, 1551 packets may be sent through tunnels in a manner that is not intended. 1553 To prevent the Tunnel Encapsulation attribute from being distributed 1554 beyond its intended scope, any BGP speaker that understands the 1555 attribute MUST be able to filter the attribute from incoming BGP 1556 UPDATE messages. When the attribute is filtered from an incoming 1557 UPDATE, the attribute is neither processed nor distributed. This 1558 filtering SHOULD be possible on a per-BGP-session basis; finer 1559 granularities (for example, per route and/or per attribute TLV) MAY 1560 be supported. For each external BGP (EBGP) session, filtering of the 1561 attribute on incoming UPDATEs MUST be enabled by default. 1563 In addition, any BGP speaker that understands the attribute MUST be 1564 able to filter the attribute from outgoing BGP UPDATE messages. This 1565 filtering SHOULD be possible on a per-BGP-session basis. For each 1566 EBGP session, filtering of the attribute on outgoing UPDATEs MUST be 1567 enabled by default. 1569 Since the Tunnel Encapsulation Extended Community provides a subset 1570 of the functionality of the Tunnel Encapsulation attribute, these 1571 considerations apply equally in its case: any BGP speaker that 1572 understands it MUST be able to filter it from incoming BGP UPDATE 1573 messages, it MUST be possible to filter the Tunnel Encapsulation 1574 Extended Community from outgoing messages, and in both cases this 1575 filtering MUST be enabled by default for EBGP sessions. 1577 12. Validation and Error Handling 1579 The Tunnel Encapsulation attribute is a sequence of TLVs, each of 1580 which is a sequence of sub-TLVs. The final octet of a TLV is 1581 determined by its length field. Similarly, the final octet of a sub- 1582 TLV is determined by its length field. The final octet of a TLV MUST 1583 also be the final octet of its final sub-TLV. If this is not the 1584 case, the TLV MUST be considered to be malformed, and the "Treat-as- 1585 withdraw" procedure of [RFC7606] is applied. 1587 If a Tunnel Encapsulation attribute does not have any valid TLVs, or 1588 it does not have the transitive bit set, the "Treat-as-withdraw" 1589 procedure of [RFC7606] is applied. 1591 If a Tunnel Encapsulation attribute can be parsed correctly, but 1592 contains a TLV whose Tunnel Type is not recognized by a particular 1593 BGP speaker, that BGP speaker MUST NOT consider the attribute to be 1594 malformed. Rather, it MUST interpret the attribute as if that TLV 1595 had not been present. If the route carrying the Tunnel Encapsulation 1596 attribute is propagated with the attribute, the unrecognized TLV MUST 1597 remain in the attribute. 1599 The following sub-TLVs defined in this document MUST NOT occur more 1600 than once in a given Tunnel TLV: Tunnel Egress Endpoint (discussed 1601 below), Encapsulation, DS, UDP Destination Port, Embedded Label 1602 Handling, MPLS Label Stack, Prefix-SID. If a Tunnel TLV has more 1603 than one of any of these sub-TLVs, all but the first occurrence of 1604 each such sub-TLV type MUST be disregarded. However, the Tunnel TLV 1605 containing them MUST NOT be considered to be malformed, and all the 1606 sub-TLVs MUST be propagated if the route carrying the Tunnel 1607 Encapsulation attribute is propagated. 1609 The following sub-TLVs defined in this document may appear zero or 1610 more times in a given Tunnel TLV: Protocol Type, Color. Each 1611 occurrence of such sub-TLVs is meaningful. For example, the Color 1612 sub-TLV may appear multiple times to assign multiple colors to a 1613 tunnel. 1615 If a TLV of a Tunnel Encapsulation attribute contains a sub-TLV that 1616 is not recognized by a particular BGP speaker, the BGP speaker MUST 1617 process that TLV as if the unrecognized sub-TLV had not been present. 1618 If the route carrying the Tunnel Encapsulation attribute is 1619 propagated with the attribute, the unrecognized sub-TLV MUST remain 1620 in the attribute. 1622 In general, if a TLV contains a sub-TLV that is malformed, the sub- 1623 TLV MUST be treated as if it were an unrecognized sub-TLV. This 1624 document specifies one exception to this rule -- if a TLV contains a 1625 malformed Tunnel Egress Endpoint sub-TLV (as defined in Section 3.1), 1626 the entire TLV MUST be ignored, and MUST be removed from the Tunnel 1627 Encapsulation attribute before the route carrying that attribute is 1628 distributed. 1630 Within a Tunnel Encapsulation attribute that is carried by a BGP 1631 UPDATE whose AFI/SAFI is one of those explicitly listed in the second 1632 paragraph of Section 6, a TLV that does not contain exactly one 1633 Tunnel Egress Endpoint sub-TLV MUST be treated as if it contained a 1634 malformed Tunnel Egress Endpoint sub-TLV. 1636 A TLV identifying a particular Tunnel Type may contain a sub-TLV that 1637 is meaningless for that Tunnel Type. For example, perhaps the TLV 1638 contains a UDP Destination Port sub-TLV, but the identified tunnel 1639 type does not use UDP encapsulation at all, or a tunnel of the form 1640 "X-in-Y" contains a Protocol Type sub-TLV that specifies something 1641 other than "X". Sub-TLVs of this sort MUST be disregarded. That is, 1642 they MUST NOT affect the creation of the encapsulation header. 1643 However, the sub-TLV MUST NOT be considered to be malformed, and MUST 1644 NOT be removed from the TLV before the route carrying the Tunnel 1645 Encapsulation attribute is distributed. An implementation MAY log a 1646 message when it encounters such a sub-TLV. 1648 13. IANA Considerations 1650 This document makes the following requests of IANA. (All 1651 registration procedures listed below are per their definitions in 1652 [RFC8126].) 1653 Because this document obsoletes RFC 5512, change all registration 1654 information that references [RFC5512] to instead reference this 1655 document. 1657 13.1. Obsoleting Code Points Assigned by RFCs 5566 and 5640 1659 Since this document obsoletes RFCs 5566 and 5640, the code points 1660 assigned by those RFCs are similarly obsoleted. Specifically, the 1661 following code points should be marked as deprecated. 1663 In the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry: 1665 +-------+---------------------------------------------+ 1666 | Value | Name | 1667 +-------+---------------------------------------------+ 1668 | 3 | Transmit tunnel endpoint | 1669 | 4 | IPsec in Tunnel-mode | 1670 | 5 | IP in IP tunnel with IPsec Transport Mode | 1671 | 6 | MPLS-in-IP tunnel with IPsec Transport Mode | 1672 +-------+---------------------------------------------+ 1674 And in the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry: 1676 +-------+----------------------------+ 1677 | Value | Name | 1678 +-------+----------------------------+ 1679 | 3 | IPsec Tunnel Authenticator | 1680 | 5 | Load-Balancing Block | 1681 +-------+----------------------------+ 1683 13.2. BGP Tunnel Encapsulation Parameters Grouping 1685 Create a new registry grouping, to be named "BGP Tunnel Encapsulation 1686 Parameters". 1688 13.3. Subsequent Address Family Identifiers 1690 Modify the "Subsequent Address Family Identifiers" registry to 1691 indicate that the Encapsulation SAFI (value 7) is obsoleted. This 1692 document should be the reference. 1694 13.4. BGP Tunnel Encapsulation Attribute Sub-TLVs 1696 Relocate the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry 1697 to be under the "BGP Tunnel Encapsulation Parameters" grouping. 1699 Add the following note to the registry: 1701 If the Sub-TLV Type is in the range from 0 to 127 inclusive, the 1702 Sub-TLV Length field contains one octet. If the Sub-TLV Type is 1703 in the range from 128-255 inclusive, the Sub-TLV Length field 1704 contains two octets. 1706 Change the registration policy of the registry to the following: 1708 +----------+-------------------------+ 1709 | Value(s) | Registration Procedure | 1710 +----------+-------------------------+ 1711 | 0 | Reserved | 1712 | 1-63 | Standards Action | 1713 | 64-125 | First Come First Served | 1714 | 126-127 | Experimental Use | 1715 | 128-191 | Standards Action | 1716 | 192-252 | First Come First Served | 1717 | 253-254 | Experimental Use | 1718 | 255 | Reserved | 1719 +----------+-------------------------+ 1721 Rename the following entries within the registry: 1723 +-------+-----------------+------------------------+ 1724 | Value | Old Name | New Name | 1725 +-------+-----------------+------------------------+ 1726 | 6 | Remote Endpoint | Tunnel Egress Endpoint | 1727 | 7 | IPv4 DS Field | DS Field | 1728 +-------+-----------------+------------------------+ 1730 13.5. Flags Field of VXLAN Encapsulation sub-TLV 1732 Create a registry named "Flags Field of VXLAN Encapsulation sub-TLV" 1733 under the "BGP Tunnel Encapsulation Parameters" grouping. The 1734 registration policy for this registry is "Standards Action". 1736 The initial values for this new registry are indicated below. 1738 +--------------+--------------------------------+-----------------+ 1739 | Bit Position | Description | Reference | 1740 +--------------+--------------------------------+-----------------+ 1741 | 0 | V (Virtual Network Identifier) | (this document) | 1742 | 1 | M (MAC Address) | (this document) | 1743 +--------------+--------------------------------+-----------------+ 1745 13.6. Flags Field of VXLAN GPE Encapsulation sub-TLV 1747 Create a registry named "Flags Field of VXLAN GPE Encapsulation sub- 1748 TLV" under the "BGP Tunnel Encapsulation Parameters" grouping. The 1749 registration policy for this registry is "Standards Action". 1751 The initial value for this new registry is indicated below. 1753 +--------------+-------------+-----------------+ 1754 | Bit Position | Description | Reference | 1755 +--------------+-------------+-----------------+ 1756 | 0 | V (VN-ID) | (this document) | 1757 +--------------+-------------+-----------------+ 1759 13.7. Flags Field of NVGRE Encapsulation sub-TLV 1761 Create a registry named "Flags Field of NVGRE Encapsulation sub-TLV" 1762 under the "BGP Tunnel Encapsulation Parameters" grouping. The 1763 registration policy for this registry is "Standards Action". 1765 The initial values for this new registry are indicated below. 1767 +--------------+-----------------+-----------------+ 1768 | Bit Position | Description | Reference | 1769 +--------------+-----------------+-----------------+ 1770 | 0 | V (VN-ID) | (this document) | 1771 | 1 | M (MAC Address) | (this document) | 1772 +--------------+-----------------+-----------------+ 1774 13.8. Embedded Label Handling sub-TLV 1776 Create a registry named "Embedded Label Handling sub-TLV" under the 1777 "BGP Tunnel Encapsulation Parameters" grouping. The registration 1778 policy for this registry is "Standards Action". 1780 The initial values for this new registry are indicated below. 1782 +-------+-------------------------------------+-----------------+ 1783 | Value | Description | Reference | 1784 +-------+-------------------------------------+-----------------+ 1785 | 1 | Payload of MPLS with embedded label | (this document) | 1786 | 2 | no embedded label in payload | (this document) | 1787 +-------+-------------------------------------+-----------------+ 1789 13.9. Color Extended Community Flags 1791 Create a registry named "Color Extended Community Flags" under the 1792 "BGP Tunnel Encapsulation Parameters" grouping. The registration 1793 policy for this registry is "Standards Action". 1795 No initial values are to be registered. The format of the registry 1796 is shown below. 1798 +--------------+-------------+-----------+ 1799 | Bit Position | Description | Reference | 1800 +--------------+-------------+-----------+ 1801 +--------------+-------------+-----------+ 1803 14. Security Considerations 1805 As Section 11 discusses, it is intended that the Tunnel Encapsulation 1806 attribute be used only within a well-defined scope, e.g., within a 1807 set of Autonomous Systems that belong to a single administrative 1808 entity. As long as the filtering mechanisms discussed in that 1809 section are applied diligently, an attacker outside the scope would 1810 not be able to use the Tunnel Encapsulation attribute in an attack. 1811 This leaves open the questions of attackers within the scope (for 1812 example, a compromised router) and failures in filtering that allow 1813 an external attack to succeed. 1815 As [RFC4272] discusses, BGP is vulnerable to traffic diversion 1816 attacks. The Tunnel Encapsulation attribute adds a new means by 1817 which an attacker could cause traffic to be diverted from its normal 1818 path, especially when the Tunnel Egress Endpoint sub-TLV is used. 1819 Such an attack would differ from pre-existing vulnerabilities in that 1820 traffic could be tunneled to a distant target across intervening 1821 network infrastructure, allowing an attack to potentially succeed 1822 more easily, since less infrastructure would have to be subverted. 1823 Potential consequences include "hijacking" of traffic (insertion of 1824 an undesired node in the path) or denial of service (directing 1825 traffic to a node that doesn't desire to receive it). 1827 In order to further mitigate the risk of diversion of traffic from 1828 its intended destination, Section 3.1.1 provides an optional 1829 procedure to check that the destination given in a Tunnel Egress 1830 Endpoint sub-TLV is within the AS that was the source of the route. 1831 One then has some level of assurance that the tunneled traffic is 1832 going to the same destination AS that it would have gone to had the 1833 Tunnel Encapsulation attribute not been present. As RFC 4272 1834 discusses, it's possible for an attacker to announce an inaccurate 1835 AS_PATH, therefore an attacker with the ability to inject a Tunnel 1836 Egress Endpoint sub-TLV could equally craft an AS_PATH that would 1837 pass the validation procedures of Section 3.1.1. BGP Origin 1838 Validation [RFC6811] and BGPsec [RFC8205] provide means to increase 1839 assurance that the origins being validated have not been falsified. 1841 15. Acknowledgments 1843 This document contains text from RFC 5512, authored by Pradosh 1844 Mohapatra and Eric Rosen. The authors of the current document wish 1845 to thank them for their contribution. RFC 5512 itself built upon 1846 prior work by Gargi Nalawade, Ruchi Kapoor, Dan Tappan, David Ward, 1847 Scott Wainner, Simon Barber, Lili Wang, and Chris Metz, whom the 1848 authors also thank for their contributions. Eric Rosen was the 1849 principal author of earlier versions of this document. 1851 The authors wish to thank Lou Berger, Ron Bonica, Martin Djernaes, 1852 John Drake, Satoru Matsushima, Dhananjaya Rao, Ravi Singh, Thomas 1853 Morin, Xiaohu Xu, and Zhaohui Zhang for their review, comments, and/ 1854 or helpful discussions. Alvaro Retana provided an especially 1855 comprehensive review. 1857 16. Contributor Addresses 1859 Below is a list of other contributing authors in alphabetical order: 1861 Randy Bush 1862 Internet Initiative Japan 1863 5147 Crystal Springs 1864 Bainbridge Island, Washington 98110 1865 United States 1867 Email: randy@psg.com 1869 Robert Raszuk 1870 Bloomberg LP 1871 731 Lexington Ave 1872 New York City, NY 10022 1873 United States 1875 Email: robert@raszuk.net 1877 Eric C. Rosen 1879 17. References 1880 17.1. Normative References 1882 [I-D.ietf-nvo3-vxlan-gpe] 1883 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 1884 Extension for VXLAN (VXLAN-GPE)", draft-ietf-nvo3-vxlan- 1885 gpe-10 (work in progress), July 2020. 1887 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1888 Requirement Levels", BCP 14, RFC 2119, 1889 DOI 10.17487/RFC2119, March 1997, 1890 . 1892 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1893 "Definition of the Differentiated Services Field (DS 1894 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1895 DOI 10.17487/RFC2474, December 1998, 1896 . 1898 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1899 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1900 DOI 10.17487/RFC2784, March 2000, 1901 . 1903 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 1904 RFC 2890, DOI 10.17487/RFC2890, September 2000, 1905 . 1907 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1908 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1909 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1910 . 1912 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 1913 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 1914 Protocol Label Switching (MPLS) Support of Differentiated 1915 Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, 1916 . 1918 [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., 1919 "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", 1920 RFC 3931, DOI 10.17487/RFC3931, March 2005, 1921 . 1923 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 1924 "Encapsulating MPLS in IP or Generic Routing Encapsulation 1925 (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, 1926 . 1928 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1929 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1930 DOI 10.17487/RFC4271, January 2006, 1931 . 1933 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1934 "Multiprotocol Extensions for BGP-4", RFC 4760, 1935 DOI 10.17487/RFC4760, January 2007, 1936 . 1938 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 1939 Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 1940 2008, . 1942 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 1943 "Special-Purpose IP Address Registries", BCP 153, 1944 RFC 6890, DOI 10.17487/RFC6890, April 2013, 1945 . 1947 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1948 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1949 eXtensible Local Area Network (VXLAN): A Framework for 1950 Overlaying Virtualized Layer 2 Networks over Layer 3 1951 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 1952 . 1954 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1955 Patel, "Revised Error Handling for BGP UPDATE Messages", 1956 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1957 . 1959 [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network 1960 Virtualization Using Generic Routing Encapsulation", 1961 RFC 7637, DOI 10.17487/RFC7637, September 2015, 1962 . 1964 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1965 Writing an IANA Considerations Section in RFCs", BCP 26, 1966 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1967 . 1969 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1970 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1971 May 2017, . 1973 [RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, 1974 A., and H. Gredler, "Segment Routing Prefix Segment 1975 Identifier Extensions for BGP", RFC 8669, 1976 DOI 10.17487/RFC8669, December 2019, 1977 . 1979 17.2. Informative References 1981 [Ethertypes] 1982 "IANA Ethertype Registry", 1983 . 1986 [I-D.ietf-bess-evpn-inter-subnet-forwarding] 1987 Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. 1988 Rabadan, "Integrated Routing and Bridging in EVPN", draft- 1989 ietf-bess-evpn-inter-subnet-forwarding-10 (work in 1990 progress), September 2020. 1992 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 1993 RFC 4272, DOI 10.17487/RFC4272, January 2006, 1994 . 1996 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1997 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1998 2006, . 2000 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 2001 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 2002 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2003 2009, . 2005 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 2006 Subsequent Address Family Identifier (SAFI) and the BGP 2007 Tunnel Encapsulation Attribute", RFC 5512, 2008 DOI 10.17487/RFC5512, April 2009, 2009 . 2011 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 2012 Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, 2013 . 2015 [RFC5566] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel 2016 Encapsulation Attribute", RFC 5566, DOI 10.17487/RFC5566, 2017 June 2009, . 2019 [RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load- 2020 Balancing for Mesh Softwires", RFC 5640, 2021 DOI 10.17487/RFC5640, August 2009, 2022 . 2024 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 2025 Austein, "BGP Prefix Origin Validation", RFC 6811, 2026 DOI 10.17487/RFC6811, January 2013, 2027 . 2029 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 2030 "Encapsulating MPLS in UDP", RFC 7510, 2031 DOI 10.17487/RFC7510, April 2015, 2032 . 2034 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 2035 Specification", RFC 8205, DOI 10.17487/RFC8205, September 2036 2017, . 2038 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 2039 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 2040 . 2042 Authors' Addresses 2044 Keyur Patel 2045 Arrcus, Inc 2046 2077 Gateway Pl 2047 San Jose, CA 95110 2048 United States 2050 Email: keyur@arrcus.com 2052 Gunter Van de Velde 2053 Nokia 2054 Copernicuslaan 50 2055 Antwerpen 2018 2056 Belgium 2058 Email: gunter.van_de_velde@nokia.com 2060 Srihari R. Sangli 2061 Juniper Networks 2063 Email: ssangli@juniper.net 2064 John Scudder 2065 Juniper Networks 2067 Email: jgs@juniper.net