The BGP Tunnel Encapsulation Attribute
draft-ietf-idr-tunnel-encaps-07
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9012.
|
|
|---|---|---|---|
| Authors | Eric C. Rosen , Keyur Patel , Gunter Van de Velde | ||
| Last updated | 2017-10-20 (Latest revision 2017-07-17) | ||
| Replaces | draft-rosen-idr-tunnel-encaps, draft-vandevelde-idr-remote-next-hop | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
TSVART Last Call review
(of
-19)
by Brian Trammell
Ready w/issues
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Consensus: Waiting for Write-Up | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 9012 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-idr-tunnel-encaps-07
#x27;s Remote Endpoint uses to represent the prefix appearing in the NLRI field of the BGP UPDATE to which the Tunnel Encapsulation attribute is attached. If a Label-Index is present in the prefix-SID sub-TLV, then when a packet is sent through the tunnel identified by the TLV, the corresponding MPLS label MUST be pushed on the packet's label stack. The corresponding MPLS label is computed from the Label-Index value and the SRGB of the route's originator. If the Originator SRGB is not present,it is assumed that the originator's SRGB is known by other means. Such "other means" are outside the scope of this document. Rosen, et al. Expires January 18, 2018 [Page 20] Internet-Draft Tunnel Encapsulation Attribute July 2017 The corresponding MPLS label is pushed on after the processing of the MPLS Label Stack sub-TLV, if present, as specified in Section 3.6. It is pushed on before any other labels (e.g., a label embedded in UPDATE's NLRI, or a label determined by the procedures of Section 8 are pushed on the stack. The Prefix-SID sub-TLV has slightly different semantics than the Prefix-SID attribute. When the Prefix-SID attribute is attached to a given route, the BGP speaker that originally attached the attribute is expected to be in the same Segment Routing domain as the BGP speakers who receive the route with the attached attribute. The Label-Index tells the receiving BGP speakers that the prefix-SID is for the advertised prefix in that Segment Routing domain. When the Prefix-SID sub-TLV is used, the BGP speaker at the head end of the tunnel need even not be in the same Segment Routing Domain as the tunnel's Remote Endpoint, and there is no implication that the prefix-SID for the advertised prefix is the same in the Segment Routing domains of the BGP speaker that originated the sub-TLV and the BGP speaker that received it. 4. Extended Communities Related to the Tunnel Encapsulation Attribute 4.1. Encapsulation Extended Community The Encapsulation Extended Community is a Transitive Opaque Extended Community. This Extended Community may be attached to a route of any AFI/SAFI to which the Tunnel Encapsulation attribute may be attached. Each such Extended Community identifies a particular tunnel type. If the Encapsulation Extended Community identifies a particular tunnel type, its semantics are exactly equivalent to the semantics of a Tunnel Encapsulation attribute Tunnel TLV for which the following three conditions all hold: 1. it identifies the same tunnel type, 2. it has a Remote Endpoint sub-TLV for which one of the following two conditions holds: a. its "Address Family" subfield contains zero, or b. its "Address" subfield contains the same IP address that appears in the next hop field of the route to which the Tunnel Encapsulation attribute is attached 3. it has no other sub-TLVs. We will refer to such a Tunnel TLV as a "barebones" Tunnel TLV. Rosen, et al. Expires January 18, 2018 [Page 21] Internet-Draft Tunnel Encapsulation Attribute July 2017 The Encapsulation Extended Community was first defined in [RFC5512]. While it provides only a small subset of the functionality of the Tunnel Encapsulation attribute, it is used in a number of deployed applications, and is still needed for backwards compatibility. To ensure backwards compatibility, this specification establishes the following rules: 1. If the Tunnel Encapsulation attribute of a given route contains a barebones Tunnel TLV identifying a particular tunnel type, an Encapsulation Extended Community identifying the same tunnel type SHOULD be attached to the route. 2. If the Encapsulation Extended Community identifying a particular tunnel type is attached to a given route, the corresponding barebones Tunnel TLV MAY be omitted from the Tunnel Encapsulation attribute. 3. Suppose a particular route has both (a) an Encapsulation Extended Community specifying a particular tunnel type, and (b) a Tunnel Encapsulation attribute with a barebones Tunnel TLV specifying that same tunnel type. Both (a) and (b) MUST be interpreted as denoting the same tunnel. In short, in situations where one could use either the Encapsulation Extended Community or a barebones Tunnel TLV, one may use either or both. However, to ensure backwards compatibility with applications that do not support the Tunnel Encapsulation attribute, it is preferable to use the Encapsulation Extended Community. If the Extended Community (identifying a particular tunnel type) is present, the corresponding Tunnel TLV is optional. Note that for tunnel types of the form "X-in-Y", e.g., MPLS-in-GRE, the Encapsulation Extended Community implies that only packets of the specified payload type "X" are to be carried through the tunnel of type "Y". In the remainder of this specification, when we speak of a route as containing a Tunnel Encapsulation attribute with a TLV identifying a particular tunnel type, we are implicitly including the case where the route contains a Tunnel Encapsulation Extended Community identifying that tunnel type. 4.2. Router's MAC Extended Community [EVPN-Inter-Subnet] defines a Router's MAC Extended Community. This Extended Community provides information that may conflict with information in one or more of the Encapsulation Sub-TLVs of a Tunnel Rosen, et al. Expires January 18, 2018 [Page 22] Internet-Draft Tunnel Encapsulation Attribute July 2017 Encapsulation attribute. In case of such a conflict, the information in the Encapsulation Sub-TLV takes precedence. 4.3. Color Extended Community The Color Extended Community is a Transitive Opaque Extended Community with the following encoding: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x03 | 0x0b | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Color Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Color Extended Community For the use of this Extended Community please see Section 7. 5. Semantics and Usage of the Tunnel Encapsulation attribute [RFC5512] specifies the use of the Tunnel Encapsulation attribute in BGP UPDATE messages of AFI/SAFI 1/7 and 2/7. That document restricts the use of this attribute to UPDATE messsages of those SAFIs. This document removes that restriction. The BGP Tunnel Encapsulation attribute MAY be carried in any BGP UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6 Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast), 1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast), or 25/70 (Ethernet VPN, usually known as EVPN)). Use of the Tunnel Encapsulation attribute in BGP UPDATE messages of other AFI/SAFIs is outside the scope of this document. It has been suggested that it may sometimes be useful to attach a Tunnel Encapsulation attribute to a BGP UPDATE message that is also carrying a PMSI (Provider Multicast Service Interface) Tunnel attribute [RFC6514]. If the PMSI Tunnel attribute specifies an IP tunnel, the Tunnel Encapsulation attribute could be used to provide additional information about the IP tunnel. The usage of the Tunnel Encapsulation attribute in combination with the PMSI Tunnel attribute is outside the scope of this document. The decision to attach a Tunnel Encapsulation attribute to a given BGP UPDATE is determined by policy. The set of TLVs and sub-TLVs contained in the attribute is also determined by policy. Rosen, et al. Expires January 18, 2018 [Page 23] Internet-Draft Tunnel Encapsulation Attribute July 2017 When the Tunnel Encapsulation attribute is carried in an UPDATE of one of the AFI/SAFIs specified in the previous paragraph, each TLV MUST have a Remote Endpoint sub-TLV. If a TLV that does not have a Remote Endpoint sub-TLV, that TLV should be treated as if it had a malformed Remote Endpoint sub-TLV (see Section 3.1). Suppose that: o a given packet P must be forwarded by router R; o the path along which P is to be forwarded is determined by BGP UPDATE U; o UPDATE U has a Tunnel Encapsulation attribute, containing at least one TLV that identifies a "feasible tunnel" for packet P. A tunnel is considered feasible if it has the following three properties: * The tunnel type is supported (i.e., router R knows how to set up tunnels of that type, how to create the encapsulation header for tunnels of that type, etc.) * The tunnel is of a type that can be used to carry packet P (e.g., an MPLS-in-UDP tunnel would not be a feasible tunnel for carrying an IP packet, UNLESS the IP packet can first be converted to an MPLS packet). * The tunnel is specified in a TLV whose Remote Endpoint sub-TLV identifies an IP address that is reachable. Then router R SHOULD send packet P through one of the feasible tunnels identified in the Tunnel Encapsulation attribute of UPDATE U. If the Tunnel Encapsulation attribute contains several TLVs (i.e., if it specifies several tunnels), router R may choose any one of those tunnels, based upon local policy. If any of tunnels' TLVs contain the Color sub-TLV(Section 3.4.2) and/or the Protocol Type sub-TLV (Section 3.4.1, the choice of tunnel may be influenced by these sub- TLVs. Note that if none of the TLVs specifies the MPLS tunnel type, a Label Switched Path SHOULD NOT be used unless none of the TLVs specifies a feasible tunnel. If a particular tunnel is not feasible at some moment because its Remote Endpoint cannot be reached at that moment, the tunnel may become feasible at a later time (when its endpoint becomes reachable). Router R SHOULD take note of this. If router R is Rosen, et al. Expires January 18, 2018 [Page 24] Internet-Draft Tunnel Encapsulation Attribute July 2017 already using a different tunnel, it MAY switch to the tunnel that just became feasible, or it MAY decide to continue using the tunnel that it is already using. How this decision is made is outside the scope of this document. A TLV specifying a non-feasible tunnel is not considered to be malformed or erroneous in any way, and the TLV SHOULD NOT be stripped from the Tunnel Encapsulation attribute before redistribution. In addition to the sub-TLVs already defined, additional sub-TLVs may be defined that affect the choice of tunnel to be used, or that affect the contents of the tunnel encapsulation header. The documents that define any such additional sub-TLVs must specify the effect that including the sub-TLV is to have. Once it is determined to send a packet through the tunnel specified in a particular TLV of a particular Tunnel Encapsulation attribute, then the tunnel's remote endpoint address is the IP address contained in the sub-TLV. If the TLV contains a Remote Endpoint sub-TLV whose value field is all zeroes, then the tunnel's remote endpoint is the IP address specified as the Next Hop of the BGP Update containing the Tunnel Encapsulation attribute. The address of the remote endpoint generally appears in a "destination address" field of the encapsulation. The full set of procedures for sending a packet through a particular tunnel type to a particular remote endpoint depends upon the tunnel type, and is outside the scope of this document. Note that some tunnel types may require the execution of an explicit tunnel setup protocol before they can be used for carrying data. Other tunnel types may not require any tunnel setup protocol. Sending a packet through a tunnel always requires that the packet be encapsulated, with an encapsulation header that is appropriate for the tunnel type. The contents of the tunnel encapsulation header MAY be influenced by the Encapsulation sub-TLV. If there is no Encapsulation sub-TLV present, the router transmitting the packet through the tunnel must have a priori knowledge (e.g., by provisioning) of how to fill in the various fields in the encapsulation header. Whenever a new Tunnel Type TLV is defined, the specification of that TLV should describe (or reference) the procedures for creating the encapsulation header used to forward packets through that tunnel type. If a tunnel type codepoint is assigned in the IANA "BGP Tunnel Encapsulation Tunnel Types" registry, but there is no corresponding specification that defines an Encapsulation sub-TLV for that tunnel Rosen, et al. Expires January 18, 2018 [Page 25] Internet-Draft Tunnel Encapsulation Attribute July 2017 type, the transmitting endpoint of such a tunnel is presumed to know a priori how to form the encapsulation header for that tunnel type. If a Tunnel Encapsulation attribute specifies several tunnels, the way in which a router chooses which one to use is a matter of policy, subject to the following constraint: if a router can determine that a given tunnel is not functional, it MUST NOT use that tunnel. In particular, if the tunnel is identified in a TLV that has a Remote Endpoint sub-TLV, and if the IP address specified in the sub-TLV is not reachable from router R, then the tunnel SHOULD be considered non-functional. Other means of determining whether a given tunnel is functional MAY be used; specification of such means is outside the scope of this specification. Of course, if a non-functional tunnel later becomes functional, router R SHOULD reevaluate its choice of tunnels. If router R determines that it cannot use any of the tunnels specified in the Tunnel Encapsulation attribute, it MAY either drop packet P, or it MAY transmit packet P as it would had the Tunnel Encapsulation attribute not been present. This is a matter of local policy. By default, the packet SHOULD be transmitted as if the Tunnel Encapsulation attribute had not been present. A Tunnel Encapsulation attribute may contain several TLVs that all specify the same tunnel type. Each TLV should be considered as specifying a different tunnel. Two tunnels of the same type may have different Remote Endpoint sub-TLVs, different Encapsulation sub-TLVs, etc. Choosing between two such tunnels is a matter of local policy. Once router R has decided to send packet P through a particular tunnel, it encapsulates packet P appropriately and then forwards it according to the route that leads to the tunnel's remote endpoint. This route may itself be a BGP route with a Tunnel Encapsulation attribute. If so, the encapsulated packet is treated as the payload and is encapsulated according to the Tunnel Encapsulation attribute of that route. That is, tunnels may be "stacked". Notwithstanding anything said in this document, a BGP speaker MAY have local policy that influences the choice of tunnel, and the way the encapsulation is formed. A BGP speaker MAY also have a local policy that tells it to ignore the Tunnel Encapsulation attribute entirely or in part. Of course, interoperability issues must be considered when such policies are put into place. Rosen, et al. Expires January 18, 2018 [Page 26] Internet-Draft Tunnel Encapsulation Attribute July 2017 6. Routing Considerations 6.1. No Impact on BGP Decision Process The presence of the Tunnel Encapsulation attribute does not affect the BGP bestpath selection algorithm. Under certain circumstances, this may lead to counter-intuitive consequences. For example, suppose: o router R1 receives a BGP UPDATE message from router R2, such that * the NLRI of that UPDATE is prefix X, * the UPDATE contains a Tunnel Encapsulation attribute specifying two tunnels, T1 and T2, * R1 cannot use tunnel T1 or tunnel T2, either because the tunnel remote endpoint is not reachable or because R1 does not support that kind of tunnel o router R1 receives a BGP UPDATE message from router R3, such that * the NLRI of that UPDATE is prefix X, * the UPDATE contains a Tunnel Encapsulation attribute specifying two tunnels, T3 and T4, * R1 can use at least one of the two tunnels Since the Tunnel Encapsulation attribute does not affect bestpath selection, R1 may well install the route from R2 rather than the route from R3, even though R2's route contains no usable tunnels. This possibility must be kept in mind whenever a Remote Endpoint sub- TLV carried by a given UPDATE specifies an IP address that is different than the next hop of that UPDATE. 6.2. Looping, Infinite Stacking, Etc. Consider a packet destined for address X. Suppose a BGP UPDATE for address prefix X carries a Tunnel Encapsulation attribute that specifies a remote tunnel endpoint of Y. And suppose that a BGP UPDATE for address prefix Y carries a Tunnel Encapsulation attribute that specifies a Remote Endpoint of X. It is easy to see that this will cause an infinite number of encapsulation headers to be put on the given packet. Rosen, et al. Expires January 18, 2018 [Page 27] Internet-Draft Tunnel Encapsulation Attribute July 2017 This could happen as a result of misconfiguration, either accidental or intentional. It could also happen if the Tunnel Encapsulation attribute were altered by a malicious agent. Implementations should be aware of this. This document does not specify a maximum number of recursions; that is an implementation-specific matter. Improper setting (or malicious altering) of the Tunnel Encapsulation attribute could also cause data packets to loop. Suppose a BGP UPDATE for address prefix X carries a Tunnel Encapsulation attribute that specifies a remote tunnel endpoint of Y. Suppose router R receives and processes the update. When router R receives a packet destined for X, it will apply the encapsulation and send the encapsulated packet to Y. Y will decapsulate the packet and forward it further. If Y is further away from X than is router R, it is possible that the path from Y to X will traverse R. This would cause a long-lasting routing loop. The control plane itself cannot detect this situation, though a TTL field in the payload packets would presumably prevent any given packet from looping infinitely. These possibilities must also be kept in mind whenever the Remote Endpoint for a given prefix differs from the BGP next hop for that prefix. 7. Recursive Next Hop Resolution Suppose that: o a given packet P must be forwarded by router R1; o the path along which P is to be forwarded is determined by BGP UPDATE U1; o UPDATE U1 does not have a Tunnel Encapsulation attribute; o the next hop of UPDATE U1 is router R2; o the best path to router R2 is a BGP route that was advertised in UPDATE U2; o UPDATE U2 has a Tunnel Encapsulation attribute. Then packet P SHOULD be sent through one of the tunnels identified in the Tunnel Encapsulation attribute of UPDATE U2. See Section 5 for further details. However, suppose that one of the TLVs in U2's Tunnel Encapsulation attribute contains the Color Sub-TLV. In that case, packet P SHOULD NOT be sent through the tunnel identified in that TLV, unless U1 is Rosen, et al. Expires January 18, 2018 [Page 28] Internet-Draft Tunnel Encapsulation Attribute July 2017 carrying the Color Extended Community that is identified in U2's Color Sub-TLV. Note that if UPDATE U1 and UPDATE U2 both have Tunnel Encapsulation attributes, packet P will be carried through a pair of nested tunnels. P will first be encapsulated based on the Tunnel Encapsulation attribute of U1. This encapsulated packet then becomes the payload, and is encapsulated based on the Tunnel Encapsulation attribute of U2. This is another way of "stacking" tunnels (see also Section 5. The procedures in this section presuppose that U1's next hop resolves to a BGP route, and that U2's next hop resolves (perhaps after further recursion) to a non-BGP route. 8. Use of Virtual Network Identifiers and Embedded Labels when Imposing a Tunnel Encapsulation If the TLV specifying a tunnel contains an MPLS Label Stack sub-TLV, then when sending a packet through that tunnel, the procedures of Section 3.6 are applied before the procedures of this section. If the TLV specifying a tunnel contains a Prefix-SID sub-TLV, the procedures of Section 3.7 are applied before the procedures of this section. If the TLV also contains an MPLS Label Stack sub-TLV, the procedures of Section 3.6 are applied before the procedures of Section 3.7. 8.1. Tunnel Types without a Virtual Network Identifier Field If a Tunnel Encapsulation attribute is attached to an UPDATE of a labeled address family, there will be one or more labels specified in the UPDATE's NLRI. When a packet is sent through a tunnel specified in one of the attribute's TLVs, and that tunnel type does not contain a virtual network identifier field, the label or labels from the NLRI are pushed on the packet's label stack. The resulting MPLS packet is then further encapsulated, as specified by the TLV. 8.2. Tunnel Types with a Virtual Network Identifier Field Three of the tunnel types that can be specified in a Tunnel Encapsulation TLV have virtual network identifier fields in their encapsulation headers. In the VXLAN and VXLAN-GPE encapsulations, this field is called the VNI (Virtual Network Identifier) field; in the NVGRE encapsulation, this field is called the VSID (Virtual Subnet Identifier) field. Rosen, et al. Expires January 18, 2018 [Page 29] Internet-Draft Tunnel Encapsulation Attribute July 2017 When one of these tunnel encapsulations is imposed on a packet, the setting of the virtual network identifier field in the encapsulation header depends upon the contents of the Encapsulation sub-TLV (if one is present). When the Tunnel Encapsulation attribute is being carried on a BGP UPDATE of a labeled address family, the setting of the virtual network identifier field also depends upon the contents of the Embedded Label Handling sub-TLV (if present). This section specifies the procedures for choosing the value to set in the virtual network identifier field of the encapsulation header. These procedures apply only when the tunnel type is VXLAN, VXLAN-GPE, or NVGRE. 8.2.1. Unlabeled Address Families This sub-section applies when: o the Tunnel Encapsulation attribute is carried on a BGP UPDATE of an unlabeled address family, and o at least one of the attribute's TLVs identifies a tunnel type that uses a virtual network identifier, and o it has been determined to send a packet through one of those tunnels. If the TLV identifying the tunnel contains an Encapsulation sub-TLV whose V bit is set, the virtual network identifier field of the encapsulation header is set to the value of the virtual network identifier field of the Encapsulation sub-TLV. Otherwise, the virtual network identifier field of the encapsulation header is set to a configured value; if there is no configured value, the tunnel cannot be used. 8.2.2. Labeled Address Families This sub-section applies when: o the Tunnel Encapsulation attribute is carried on a BGP UPDATE of a labeled address family, and o at least one of the attribute's TLVs identifies a tunnel type that uses a virtual network identifier, and o it has been determined to send a packet through one of those tunnels. Rosen, et al. Expires January 18, 2018 [Page 30] Internet-Draft Tunnel Encapsulation Attribute July 2017 8.2.2.1. When a Valid VNI has been Signaled If the TLV identifying the tunnel contains an Encapsulation sub-TLV whose V bit is set, the virtual network identifier field of the encapsulation header is set as follows: o If the TLV contains an Embedded Label Handling sub-TLV whose value is 1, then the virtual network identifier field of the encapsulation header is set to the value of the virtual network identifier field of the Encapsulation sub-TLV. The embedded label (from the NLRI of the route that is carrying the Tunnel Encapsulation attribute) appears at the top of the MPLS label stack in the encapsulation payload. o If the TLV does not contain an Embedded Label Handling sub-TLV, or if contains an Embedded Label Handling sub-TLV whose value is 2, the embedded label is ignored entirely, and the virtual network identifier field of the encapsulation header is set to the value of the virtual network identifier field of the Encapsulation sub- TLV. 8.2.2.2. When a Valid VNI has not been Signaled If the TLV identifying the tunnel does not contain an Encapsulation sub-TLV whose V bit is set, the virtual network identifier field of the encapsulation header is set as follows: o If the TLV contains an Embedded Label Handling sub-TLV whose value is 1, then the virtual network identifier field of the encapsulation header is set to a configured value. If there is no configured value, the tunnel cannot be used. The embedded label (from the NLRI of the route that is carrying the Tunnel Encapsulation attribute) appears at the top of the MPLS label stack in the encapsulation payload. o If the TLV does not contain an Embedded Label Handling sub-TLV, or if it contains an Embedded Label Handling sub-TLV whose value is 2, the embedded label is copied into the virtual network identifier field of the encapsulation header. In this case, the payload may or may not contain an MPLS label stack, depending upon other factors. If the payload does contain an MPLS lable stack, the embedded label does not appear in that stack. Rosen, et al. Expires January 18, 2018 [Page 31] Internet-Draft Tunnel Encapsulation Attribute July 2017 9. Applicability Restrictions In a given UPDATE of a labeled address family, the label embedded in the NLRI is generally a label that is meaningful only to the router whose address appears as the next hop. Certain of the procedures of Section 8.2.2.1 or Section 8.2.2.2 cause the embedded label to be carried by a data packet to the router whose address appears in the Remote Endpoint sub-TLV. If the Remote Endpoint sub-TLV does not identify the same router that is the next hop, sending the packet through the tunnel may cause the label to be misinterpreted at the tunnel's remote endpoint. This may cause misdelivery of the packet. Therefore the embedded label MUST NOT be carried by a data packet traveling through a tunnel unless it is known that the label will be properly interpreted at the tunnel's remote endpoint. How this is known is outside the scope of this document. Note that if the Tunnel Encapsulation attribute is attached to a VPN- IP route [RFC4364], and if Inter-AS "option b" (see section 10 of [RFC4364] is being used, and if the Remote Endpoint sub-TLV contains an IP address that is not in same AS as the router receiving the route, it is very likely that the embedded label has been changed. Therefore use of the Tunnel Encapsulation attribute in an "Inter-AS option b" scenario is not supported. 10. Scoping The Tunnel Encapsulation attribute is defined as a transitive attribute, so that it may be passed along by BGP speakers that do not recognize it. However, it is intended that the Tunnel Encapsulation attribute be used only within a well-defined scope, e.g., within a set of Autonomous Systems that belong to a single administrative entity. If the attribute is distributed beyond its intended scope, packets may be sent through tunnels in a manner that is not intended. To prevent the Tunnel Encapsulation attribute from being distributed beyond its intended scope, any BGP speaker that understands the attribute MUST be able to filter the attribute from incoming BGP UPDATE messages. When the attribute is filtered from an incoming UPDATE, the attribute is neither processed nor redistributed. This filtering SHOULD be possible on a per-BGP-session basis. For each session, filtering of the attribute on incoming UPDATEs MUST be enabled by default. In addition, any BGP speaker that understands the attribute MUST be able to filter the attribute from outgoing BGP UPDATE messages. This filtering SHOULD be possible on a per-BGP-session basis. For each Rosen, et al. Expires January 18, 2018 [Page 32] Internet-Draft Tunnel Encapsulation Attribute July 2017 session, filtering of the attribute on outgoing UPDATEs MUST be enabled by default. 11. Error Handling The Tunnel Encapsulation attribute is a sequence of TLVs, each of which is a sequence of sub-TLVs. The final octet of a TLV is determined by its length field. Similarly, the final octet of a sub- TLV is determined by its length field. The final octet of a TLV MUST also be the final octet of its final sub-TLV. If this is not the case, the TLV MUST be considered to be malformed. A TLV that is found to be malformed for this reason MUST NOT be processed, and MUST be stripped from the Tunnel Encapsulation attribute before the attribute is propagated. Subsequent TLVs in the Tunnel Encapsulation attribute may still be valid, in which case they MUST be processed and redistributed normally. If a Tunnel Encapsulation attribute does not have any valid TLVs, or it does not have the transitive bit set, the "Attribute Discard" procedure of [RFC7606] is applied. If a Tunnel Encapsulation attribute can be parsed correctly, but contains a TLV whose tunnel type is not recognized by a particular BGP speaker, that BGP speaker MUST NOT consider the attribute to be malformed. Rather, the TLV with the unrecognized tunnel type MUST be ignored, and the BGP speaker MUST interpret the attribute as if that TLV had not been present. If the route carrying the Tunnel Encapsulation attribute is propagated with the attribute, the unrecognized TLV SHOULD remain in the attribute. If a TLV of a Tunnel Encapsulation attribute contains a sub-TLV that is not recognized by a particular BGP speaker, the BGP speaker SHOULD process that TLV as if the unrecognized sub-TLV had not been present. If the route carrying the Tunnel Encapsulation attribute is propagated with the attribute, the unrecognized TLV SHOULD remain in the attribute. If the type code of a sub-TLV appears as "reserved" in the IANA "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry, the sub-TLV MUST be treated as an unrecognized sub-TLV. In general, if a TLV contains a sub-TLV that is malformed (e.g., contains a length field whose value is not legal for that sub-TLV), the sub-TLV should be treated as if it were an unrecognized sub-TLV. This document specifies one exception to this rule -- if a TLV contains a malformed Remote Endpoint sub-TLV (as defined in Section 3.1, the entire TLV MUST be ignored, and SHOULD be removed Rosen, et al. Expires January 18, 2018 [Page 33] Internet-Draft Tunnel Encapsulation Attribute July 2017 from the Tunnel Encapsulation attribute before the route carrying that attribute is redistributed. A TLV that does not contain exactly one Remote Endpoint sub-TLV MUST be treated as if it contained a malformed Remote Endpoint sub-TLV. A TLV identifying a particular tunnel type may contain a sub-TLV that is meaningless for that tunnel type. For example, perhaps the TLV contains a "UDP Destination Port" sub-TLV, but the identified tunnel type does not use UDP encapsulation at all. Sub-TLVs of this sort SHOULD be treated as no-ops. That is, they SHOULD NOT affect the creation of the encapsulation header. However, the sub-TLV MUST NOT be considered to be malformed, and MUST NOT be removed from the TLV before the route carrying the Tunnel Encapsulation attribute is redistributed. (This allows for the possibility that such sub-TLVs may be given a meaning, in the context of the specified tunnel type, in the future.) There is no significance to the order in which the TLVs occur within the Tunnel Encapsulation attribute. Multiple TLVs may occur for a given tunnel type; each such TLV is regarded as describing a different tunnel. The following sub-TLVs defined in this document SHOULD NOT occur more than once in a given Tunnel TLV: Remote Endpoint (discussed above), Encapsulation, IPv4 DS, UDP Destination Port, Embedded Label Handling, MPLS Label Stack, Prefix-SID. If a Tunnel TLV has more than one of any of these sub-TLVs, all but the first occurrence of each such sub-TLV type MUST be treated as a no-op. However, the Tunnel TLV containing them MUST NOT be considered to be malformed, and all the sub-TLVs SHOULD be propagated if the route carrying the Tunnel Encapsulation attribute is propagated. The following sub-TLVs defined in this document may appear zero or more times in a given Tunnel TLV: Protocol Type, Color. Each occurrence of such sub-TLVs is meaningful. For example, the Color sub-TLV may appear multiple times to assign multiple colors to a tunnel. 12. IANA Considerations 12.1. Subsequent Address Family Identifiers IANA is requested to modify the "Subsequent Address Family Identifiers" registry to indicate that the Encapsulation SAFI is deprecated. This document should be the reference. Rosen, et al. Expires January 18, 2018 [Page 34] Internet-Draft Tunnel Encapsulation Attribute July 2017 12.2. BGP Path Attributes IANA has assigned value 23 from the "BGP Path Attributes" Registry, to "Tunnel Encapsulation Attribute". IANA is requested to add this document as a reference. 12.3. Extended Communities IANA has assigned values from the "Transitive Opaque Extended Community" type Registry to the "Color Extended Community" (sub-type 0x0b), and to the "Encapsulation Extended Community"(0x030c). IANA is requested to add this document as a reference for both assignments. 12.4. BGP Tunnel Encapsulation Attribute Sub-TLVs IANA is requested to add the following note to the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry: If the Sub-TLV Type is in the range from 1 to 127 inclusive, the Sub-TLV Length field contains one octet. If the Sub-TLV Type is in the range from 128-254 inclusive, the Sub-TLV Length field contains two octets. IANA is requested to change the registration policy of the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry to the following: o The values 0 and 255 are reserved. o The values in the range 1-63 and 128-191 are to be allocated using the "Standards Action" registration procedure. o The values in the range 64-125 and 192-252 are to be allocated using the "First Come, First Served" registration procedure. o The values in the range 126-127 and 253-254 are reserved for experimental use; IANA shall not allocate values from this range. IANA is requested to assign a codepoint, from the range 1-63 of the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry, for "Remote Endpoint", with this document being the reference. IANA is requested to assign a codepoint, from the range 1-63 of the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry, for "IPv4 DS Field", with this document being the reference. Rosen, et al. Expires January 18, 2018 [Page 35] Internet-Draft Tunnel Encapsulation Attribute July 2017 IANA is requested to assign a codepoint, from the range 1-63 of the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry for "UDP Destination Port", with this document being the reference. IANA is requested to assign a codepoint, from the range 1-63 of the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry, for "Embedded Label Handling", with this document being the reference. IANA is requested to assign a codepoint, from the range 1-63 of the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry, for "MPLS Label Stack", with this document being the reference. IANA is requested to assign a codepoint, from the range 1-63 of the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry, for "Prefix SID", with this document being the reference. IANA has assigned codepoints from the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry for "Encapsulation", "Protocol Type", and "Color". IANA is requested to add this document as a reference. 12.5. Tunnel Types IANA is requested to add this document as a reference for tunnel types 8 (VXLAN), 9 (NVGRE), 11 (MPLS-in-GRE), and 12 (VXLAN-GPE) in the "BGP Tunnel Encapsulation Tunnel Types" registry. IANA is requested to assign a codepoint from the "BGP Tunnel Encapsulation Tunnel Types" registry for "GTP". IANA is requested to add this document as a reference for tunnel types 1 (L2TPv3), 2 (GRE), and 7 (IP in IP) in the "BGP Tunnel Encapsulation Tunnel Types" registry. 13. Security Considerations The Tunnel Encapsulation attribute can cause traffic to be diverted from its normal path, especially when the Remote Endpoint sub-TLV is used. This can have serious consequences if the attribute is added or modified illegitimately, as it enables traffic to be "hijacked". The Remote Endpoint sub-TLV contains both an IP address and an AS number. BGP Origin Validation [RFC6811] can be used to obtain assurance that the given IP address belongs to the given AS. While this provides some protection against misconfiguration, it does not prevent a malicious agent from inserting a sub-TLV that will appear valid. Rosen, et al. Expires January 18, 2018 [Page 36] Internet-Draft Tunnel Encapsulation Attribute July 2017 Before sending a packet through the tunnel identified in a particular TLV of a Tunnel Encapsulation attribute, it may be advisable to use BGP Origin Validation to obtain the following additional assurances: o the origin AS of the route carrying the Tunnel Encapsulation attribute is correct; o the origin AS of the route to the IP address specified in the Remote Endpoint sub-TLV is correct, and is the same AS that is specified in the Remote Endpoint sub-TLV. One then has some level of assurance that the tunneled traffic is going to the same destination AS that it would have gone to had the Tunnel Encapsulation attribute not been present. However, this may not suit all use cases, and in any event is not very strong protection against hijacking. For these reasons, BGP Origin Validation should not be relied upon exclusively, and the filtering procedures of Section 10 should always be in place. Increased protection can be obtained by using BGP Path Validation [BGPSEC] to ensure that the route carrying the Tunnel Encapsulation attribute, and the routes to the Remote Endpoint of each specified tunnel, have not been altered illegitimately. If BGP Origin Validation is used as specified above, and the tunnel specified in a particular TLV of a Tunnel Encapsulation attribute is therefore regarded as "suspicious", that tunnel should not be used. Other tunnels specified in (other TLVs of) the Tunnel Encapsulation attribute may still be used. 14. Acknowledgments This document contains text from RFC5512, co-authored by Pradosh Mohapatra. The authors of the current document wish to thank Pradosh for his contribution. RFC5512 itself built upon prior work by Gargi Nalawade, Ruchi Kapoor, Dan Tappan, David Ward, Scott Wainner, Simon Barber, and Chris Metz, whom we also thank for their contributions. The authors wish to thank Lou Berger, Ron Bonica, Martin Djaernes, John Drake, Satoru Matsushima, Dhananjaya Rao, John Scudder, Ravi Singh, Thomas Morin, Xiaohu Xu, and Zhaohui Zhang for their review, comments, and/or helpful discussions. Rosen, et al. Expires January 18, 2018 [Page 37] Internet-Draft Tunnel Encapsulation Attribute July 2017 15. Contributor Addresses Below is a list of other contributing authors in alphabetical order: Randy Bush Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, Washington 98110 United States Email: randy@psg.com Robert Raszuk Bloomberg LP 731 Lexington Ave New York City, NY 10022 United States Email: robert@raszuk.net 16. References 16.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC 5512, DOI 10.17487/RFC5512, April 2009, <http://www.rfc-editor.org/info/rfc5512>. [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <http://www.rfc-editor.org/info/rfc7606>. 16.2. Informative References [BGPSEC] Lepinski, M. and S. Turner, "An Overview of BGPsec", internet-draft draft-ietf-sidr-bgpsec-overview-08, June 2016. Rosen, et al. Expires January 18, 2018 [Page 38] Internet-Draft Tunnel Encapsulation Attribute July 2017 [Ethertypes] "IANA Ethertype Registry", <http://www.iana.org/assignments/ieee-802-numbers/ ieee-802-numbers.xhtml>. [EVPN-Inter-Subnet] Sajassi, A., Salem, S., Thoria, S., Drake, J., Rabadan, J., and L. Yong, "Integrated Routing and Bridging in EVPN", internet-draft draft-ietf-bess-evpn-inter-subnet- forwarding-03, February 2017. [Prefix-SID-Attribute] Previdi, S., Filsfils, C., Lindem, A., Patel, K., Sreekantiah, A., Ray, S., and H. Gredler, "Segment Routing Prefix SID extensions for BGP", internet-draft draft-ietf- idr-bgp-prefix-sid-06, June 2017. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <http://www.rfc-editor.org/info/rfc2474>. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, <http://www.rfc-editor.org/info/rfc2784>. [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, DOI 10.17487/RFC2890, September 2000, <http://www.rfc-editor.org/info/rfc2890>. [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, <http://www.rfc-editor.org/info/rfc3032>. [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, DOI 10.17487/RFC3931, March 2005, <http://www.rfc-editor.org/info/rfc3931>. [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, <http://www.rfc-editor.org/info/rfc4023>. Rosen, et al. Expires January 18, 2018 [Page 39] Internet-Draft Tunnel Encapsulation Attribute July 2017 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>. [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2009, <http://www.rfc-editor.org/info/rfc5462>. [RFC5566] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel Encapsulation Attribute", RFC 5566, DOI 10.17487/RFC5566, June 2009, <http://www.rfc-editor.org/info/rfc5566>. [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, <http://www.rfc-editor.org/info/rfc6514>. [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, <http://www.rfc-editor.org/info/rfc6811>. [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, <http://www.rfc-editor.org/info/rfc7348>. [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, "Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/RFC7510, April 2015, <http://www.rfc-editor.org/info/rfc7510>. [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network Virtualization Using Generic Routing Encapsulation", RFC 7637, DOI 10.17487/RFC7637, September 2015, <http://www.rfc-editor.org/info/rfc7637>. [VXLAN-GPE] Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol Extension for VXLAN", internet-draft draft-ietf-nvo3- vxlan-gpe, April 2017. Rosen, et al. Expires January 18, 2018 [Page 40] Internet-Draft Tunnel Encapsulation Attribute July 2017 Authors' Addresses Eric C. Rosen (editor) Juniper Networks, Inc. 10 Technology Park Drive Westford, Massachusetts 01886 United States Email: erosen@juniper.net Keyur Patel Arrcus Email: keyur@arrcus.com Gunter Van de Velde Nokia Copernicuslaan 50 Antwerpen 2018 Belgium Email: gunter.van_de_velde@nokia.com Rosen, et al. Expires January 18, 2018 [Page 41]