draft-ietf-idr-tunnel-encaps-00.txt   draft-ietf-idr-tunnel-encaps-01.txt 
IDR Working Group E. Rosen, Ed. IDR Working Group E. Rosen, Ed.
Internet-Draft Juniper Networks, Inc. Internet-Draft Juniper Networks, Inc.
Updates: 5512 (if approved) K. Patel Obsoletes: 5512 (if approved) K. Patel
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: February 20, 2016 G. Van de Velde Expires: June 23, 2016 G. Van de Velde
Alcatel-Lucent Alcatel-Lucent
August 19, 2015 December 21, 2015
Using the BGP Tunnel Encapsulation Attribute without the BGP The BGP Tunnel Encapsulation Attribute
Encapsulation SAFI draft-ietf-idr-tunnel-encaps-01
draft-ietf-idr-tunnel-encaps-00
Abstract Abstract
RFC 5512 defines a BGP Path Attribute known as the "Tunnel RFC 5512 defines a BGP Path Attribute known as the "Tunnel
Encapsulation Attribute". This attribute allows one to specify a set Encapsulation Attribute". This attribute allows one to specify a set
of tunnels. For each such tunnel, the attribute can provide of tunnels. For each such tunnel, the attribute can provide the
additional information used to create a tunnel and the corresponding information needed to create the tunnel and the corresponding
encapsulation header, and can also provide information that aids in encapsulation header. The attribute can also provide information
choosing whether a particular packet is to be sent through a that aids in choosing whether a particular packet is to be sent
particular tunnel. RFC 5512 states that the attribute is only through a particular tunnel. RFC 5512 states that the attribute is
carried in BGP UPDATEs that have the "Encapsulation Subsequent only carried in BGP UPDATEs that have the "Encapsulation Subsequent
Address Family (Encapsulation SAFI)". This document updates RFC 5512 Address Family (Encapsulation SAFI)". This document deprecates the
by deprecating the Encapsulation SAFI (which has never been used),and Encapsulation SAFI (which has never been used), and specifies
by specifying semantics for the attribute when it is carried in semantics for the attribute when it is carried in UPDATEs of certain
UPDATEs of certain other SAFIs. This document also extends the other SAFIs. This document adds support for additional tunnel types,
attribute by enabling it to carry additional information needed to and allows a remote tunnel endpoint address to be specified for each
create the encapsulation headers additional tunnel types not tunnel. This document also provides support for specifying fields of
mentioned in RFC 5512. Finally, this document also extends the any inner or outer encapsulations that may be used by a particular
attribute by allowing it to specify a remote tunnel endpoint address tunnel.
for each tunnel.
This document obsoletes RFC 5512.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 20, 2016. This Internet-Draft will expire on June 23, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . . . . . 5 1.1. Brief Summary of RFC 5512 . . . . . . . . . . . . . . . . 4
2.1. The Remote Endpoint Sub-TLV . . . . . . . . . . . . . . . 5 1.2. Deficiencies in RFC 5512 . . . . . . . . . . . . . . . . 4
2.2. Encapsulation Sub-TLVs for Particular Tunnel Types . . . 8 1.3. Brief Summary of Changes from RFC 5512 . . . . . . . . . 5
2.2.1. VXLAN . . . . . . . . . . . . . . . . . . . . . . . . 8 2. The Tunnel Encapsulation Attribute . . . . . . . . . . . . . 6
2.2.2. VXLAN-GPE . . . . . . . . . . . . . . . . . . . . . . 9 3. Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . . . . . 7
2.2.3. NVGRE . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. The Remote Endpoint Sub-TLV . . . . . . . . . . . . . . . 7
2.2.4. GTP . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Encapsulation Sub-TLVs for Particular Tunnel Types . . . 10
2.2.5. MPLS-in-GRE . . . . . . . . . . . . . . . . . . . . . 12 3.2.1. VXLAN . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Outer Encapsulation Sub-TLVs . . . . . . . . . . . . . . 13 3.2.2. VXLAN-GPE . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1. IPv4 DS Field . . . . . . . . . . . . . . . . . . . . 13 3.2.3. NVGRE . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.2. UDP Destination Port . . . . . . . . . . . . . . . . 13 3.2.4. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . 13
2.4. Embedded Label Handling Sub-TLV . . . . . . . . . . . . . 14 3.2.5. GTP . . . . . . . . . . . . . . . . . . . . . . . . . 14
3. Tunnel Encapsulation Extended Community . . . . . . . . . . . 15 3.2.6. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Semantics and Usage of the Tunnel Encapsulation 3.2.7. MPLS-in-GRE . . . . . . . . . . . . . . . . . . . . . 15
attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.3. Outer Encapsulation Sub-TLVs . . . . . . . . . . . . . . 16
5. Routing Considerations . . . . . . . . . . . . . . . . . . . 18 3.3.1. IPv4 DS Field . . . . . . . . . . . . . . . . . . . . 17
5.1. No Impact on BGP Decision Process . . . . . . . . . . . . 18 3.3.2. UDP Destination Port . . . . . . . . . . . . . . . . 17
5.2. Looping, Infinite Stacking, Etc. . . . . . . . . . . . . 19 3.4. Sub-TLVs for Aiding Tunnel Selection . . . . . . . . . . 17
6. Recursive Next Hop Resolution . . . . . . . . . . . . . . . . 19 3.4.1. Protocol Type Sub-TLV . . . . . . . . . . . . . . . . 17
7. Use of Virtual Network Identifiers and Embedded Labels 3.4.2. Color Sub-TLV . . . . . . . . . . . . . . . . . . . . 18
when Imposing a Tunnel Encapsulation . . . . . . . . . . . . 20 3.5. Embedded Label Handling Sub-TLV . . . . . . . . . . . . . 18
7.1. Unlabeled Address Families . . . . . . . . . . . . . . . 20 3.6. MPLS Label Stack Sub-TLV . . . . . . . . . . . . . . . . 19
7.2. Labeled Address Families . . . . . . . . . . . . . . . . 21 3.7. Prefix-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 20
7.2.1. When a Valid VNI has been Signaled . . . . . . . . . 21 4. Extended Communities Related to the Tunnel Encapsulation
7.2.2. When a Valid VNI has not been Signaled . . . . . . . 22 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2.3. Applicability Restrictions . . . . . . . . . . . . . 22 4.1. Encapsulation Extended Community . . . . . . . . . . . . 21
8. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.2. Router's MAC Extended Community . . . . . . . . . . . . . 22
9. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 23 4.3. Color Extended Community . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 5. Semantics and Usage of the Tunnel Encapsulation
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 22
13. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 26 6. Routing Considerations . . . . . . . . . . . . . . . . . . . 26
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.1. No Impact on BGP Decision Process . . . . . . . . . . . . 26
14.1. Normative References . . . . . . . . . . . . . . . . . . 27 6.2. Looping, Infinite Stacking, Etc. . . . . . . . . . . . . 26
14.2. Informative References . . . . . . . . . . . . . . . . . 27 7. Recursive Next Hop Resolution . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 8. Use of Virtual Network Identifiers and Embedded Labels
when Imposing a Tunnel Encapsulation . . . . . . . . . . . . 28
8.1. Tunnel Types without a Virtual Network Identifier
Field . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.2. Tunnel Types with a Virtual Network Identifier Field . . 28
8.2.1. Unlabeled Address Families . . . . . . . . . . . . . 29
8.2.2. Labeled Address Families . . . . . . . . . . . . . . 29
8.2.2.1. When a Valid VNI has been Signaled . . . . . . . 29
8.2.2.2. When a Valid VNI has not been Signaled . . . . . 30
9. Applicability Restrictions . . . . . . . . . . . . . . . . . 30
10. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 31
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
12.1. Subsequent Address Family Identifiers . . . . . . . . . 33
12.2. BGP Path Attributes . . . . . . . . . . . . . . . . . . 33
12.3. Extended Communities . . . . . . . . . . . . . . . . . . 33
12.4. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . 33
12.5. Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 34
13. Security Considerations . . . . . . . . . . . . . . . . . . . 34
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
15. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 36
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
16.1. Normative References . . . . . . . . . . . . . . . . . . 36
16.2. Informative References . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
This document obsoletes RFC 5512. The deficiencies of RFC 5512, and
a summary of the changes made, are discussed in Sections 1.1-1.3.
The material from RFC 5512 that is retained has been incorporated
into this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL", when and only when appearing in all capital letters, are
to be interpreted as described in [RFC2119].
1.1. Brief Summary of RFC 5512
[RFC5512] defines a BGP Path Attribute known as the Tunnel [RFC5512] defines a BGP Path Attribute known as the Tunnel
Encapsulation attribute. This attribute consists of one or more Encapsulation attribute. This attribute consists of one or more
TLVs. Each TLV identifies a particular type of tunnel. Each TLV TLVs. Each TLV identifies a particular type of tunnel. Each TLV
also contains one or more sub-TLVs. Some of the sub-TLVs, e.g., the also contains one or more sub-TLVs. Some of the sub-TLVs, e.g., the
"Encapsulation sub-TLV", contain information that may be used to form "Encapsulation sub-TLV", contain information that may be used to form
the encapsulation header for the specified tunnel type. Other sub- the encapsulation header for the specified tunnel type. Other sub-
TLVs, e.g., the "color sub-TLV" and the "protocol sub-TLV", contain TLVs, e.g., the "color sub-TLV" and the "protocol sub-TLV", contain
information that aids in determining whether particular packets information that aids in determining whether particular packets
should be sent through the tunnel that the TLV identifies. should be sent through the tunnel that the TLV identifies.
skipping to change at page 3, line 48 skipping to change at page 4, line 40
o R1 has a packet, P, to transmit to destination D; o R1 has a packet, P, to transmit to destination D;
o R1's best path to D is a BGP route that has R2 as its next hop; o R1's best path to D is a BGP route that has R2 as its next hop;
In this scenario, when R1 transmits packet P, it should transmit it In this scenario, when R1 transmits packet P, it should transmit it
to R2 through one of the tunnels specified in U's Tunnel to R2 through one of the tunnels specified in U's Tunnel
Encapsulation attribute. The IP address of the remote endpoint of Encapsulation attribute. The IP address of the remote endpoint of
each such tunnel is R2. Packet P is known as the tunnel's "payload". each such tunnel is R2. Packet P is known as the tunnel's "payload".
1.2. Deficiencies in RFC 5512
While the ability to specify tunnel information in a BGP UPDATE is While the ability to specify tunnel information in a BGP UPDATE is
useful, the procedures of [RFC5512] have certain limitations: useful, the procedures of [RFC5512] have certain limitations:
o The requirement to use the "Encapsulation SAFI" presents an o The requirement to use the "Encapsulation SAFI" presents an
unfortunate operational cost, as each BGP session that may need to unfortunate operational cost, as each BGP session that may need to
carry tunnel encapsulation information needs to be reconfigured to carry tunnel encapsulation information needs to be reconfigured to
support the Encapsulation SAFI. The Encapsulation SAFI has never support the Encapsulation SAFI. The Encapsulation SAFI has never
been used, and this requirement has served only to discourage the been used, and this requirement has served only to discourage the
use of the Tunnel Encapsulation attribute. use of the Tunnel Encapsulation attribute.
o There is no way to use the Tunnel Encapsulation attribute to o There is no way to use the Tunnel Encapsulation attribute to
specify the remote endpoint address of a given tunnel; [RFC5512] specify the remote endpoint address of a given tunnel; [RFC5512]
assumes that the remote endpoint of each tunnel is specified as assumes that the remote endpoint of each tunnel is specified as
the NLRI of an UPDATE of the Encapsulation-SAFI. the NLRI of an UPDATE of the Encapsulation-SAFI.
o If the respective best paths to two different address prefixes o If the respective best paths to two different address prefixes
have the same next hop, [RFC5512] does not provide a have the same next hop, [RFC5512] does not provide a
straightforward method to associate each prefix with a different straightforward method to associate each prefix with a different
tunnel. tunnel.
o If a particular tunnel type requires an outer IP or UDP
encapsulation, there is no way to signal the values of any of the
fields of the outer encapsulation.
1.3. Brief Summary of Changes from RFC 5512
In this document we address these deficiencies by: In this document we address these deficiencies by:
o Deprecating the Encapsulation SAFI. o Deprecating the Encapsulation SAFI.
o Defining a new "Remote Endpoint Address sub-TLV" that can be o Defining a new "Remote Endpoint Address sub-TLV" that can be
included in any of the TLVs contained in the Tunnel Encapsulation included in any of the TLVs contained in the Tunnel Encapsulation
attribute. This sub-TLV can be used to specify the remote attribute. This sub-TLV can be used to specify the remote
endpoint address of a particular tunnel. endpoint address of a particular tunnel.
o Allowing the Tunnel Encapsulation attribute to be carried by BGP o Allowing the Tunnel Encapsulation attribute to be carried by BGP
UPDATEs of additional AFI/SAFIs. Appropriate semantics are UPDATEs of additional AFI/SAFIs. Appropriate semantics are
provided for this way of using the attribute. provided for this way of using the attribute.
o Defining a number of new sub-TLVs that provide additional
information that is useful when forming the encapsulation header
used to send a packet through a particular tunnel.
One of the sub-TLVs defined in [RFC5512] is the "Encapsulation sub- One of the sub-TLVs defined in [RFC5512] is the "Encapsulation sub-
TLV". For a given tunnel, the encapsulation sub-TLV specifies some TLV". For a given tunnel, the encapsulation sub-TLV specifies some
of the information needed to construct the encapsulation header used of the information needed to construct the encapsulation header used
when sending packets through that tunnel. This document defines when sending packets through that tunnel. This document defines
encapsulation sub-TLVs for a number of tunnel types not discussed in encapsulation sub-TLVs for a number of tunnel types not discussed in
[RFC5512]: VXLAN, VXLAN-GPE, NVGRE, GTP, and MPLS-in-GRE. MPLS-in- [RFC5512]: VXLAN, VXLAN-GPE, NVGRE, GTP, and MPLS-in-GRE. MPLS-in-
UDP [RFC7510] is also supported, but an Encapsulation sub-TLV for it UDP [RFC7510] is also supported, but an Encapsulation sub-TLV for it
is not needed. is not needed.
Some of the encapsulations mentioned in the previous paragraph need Some of the encapsulations mentioned in the previous paragraph need
skipping to change at page 5, line 20 skipping to change at page 6, line 23
using sub-TLVs of the Tunnel Encapsulation attribute) how one wants using sub-TLVs of the Tunnel Encapsulation attribute) how one wants
to use the embedded label when the tunnel encapsulation has its own to use the embedded label when the tunnel encapsulation has its own
virtual network identifier field. virtual network identifier field.
[RFC5512] defines a Tunnel Encapsulation Extended Community, that can [RFC5512] defines a Tunnel Encapsulation Extended Community, that can
be used instead of the Tunnel Encapsulation attribute under certain be used instead of the Tunnel Encapsulation attribute under certain
circumstances. This document addresses the issue of how to handle a circumstances. This document addresses the issue of how to handle a
BGP UPDATE that carries both a Tunnel Encapsulation attribute and one BGP UPDATE that carries both a Tunnel Encapsulation attribute and one
or more Tunnel Encapsulation Extended Communities. or more Tunnel Encapsulation Extended Communities.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 2. The Tunnel Encapsulation Attribute
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL", when and only when appearing in all capital letters, are
to be interpreted as described in [RFC2119].
2. Tunnel Encapsulation Attribute Sub-TLVs The Tunnel Encapsulation attribute is an optional transitive BGP Path
attribute. IANA has assigned the value 23 as the type code of the
attribute. The attribute is composed of a set of Type-Length-Value
(TLV) encodings. Each TLV contains information corresponding to a
particular tunnel type. A TLV is structured as follows:
[RFC5512] specifies three sub-TLVs for the Tunnel Encapsulation 0 1 2 3
attribute: the Encapsulation sub-TLV, the Color sub-TLV, and the 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
Protocol Type sub-TLV. In this section we specify a number of +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
additional sub-TLVs. We also specify Encapsulation sub-TLVs for a | Tunnel Type (2 Octets) | Length (2 Octets) |
number of tunnel types that are not mentioned in [RFC5512]. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1. The Remote Endpoint Sub-TLV Figure 1: Tunnel Encapsulation TLV Value Field
o Tunnel Type (2 octets): identifies a type of tunnel. The field
contains values from the IANA Registry "BGP Tunnel Encapsulation
Attribute Tunnel Types".
Note that for tunnel types whose names are of the form "X-in-Y",
e.g., "MPLS-in-GRE", only packets of the specified payload type
"X" are to be carried through the tunnel of type "Y". This is the
equivalent of specifying a tunnel type "Y" and including in its
TLV a Protocol Type sub-TLV (see Section 3.4.1 specifying protocol
"X".
o Length (2 octets): the total number of octets of the value field.
o Value (variable): comprised of multiple sub-TLVs.
Each sub-TLV consists of three fields: a 1-octet type, 1-octet
length, and zero or more octets of value. A sub-TLV is structured as
follows:
+-----------------------------------+
| Sub-TLV Type (1 Octet) |
+-----------------------------------+
| Sub-TLV Length (1 Octet) |
+-----------------------------------+
| Sub-TLV Value (Variable) |
| |
+-----------------------------------+
Figure 2: Tunnel Encapsulation Sub-TLV Format
o Sub-TLV Type (1 octet): each sub-TLV type defines a certain
property about the tunnel TLV that contains this sub-TLV.
o Sub-TLV Length (1 octet): the total number of octets of the sub-
TLV value field.
o Sub-TLV Value (variable): encodings of the value field depend on
the sub-TLV type as enumerated above. The following sub-sections
define the encoding in detail.
3. Tunnel Encapsulation Attribute Sub-TLVs
In this section, we specify a number of sub-TLVs. These sub-TLVs can
be included in a TLV of the Tunnel Encapsulation attribute.
3.1. The Remote Endpoint Sub-TLV
The Remote Endpoint sub-TLV is a sub-TLV whose value field contains The Remote Endpoint sub-TLV is a sub-TLV whose value field contains
three sub-fields: three sub-fields:
1. a four-octet Autonomous System (AS) number sub-field 1. a four-octet Autonomous System (AS) number sub-field
2. a two-octet Address Family sub-field 2. a two-octet Address Family sub-field
3. an address sub-field, whose length depends upon the Address 3. an address sub-field, whose length depends upon the Address
Family. Family.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Autonomous System Number | | Autonomous System Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Address ~ | Address Family | Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Remote Endpoint Sub-TLV Value Field Figure 3: Remote Endpoint Sub-TLV Value Field
The Address Family subfield contains a value from IANA's "Address The Address Family subfield contains a value from IANA's "Address
Family Numbers" registry. In this document, we assume that the Family Numbers" registry. In this document, we assume that the
Address Family is either IPv4 or IPv6; use of other address families Address Family is either IPv4 or IPv6; use of other address families
is outside the scope of this document. is outside the scope of this document.
If the Address Family subfield contains the value for IPv4, the If the Address Family subfield contains the value for IPv4, the
address subfield must contain an IPv4 address (a /32 IPv4 prefix). address subfield must contain an IPv4 address (a /32 IPv4 prefix).
In this case, the length field of Remote Endpoint sub-TLV must In this case, the length field of Remote Endpoint sub-TLV must
contain the value 10 (0xa). IPv4 broadcast addresses are not valid contain the value 10 (0xa). IPv4 broadcast addresses are not valid
skipping to change at page 7, line 27 skipping to change at page 9, line 27
o The sub-TLV contains the value zero in its Address Family field, o The sub-TLV contains the value zero in its Address Family field,
but the length of the sub-TLV's value field is other than 6, or but the length of the sub-TLV's value field is other than 6, or
the Autonomous System subfield is not set to zero. the Autonomous System subfield is not set to zero.
o The IP address in the sub-TLV's address subfield is not a valid IP o The IP address in the sub-TLV's address subfield is not a valid IP
address (e.g., it's an IPv4 broadcast address). address (e.g., it's an IPv4 broadcast address).
o It can be determined that the IP address in the sub-TLV's address o It can be determined that the IP address in the sub-TLV's address
subfield does not belong to the non-zero AS whose number is in the subfield does not belong to the non-zero AS whose number is in the
its Autonomous System subfield. (See section Section 11 for its Autonomous System subfield. (See section Section 13 for
discussion of one way to determine this.) discussion of one way to determine this.)
If the Remote Endpoint sub-TLV is malformed, the TLV containing it is If the Remote Endpoint sub-TLV is malformed, the TLV containing it is
also considered to be malformed, and the entire TLV MUST be ignored. also considered to be malformed, and the entire TLV MUST be ignored.
However, the Tunnel Encapsulation attribute SHOULD NOT be considered However, the Tunnel Encapsulation attribute SHOULD NOT be considered
to be malformed in this case; other TLVs in the attribute SHOULD be to be malformed in this case; other TLVs in the attribute SHOULD be
processed (if they can be parsed correctly). processed (if they can be parsed correctly).
When redistributing a route that is carrying a Tunnel Encapsulation When redistributing a route that is carrying a Tunnel Encapsulation
attribute containing a TLV that itself contains a malformed Remote attribute containing a TLV that itself contains a malformed Remote
Endpoint sub-TLV, the TLV SHOULD be removed from the attribute before Endpoint sub-TLV, the TLV SHOULD be removed from the attribute before
redistribution. redistribution.
See Section 9 for further discussion of how to handle errors that are See Section 11 for further discussion of how to handle errors that
encountered when parsing the Tunnel Encapsulation attribute. are encountered when parsing the Tunnel Encapsulation attribute.
If the Remote Endpoint sub-TLV contains an IPv4 or IPv6 address that If the Remote Endpoint sub-TLV contains an IPv4 or IPv6 address that
is valid but not reachable, the sub-TLV is NOT considered to be is valid but not reachable, the sub-TLV is NOT considered to be
malformed, and the containing TLV SHOULD NOT be removed from the malformed, and the containing TLV SHOULD NOT be removed from the
attribute before redistribution. However, the tunnel identified by attribute before redistribution. However, the tunnel identified by
the TLV containing that sub-TLV cannot be used until such time as the the TLV containing that sub-TLV cannot be used until such time as the
address becomes reachable. See Section 4. address becomes reachable. See Section 5.
2.2. Encapsulation Sub-TLVs for Particular Tunnel Types
Tunnel Encapsulation sub-TLVs for the following tunnel types are 3.2. Encapsulation Sub-TLVs for Particular Tunnel Types
defined in [RFC5512]: L2TPv3, and GRE.
This section defines Tunnel Encapsulation sub-TLVs for the following This section defines Tunnel Encapsulation sub-TLVs for the following
tunnel types: VXLAN ([RFC7348]), VXLAN-GPE ([VXLAN-GPE]), NVGRE tunnel types: VXLAN ([RFC7348]), VXLAN-GPE ([VXLAN-GPE]), NVGRE
([NVGRE]), GTP [GTP-U], and MPLS-in-GRE ([RFC2784], [RFC2890], ([RFC7637]), GTP ([GTP-U]), MPLS-in-GRE ([RFC2784], [RFC2890],
[RFC4023]), L2TPv3 ([RFC3931]), and GRE ([RFC2784], [RFC2890],
[RFC4023]). [RFC4023]).
Rules for forming the encapsulation based on the information in a Rules for forming the encapsulation based on the information in a
given TLV are given in Section 7. given TLV are given in Section 8. For some tunnel types, the rules
are obvious and not mentioned in this document. There are also
tunnel types for which it is not necessary to define an Encapsulation
sub-TLV.
2.2.1. VXLAN 3.2.1. VXLAN
This document defines an encapsulation sub-TLV for VXLAN tunnels. This document defines an encapsulation sub-TLV for VXLAN tunnels.
When the tunnel type is VXLAN, the following is the structure of the When the tunnel type is VXLAN, the following is the structure of the
value field in the encapsulation sub-TLV: value field in the encapsulation sub-TLV:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V|M|R|R|R|R|R|R| VN-ID (3 Octets) | |V|M|R|R|R|R|R|R| VN-ID (3 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (4 Octets) | | MAC Address (4 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (2 Octets) | Reserved | | MAC Address (2 Octets) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: VXLAN Encapsulation Sub-TLV Figure 4: VXLAN Encapsulation Sub-TLV
V: This bit is set to 1 to indicate that a valid VN-ID is present V: This bit is set to 1 to indicate that a "valid" VN-ID is
in the encapsulation sub-TLV. present in the encapsulation sub-TLV. Please see Section 8.
M: This bit is set to 1 to indicate that a valid MAC Address is M: This bit is set to 1 to indicate that a valid MAC Address is
present in the encapsulation sub-TLV. present in the encapsulation sub-TLV.
R: The remaining bits in the 8-bit flags field are reserved for R: The remaining bits in the 8-bit flags field are reserved for
further use. They SHOULD always be set to 0. further use. They SHOULD always be set to 0.
VN-ID: If the V bit is set, the VN-id field contains a 3 octet VN- VN-ID: If the V bit is set, the VN-id field contains a 3 octet VN-
ID value. If the V bit is not set, the VN-id field SHOULD be set ID value. If the V bit is not set, the VN-id field SHOULD be set
to zero. to zero.
skipping to change at page 9, line 30 skipping to change at page 11, line 34
If the M bit is not set, and the payload being sent through the If the M bit is not set, and the payload being sent through the
VXLAN tunnel is an ethernet frame, the Destination MAC Address VXLAN tunnel is an ethernet frame, the Destination MAC Address
field of the Inner Ethernet Header is just the Destination MAC field of the Inner Ethernet Header is just the Destination MAC
Address field of the payload's ethernet header. Address field of the payload's ethernet header.
If the M bit is not set, and the payload being sent through the If the M bit is not set, and the payload being sent through the
VXLAN tunnel is an IP or MPLS packet, the Inner Destination MAC VXLAN tunnel is an IP or MPLS packet, the Inner Destination MAC
address field is set to a configured value; if there is no address field is set to a configured value; if there is no
configured value, the VXLAN tunnel cannot be used. configured value, the VXLAN tunnel cannot be used.
o See Section 7 to see how the VNI field of the VXLAN encapsulation o See Section 8 to see how the VNI field of the VXLAN encapsulation
header is set. header is set.
2.2.2. VXLAN-GPE 3.2.2. VXLAN-GPE
This document defines an encapsulation sub-TLV for VXLAN tunnels. This document defines an encapsulation sub-TLV for VXLAN tunnels.
When the tunnel type is VXLAN-GPE, the following is the structure of When the tunnel type is VXLAN-GPE, the following is the structure of
the value field in the encapsulation sub-TLV: the value field in the encapsulation sub-TLV:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|V|R|R|R|R|R| Reserved | |Ver|V|R|R|R|R|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VN-ID | Reserved | | VN-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: VXLAN GPE Encapsulation Sub-TLV Figure 5: VXLAN GPE Encapsulation Sub-TLV
V: This bit is set to 1 to indicate that a valid VN-ID is present V: This bit is set to 1 to indicate that a "valid" VN-ID is
in the encapsulation sub-TLV. present in the encapsulation sub-TLV. Please see Section 8.
R: The bits designated "R" above are reserved for future use. R: The bits designated "R" above are reserved for future use.
They SHOULD always be set to zero. They SHOULD always be set to zero.
Version (Ver): Indicates VXLAN GPE protocol version. If the Version (Ver): Indicates VXLAN GPE protocol version. If the
indicated version is not supported, the TLV that contains this indicated version is not supported, the TLV that contains this
Encapsulation sub-TLV MUST be treated as specifying an unsupported Encapsulation sub-TLV MUST be treated as specifying an unsupported
tunnel type. The value of this field will be copied into the tunnel type. The value of this field will be copied into the
corresponding field of the VXLAN encapsulation header. corresponding field of the VXLAN encapsulation header.
VN-ID: If the V bit is set, this field contains a 3 octet VN-ID VN-ID: If the V bit is set, this field contains a 3 octet VN-ID
value. If the V bit is not set, this field SHOULD be set to zero. value. If the V bit is not set, this field SHOULD be set to zero.
When forming the VXLAN-GPE encapsulation header: When forming the VXLAN-GPE encapsulation header:
o The values of the V and R bits are NOT copied into the flags field o The values of the V and R bits are NOT copied into the flags field
of the VXLAN-GPE header. However, the values of the Ver bits are of the VXLAN-GPE header. However, the values of the Ver bits are
copied into the VXLAN-GPE header. Other bits in the flags field copied into the VXLAN-GPE header. Other bits in the flags field
of the VXLAN-GPE header are set as per [VXLAN-GPE]. of the VXLAN-GPE header are set as per [VXLAN-GPE].
o See Section 7 to see how the VNI field of the VXLAN-GPE o See Section 8 to see how the VNI field of the VXLAN-GPE
encapsulation header is set. encapsulation header is set.
2.2.3. NVGRE 3.2.3. NVGRE
This document defines an encapsulation sub-TLV for NVGRE tunnels. This document defines an encapsulation sub-TLV for NVGRE tunnels.
When the tunnel type is NVGRE, the following is the structure of the When the tunnel type is NVGRE, the following is the structure of the
value field in the encapsulation sub-TLV: value field in the encapsulation sub-TLV:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V|M|R|R|R|R|R|R| VN-ID (3 Octets) | |V|M|R|R|R|R|R|R| VN-ID (3 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (4 Octets) | | MAC Address (4 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (2 Octets) | Reserved | | MAC Address (2 Octets) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: NVGRE Encapsulation Sub-TLV Figure 6: NVGRE Encapsulation Sub-TLV
V: This bit is set to 1 to indicate that a valid VN-ID is present V: This bit is set to 1 to indicate that a "valid" VN-ID is
in the encapsulation sub-TLV. present in the encapsulation sub-TLV. Please see Section 8.
M: This bit is set to 1 to indicate that a valid MAC Address is M: This bit is set to 1 to indicate that a valid MAC Address is
present in the encapsulation sub-TLV. present in the encapsulation sub-TLV.
R: The remaining bits in the 8-bit flags field are reserved for R: The remaining bits in the 8-bit flags field are reserved for
further use. They SHOULD always be set to 0. further use. They SHOULD always be set to 0.
VN-ID: If the V bit is set, the VN-id field contains a 3 octet VN- VN-ID: If the V bit is set, the VN-id field contains a 3 octet VN-
ID value. If the V bit is not set, the VN-id field SHOULD be set ID value. If the V bit is not set, the VN-id field SHOULD be set
to zero. to zero.
MAC Address: If the M bit is set, this field contains a 6 octet MAC Address: If the M bit is set, this field contains a 6 octet
Ethernet MAC address. If the M bit is not set, this field SHOULD Ethernet MAC address. If the M bit is not set, this field SHOULD
be set to all zeroes. be set to all zeroes.
When forming the NVGRE encapsulation header: When forming the NVGRE encapsulation header:
o The values of the V, M, and R bits are NOT copied into the flags o The values of the V, M, and R bits are NOT copied into the flags
field of the NVGRE header. The flags field of the VXLAN header is field of the NVGRE header. The flags field of the VXLAN header is
set as per [NVGRE]. set as per [RFC7637].
o If the M bit is set, the MAC Address is copied into the Inner o If the M bit is set, the MAC Address is copied into the Inner
Destination MAC Address field of the Inner Ethernet Header (see Destination MAC Address field of the Inner Ethernet Header (see
section 3.2 of [NVGRE]. section 3.2 of [RFC7637].
If the M bit is not set, and the payload being sent through the If the M bit is not set, and the payload being sent through the
NVGRE tunnel is an ethernet frame, the Destination MAC Address NVGRE tunnel is an ethernet frame, the Destination MAC Address
field of the Inner Ethernet Header is just the Destination MAC field of the Inner Ethernet Header is just the Destination MAC
Address field of the payload's ethernet header. Address field of the payload's ethernet header.
If the M bit is not set, and the payload being sent through the If the M bit is not set, and the payload being sent through the
NVGRE tunnel is an IP or MPLS packet, the Inner Destination MAC NVGRE tunnel is an IP or MPLS packet, the Inner Destination MAC
address field is set to a configured value; if there is no address field is set to a configured value; if there is no
configured value, the NVGRE tunnel cannot be used. configured value, the NVGRE tunnel cannot be used.
o See Section 7 to see how the VSID field of the NVGRE encapsulation o See Section 8 to see how the VSID field of the NVGRE encapsulation
header is set. header is set.
2.2.4. GTP 3.2.4. L2TPv3
When the tunnel type of the TLV is L2TPv3 over IP, the following is
the structure of the value field of the encapsulation sub-TLV:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Cookie (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: L2TPv3 Encapsulation Sub-TLV
Session ID: a non-zero 4-octet value locally assigned by the
advertising router that serves as a lookup key in the incoming
packet's context.
Cookie: an optional, variable length (encoded in octets -- 0 to 8
octets) value used by L2TPv3 to check the association of a
received data message with the session identified by the Session
ID. Generation and usage of the cookie value is as specified in
[RFC3931].
The length of the cookie is not encoded explicitly, but can be
calculated as (sub-TLV length - 4).
3.2.5. GTP
When the tunnel type is GTP [GTP-U], the Encapsulation sub-TLV When the tunnel type is GTP [GTP-U], the Encapsulation sub-TLV
contains information needed to send data packets through a GTP contains information needed to send data packets through a GTP
tunnel, and also contains information needed by the tunnel's remote tunnel, and also contains information needed by the tunnel's remote
endpoint to create a "reverse" tunnel back to the transmitter. This endpoint to create a "reverse" tunnel back to the transmitter. This
allows a bidirectional control connection to be created. The format allows a bidirectional control connection to be created. The format
of the Encapsulation Sub-TLV is: of the Encapsulation Sub-TLV is:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote TEID (4 Octets) | | Remote TEID (4 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local TEID (4 Octets) | | Local TEID (4 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Endpoint Address (4/16 Octets (IPv4/IPv6)) | | Local Endpoint Address (4/16 Octets (IPv4/IPv6)) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: GTP Encapsulation Sub-TLV Figure 8: GTP Encapsulation Sub-TLV
Remote TEID: Contains the 32-bit Tunnel Endpoint Identifier of the Remote TEID: Contains the 32-bit Tunnel Endpoint Identifier of the
GTP tunnel through which data packets are to be sent. When data GTP tunnel through which data packets are to be sent. When data
packets are sent through the tunnel, the Remote TEID is carried in packets are sent through the tunnel, the Remote TEID is carried in
the GTP encapsulation header. The GTP header is itself the GTP encapsulation header. The GTP header is itself
encapsulation within an IP header, whose IP destination address encapsulation within an IP header, whose IP destination address
field is set to the value of the Remote Endpoint sub-TLV. field is set to the value of the Remote Endpoint sub-TLV.
Local TEID: Contains a 32-bit Tunnel Endpoint Identifier of a GTP Local TEID: Contains a 32-bit Tunnel Endpoint Identifier of a GTP
tunnel assigned by EPC ([vEPC]). tunnel assigned by EPC ([vEPC]).
Local Endpoint Address: Contains an IPv4 or IPv6 anycast address. Local Endpoint Address: Contains an IPv4 or IPv6 anycast address.
This is used, along with the Local TEID, to set up a tunnel in the This is used, along with the Local TEID, to set up a tunnel in the
reverse direction. See [vEPC] for details. reverse direction. See [vEPC] for details.
2.2.5. MPLS-in-GRE 3.2.6. GRE
When the tunnel type of the TLV is GRE, the following is the
structure of the value field of the encapsulation sub-TLV:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Key (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: GRE Encapsulation Sub-TLV
GRE Key: 4-octet field [RFC2890] that is generated by the
advertising router. The actual method by which the key is
obtained is beyond the scope of this document. The key is
inserted into the GRE encapsulation header of the payload packets
sent by ingress routers to the advertising router. It is intended
to be used for identifying extra context information about the
received payload.
Note that the key is optional. Unless a key value is being
advertised, the GRE encapsulation sub-TLV MUST NOT be present.
3.2.7. MPLS-in-GRE
When the tunnel type is MPLS-in-GRE, the following is the structure When the tunnel type is MPLS-in-GRE, the following is the structure
of the value field in an optional encapsulation sub-TLV: of the value field in an optional encapsulation sub-TLV:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE-Key (4 Octets) | | GRE-Key (4 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: MPLS-in-GRE Encapsulation Sub-TLV Figure 10: MPLS-in-GRE Encapsulation Sub-TLV
GRE-Key: 4-octet field [RFC2890] that is generated by the GRE-Key: 4-octet field [RFC2890] that is generated by the
advertising router. The actual method by which the key is advertising router. The actual method by which the key is
obtained is beyond the scope of this document. The key is obtained is beyond the scope of this document. The key is
inserted into the GRE encapsulation header of the payload packets inserted into the GRE encapsulation header of the payload packets
sent by ingress routers to the advertising router. It is intended sent by ingress routers to the advertising router. It is intended
to be used for identifying extra context information about the to be used for identifying extra context information about the
received payload. Note that the key is optional. Unless a key received payload. Note that the key is optional. Unless a key
value is being advertised, the MPLS-in-GRE encapsulation sub-TLV value is being advertised, the MPLS-in-GRE encapsulation sub-TLV
MUST NOT be present. MUST NOT be present.
Note that the GRE tunnel type defined in [RFC5512] can be used Note that the GRE tunnel type defined in Section 3.2.6 can be used
instead of the MPLS-in-GRE tunnel type when it is necessary to instead of the MPLS-in-GRE tunnel type when it is necessary to
encapsulate MPLS in GRE. Including a TLV of the MPLS-in-GRE tunnel encapsulate MPLS in GRE. Including a TLV of the MPLS-in-GRE tunnel
type is equivalent to including a TLV of the GRE tunnel type that type is equivalent to including a TLV of the GRE tunnel type that
also includes a Protocol Type sub-TLV ([RFC5512]) specifying MPLS as also includes a Protocol Type sub-TLV ([RFC5512]) specifying MPLS as
the protocol to be encapsulated. That is, if a TLV specifies MPLS- the protocol to be encapsulated. That is, if a TLV specifies MPLS-
in-GRE or if it includes a Protocol Type sub-TLV specifying MPLS, the in-GRE or if it includes a Protocol Type sub-TLV specifying MPLS, the
GRE tunnel advertised in that TLV MUST NOT be used for carrying IP GRE tunnel advertised in that TLV MUST NOT be used for carrying IP
packets. packets.
2.3. Outer Encapsulation Sub-TLVs While it is not really necessary to have both the GRE and MPLS-in-GRE
tunnel types, both are included for reasons of backwards
compatibility.
3.3. Outer Encapsulation Sub-TLVs
The Encapsulation sub-TLV for a particular tunnel type allows one to The Encapsulation sub-TLV for a particular tunnel type allows one to
specify the values that are to be placed in certain fields of the specify the values that are to be placed in certain fields of the
encapsulation header for that tunnel type. However, some tunnel encapsulation header for that tunnel type. However, some tunnel
types require an outer IP encapsulation, and some also require an types require an outer IP encapsulation, and some also require an
outer UDP encapsulation. The Encapsulation sub-TLV for a given outer UDP encapsulation. The Encapsulation sub-TLV for a given
tunnel type does not usually provide a way to specify values for tunnel type does not usually provide a way to specify values for
fields of the outer IP and/or UDP encapsulations. If it is necessary fields of the outer IP and/or UDP encapsulations. If it is necessary
to specify values for fields of the outer encapsulation, additional to specify values for fields of the outer encapsulation, additional
sub-TLVs must be used. This document defines two such sub-TLVs. sub-TLVs must be used. This document defines two such sub-TLVs.
If an outer encapsulation sub-TLV occurs in a TLV for a tunnel type If an outer encapsulation sub-TLV occurs in a TLV for a tunnel type
that does not use the corresponding outer encapsulation, the sub-TLV that does not use the corresponding outer encapsulation, the sub-TLV
as if it were an unknown type of sub-TLV. is treated as if it were an unknown type of sub-TLV.
2.3.1. IPv4 DS Field 3.3.1. IPv4 DS Field
Most of the tunnel types that can be specified in the Tunnel Most of the tunnel types that can be specified in the Tunnel
Encapsulation attribute require an outer IP encapsulation. The IPv4 Encapsulation attribute require an outer IP encapsulation. The IPv4
DS Field sub-TLV can be carried in the TLV of any such tunnel type. DS Field sub-TLV can be carried in the TLV of any such tunnel type.
It specifies the setting of one-octet Differentiated Services field It specifies the setting of one-octet Differentiated Services field
in the outer IP encapsulation (see [RFC2474]). The value field is in the outer IP encapsulation (see [RFC2474]). The value field is
always a single octet. always a single octet.
2.3.2. UDP Destination Port 3.3.2. UDP Destination Port
Some of the tunnel types that can be specified in the Tunnel Some of the tunnel types that can be specified in the Tunnel
Encapsulation attribute require an outer UDP encapsulation. Encapsulation attribute require an outer UDP encapsulation.
Generally there is a standard UDP Destination Port value for a Generally there is a standard UDP Destination Port value for a
particular tunnel type. However, sometimes it is useful to be able particular tunnel type. However, sometimes it is useful to be able
to use a non-standard UDP destination port. If a particular tunnel to use a non-standard UDP destination port. If a particular tunnel
type requires an outer UDP encapsulation, and it is desired to use a type requires an outer UDP encapsulation, and it is desired to use a
UDP destination port other than the standard one, the port to be used UDP destination port other than the standard one, the port to be used
can be specified by including a UDP Destination Port sub-TLV. The can be specified by including a UDP Destination Port sub-TLV. The
value field of this sub-TLV is always a two-octet field, containing value field of this sub-TLV is always a two-octet field, containing
the port value. the port value.
2.4. Embedded Label Handling Sub-TLV 3.4. Sub-TLVs for Aiding Tunnel Selection
3.4.1. Protocol Type Sub-TLV
The protocol type sub-TLV MAY be included in a given TLV to indicate
the type of the payload packets that may be encapsulated with the
tunnel parameters that are being signaled in the TLV. The value
field of the sub-TLV contains a 2-octet value from IANA's ethertype
registry [Ethertypes].
For example, if we want to use three L2TPv3 sessions, one carrying
IPv4 packets, one carrying IPv6 packets, and one carrying MPLS
packets, the egress router will include three TLVs of L2TPv3
encapsulation type, each specifying a different Session ID and a
different payload type. The protocol type sub-TLV for these will be
IPv4 (protocol type = 0x0800), IPv6 (protocol type = 0x86dd), and
MPLS (protocol type = 0x8847), respectively. This informs the
ingress routers of the appropriate encapsulation information to use
with each of the given protocol types. Insertion of the specified
Session ID at the ingress routers allows the egress to process the
incoming packets correctly, according to their protocol type.
3.4.2. Color Sub-TLV
The color sub-TLV MAY be encoded as a way to "color" the
corresponding tunnel TLV. The value field of the sub-TLV consists of
a Color Extended Community, as defined in Section 4.3. For the use
of this sub-TLV and Extended Community, please see Section 7.
3.5. Embedded Label Handling Sub-TLV
Certain BGP address families (corresponding to particular AFI/SAFI Certain BGP address families (corresponding to particular AFI/SAFI
pairs, e.g., 1/4, 2/4, 1/128, 2/128) have MPLS labels embedded in pairs, e.g., 1/4, 2/4, 1/128, 2/128) have MPLS labels embedded in
their NLRIs. We will use the term "embedded label" to refer to the their NLRIs. We will use the term "embedded label" to refer to the
MPLS label that is embedded in an NLRI, and the term "labeled address MPLS label that is embedded in an NLRI, and the term "labeled address
family" to refer to any AFI/SAFI that has embedded labels. family" to refer to any AFI/SAFI that has embedded labels.
Some of the tunnel types (e.g., VXLAN, VXLAN-GPE, and NVGRE) that can Some of the tunnel types (e.g., VXLAN, VXLAN-GPE, and NVGRE) that can
be specified in the Tunnel Encapsulation attribute have an be specified in the Tunnel Encapsulation attribute have an
encapsulation header containing "Virtual Network" identifier of some encapsulation header containing "Virtual Network" identifier of some
skipping to change at page 14, line 34 skipping to change at page 18, line 41
deployment scenarios require different handling of the embedded label deployment scenarios require different handling of the embedded label
and/or the virtual network identifier. The Embedded Label Handling and/or the virtual network identifier. The Embedded Label Handling
sub-TLV can be used to control the placement of the embedded label sub-TLV can be used to control the placement of the embedded label
and/or the virtual network identifier in the encapsulation. and/or the virtual network identifier in the encapsulation.
The Embedded Label Handling sub-TLV may be included in any TLV of the The Embedded Label Handling sub-TLV may be included in any TLV of the
Tunnel Encapsulation attribute. If the Tunnel Encapsulation Tunnel Encapsulation attribute. If the Tunnel Encapsulation
attribute is attached to an UPDATE of a non-labeled address family, attribute is attached to an UPDATE of a non-labeled address family,
the sub-TLV is treated as a no-op. If the sub-TLV is contained in a the sub-TLV is treated as a no-op. If the sub-TLV is contained in a
TLV whose tunnel type does not have a virtual network identifier in TLV whose tunnel type does not have a virtual network identifier in
its encapsulation header, the sub-TLV is treated as a no-op. its encapsulation header, the sub-TLV is treated as a no-op. In
those cases where the sub-TLV is treated as a no-op, it SHOULD NOT be
stripped from the TLV before the UPDATE is forwarded.
The sub-TLV's Length field always contains the value 1, and its value The sub-TLV's Length field always contains the value 1, and its value
field consists of a single octet. The following values are defined: field consists of a single octet. The following values are defined:
1: The payload will be an MPLS packet with the embedded label at the 1: The payload will be an MPLS packet with the embedded label at the
top of its label stack. top of its label stack.
2: The embedded label is not carried in the payload, but is carried 2: The embedded label is not carried in the payload, but is carried
either in the virtual network identifier field of the either in the virtual network identifier field of the
encapsulation header, or else is ignored entirely. encapsulation header, or else is ignored entirely.
Please see Section 7 for the details of how this sub-TLV is used when Please see Section 8 for the details of how this sub-TLV is used when
it is carried by an UPDATE of a labeled address family. it is carried by an UPDATE of a labeled address family.
If the Embedded Label sub-TLV is carried by an UPDATE of a non- 3.6. MPLS Label Stack Sub-TLV
labeled address family, it is treated as a no-op. However, it SHOULD
NOT be stripped from the TLV before the UPDATE is forwarded.
3. Tunnel Encapsulation Extended Community This sub-TLV allows an MPLS label stack to be associated with a
particular tunnel.
[RFC5512] defines an Encapsulation Extended Community. This Extended The value field of this sub-TLV is a sequence of MPLS label stack
Community may be attached to a route any AFI/SAFI to which the Tunnel entries. The first entry in the sequence is the "topmost" label, the
Encapsulation attribute may be attached. Each such Extended final entry in the sequence is the "bottommost" label. When this
Community identifies a particular tunnel type. If the Encapsulation label stack is pushed onto a packet, this ordering MUST be preserved.
Extended Community identifies a particular tunnel type, its semantics
are exactly equivalent to the semantics of a Tunnel Encapsulation Each label stack entry has the following format:
attribute TLV that:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | ToS |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: MPLS Label Stack Sub-TLV
If a packet is to be sent through the tunnel identified in a
particular TLV, and if that TLV contains an MPLS Label Stack sub-TLV,
then the label stack appearing in the sub-TLV MUST be pushed onto the
packet. This label stack MUST be pushed onto the packet before any
other labels are pushed onto the packet.
In particular, if the Tunnel Encapsulation attribute is attached to a
BGP UPDATE of a labeled address family, the contents of the MPLS
Label Stack sub-TLV MUST be pushed onto the packet before the label
embedded in the NLRI is pushed onto the packet.
If the MPLS label stack sub-TLV is included in a TLV identifying a
tunnel type that uses virtual network identifiers (see Section 8),
the contents of the MPLS label stack sub-TLV MUST be pushed onto the
packet before the procdures of Section 8 are applied.
The number of label stack entries in the sub-TLV MUST be determined
from the sub-TLV length field. Thus it is not necessary to set the S
bit in any of the label stack entries of the sub-TLV, and the setting
of the S bit is ignored when parsing the sub-TLV. When the label
stack entries are pushed onto a packet that already has a label
stack, the S bits of all the entries MUST be cleared. When the label
stack entries are pushed onto a packet that does not already have a
label stack, the S bit of the bottommost label stack entry MUST be
set, and the S bit of all the other label stack entries MUST be
cleared..
By default, the ToS field of each label stack entry is set to 0.
This may of course be changed by policy at the originator of the sub-
TLV. When pushing the label stack onto a packet, the ToS of the
label stack entries is preserved by default. However, local policy
at the router that is pushing on the stack MAY cause modification of
the ToS values.
By default, the TTL field of each label stack entry is set to 255.
This may be changed by policy at the originator of the sub-TLV. When
pushing the label stack onto a packet, the TTL of the label stack
entries is preserved by default. However, local policy at the router
that is pushing on the stack MAY cause modification of the TTL
values. If any label stack entry in the sub-TLV has a TTL value of
zero, the router that is pushing the stack on a packet MUST change
the value to a non-zero value.
Note that this sub-TLV can be appear within a TLV identifying any
type of tunnel, not just within a TLV identifying an MPLS tunnel.
However, if this sub-TLV appears within a TLV identifying an MPLS
tunnel (or an MPLS-in-X tunnel), this sub-TLV plays the same role
that would be played by an MPLS Encapsulation sub-TLV. Therefore, an
MPLS Encapsulation sub-TLV is not defined.
3.7. Prefix-SID Sub-TLV
[Prefix-SID-Attribute] defines a BGP Path attribute known as the
"Prefix-SID Attribute". This attribute is defined to contain a
sequence of one or more TLVs, where each TLV is either a "Label-
Index" TLV, an "IPv6 SID" TLV, or an "Originator SRGB" TLV.
In this document, we define a Prefix-SID sub-TLV. The value field of
the Prefix-SID sub-TLV can be set to any valid value of the value
field of a BGP Prefix-SID attribute, as defined in
[Prefix-SID-Attribute].
The Prefix-SID sub-TLV can occur in a TLV identifying any type of
tunnel. If an Originator SRGB is specified in the sub-TLV, the SRGB
MUST be interpreted to be the SRGB used by the tunnel's Remote
Endpoint. The Label-Index, if present, is the Segment Routing SID
that the tunnel'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.
If the Originator SRGB is present, the corresponding MPLS label is
computed from the combination of the Label-Index and the Originator
SRGB (see [Prefix-SID-Attribute]). If the Originator SRGB is not
present, the corresponding MPLS label is just the Label-Index value
itself. 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 TLV that:
o identifies the same tunnel type, and o identifies the same tunnel type, and
o has a Remote Endpoint sub-TLV whose IP address field contains the o has a Remote Endpoint sub-TLV whose IP address field contains the
address of the BGP next hop of the route to which it is attached, address of the BGP next hop of the route to which it is attached,
and and
o has no other sub-TLVs. o has no other sub-TLVs.
The Encapsulation Extended Community was first defined in [RFC5512].
It provides a small subset of the functionality of the Tunnel
Encapsulation attribute, and, strictly speaking, is no longer needed.
However, it is included here for backwards compatibility.
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 In the remainder of this specification, when we speak of a route as
containing a Tunnel Encapsulation attribute with a TLV identifying a containing a Tunnel Encapsulation attribute with a TLV identifying a
particular tunnel type, we are implicitly including the case where particular tunnel type, we are implicitly including the case where
the route contains a Tunnel Encapsulation Extended Community the route contains a Tunnel Encapsulation Extended Community
identifying that tunnel type. identifying that tunnel type.
4.2. Router's MAC Extended Community
[EVPN-Inter-Subnet] defines a Router's MAC Extended Community. This [EVPN-Inter-Subnet] defines a Router's MAC Extended Community. This
Extended Community provides information that may conflict with Extended Community provides information that may conflict with
information in one or more of the Encapsulation Sub-TLVs of a Tunnel information in one or more of the Encapsulation Sub-TLVs of a Tunnel
Encapsulation attribute. In case of such a conflict, the information Encapsulation attribute. In case of such a conflict, the information
in the Encapsulation Sub-TLV takes precedence. in the Encapsulation Sub-TLV takes precedence.
4. Semantics and Usage of the Tunnel Encapsulation attribute 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 12: 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 [RFC5512] specifies the use of the Tunnel Encapsulation attribute in
BGP UPDATE messages of AFI/SAFI 1/7 and 2/7. That document restricts 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 the use of this attribute to UPDATE messsages of those SAFIs. This
document removes that restriction. document removes that restriction.
The BGP Tunnel Encapsulation attribute MAY be carried in any BGP The BGP Tunnel Encapsulation attribute MAY be carried in any BGP
UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6 UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6
Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast), Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast),
1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast), 1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast),
or 25/70 (EVPN). Use of the Tunnel Encapsulation attribute in BGP or 25/70 (EVPN). Use of the Tunnel Encapsulation attribute in BGP
UPDATE messages of other AFI/SAFIs is outside the scope of this UPDATE messages of other AFI/SAFIs is outside the scope of this
document. 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 The decision to attach a Tunnel Encapsulation attribute to a given
BGP UPDATE is determined by policy. The set of TLVs and sub-TLVs BGP UPDATE is determined by policy. The set of TLVs and sub-TLVs
contained in the attribute is also determined by policy. contained in the attribute is also determined by policy.
When the Tunnel Encapsulation attribute is carried in an UPDATE of When the Tunnel Encapsulation attribute is carried in an UPDATE of
one of the AFI/SAFIs specifies in the previous paragraph, each TLV one of the AFI/SAFIs specifies in the previous paragraph, each TLV
MUST have a Remote Endpoint sub-TLV. If a TLV that does not have a 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 Remote Endpoint sub-TLV, that TLV should be treated as if it had a
malformed Remote Endpoint sub-TLV (see Section 2.1). malformed Remote Endpoint sub-TLV (see Section 3.1).
Suppose that: Suppose that:
o a given packet P must be forwarded by router R; 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 o the path along which P is to be forwarded is determined by BGP
UPDATE U; UPDATE U;
o UPDATE U has a Tunnel Encapsulation attribute, containing at least o UPDATE U has a Tunnel Encapsulation attribute, containing at least
one TLV that identifies a "feasible tunnel" for packet P. A one TLV that identifies a "feasible tunnel" for packet P. A
skipping to change at page 16, line 41 skipping to change at page 24, line 14
* The tunnel is specified in a TLV whose Remote Endpoint sub-TLV * The tunnel is specified in a TLV whose Remote Endpoint sub-TLV
identifies an IP address that is reachable. identifies an IP address that is reachable.
Then router R SHOULD send packet P through one of the feasible Then router R SHOULD send packet P through one of the feasible
tunnels identified in the Tunnel Encapsulation attribute of UPDATE U. tunnels identified in the Tunnel Encapsulation attribute of UPDATE U.
If the Tunnel Encapsulation attribute contains several TLVs (i.e., if If the Tunnel Encapsulation attribute contains several TLVs (i.e., if
it specifies several tunnels), router R may choose any one of those it specifies several tunnels), router R may choose any one of those
tunnels, based upon local policy. If any of tunnels' TLVs contain tunnels, based upon local policy. If any of tunnels' TLVs contain
the Color sub-TLV and/or the Protocol Type sub-TLV defined in the Color sub-TLV(Section 3.4.2) and/or the Protocol Type sub-TLV
[RFC5512], the choice of tunnel may be influenced by these sub-TLVs. (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 Note that if none of the TLVs specifies the MPLS tunnel type, a Label
Switched Path SHOULD NOT be used. 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 If a particular tunnel is not feasible at some moment because its
Remote Endpoint cannot be reached at that moment, the tunnel may Remote Endpoint cannot be reached at that moment, the tunnel may
become feasible at a later time. When this happens, router R SHOULD become feasible at a later time. When this happens, router R SHOULD
reconsider its choice of tunnel to use, and MAY choose to now use the reconsider its choice of tunnel to use, and MAY choose to now use the
tunnel. tunnel.
A TLV specifying a non-feasible tunnel is not considered to be 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 malformed or erroneous in any way, and the TLV SHOULD NOT be stripped
from the Tunnel Encapsulation attribute before redistribution. from the Tunnel Encapsulation attribute before redistribution.
In addition to the sub-TLVs already defined, additional sub-TLVs may 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 be defined that affect the choice of tunnel to be used, or that
affect the contents of the tunnel encapsulation header. The affect the contents of the tunnel encapsulation header. The
documents that define any such additional sub-TLVs must specify the documents that define any such additional sub-TLVs must specify the
effect that including the sub-TLV is to have. effect that including the sub-TLV is to have.
If it is determined to send a packet through the tunnel specified in If it is determined to send a packet through the tunnel specified in
a particular TLV of a particular Tunnel Encapsulation attribute, and a particular TLV of a particular Tunnel Encapsulation attribute, then
if that TLV contains a Remote Endpoint sub-TLV, then the tunnel's the tunnel's remote endpoint address is the IP address contained in
remote endpoint address is the IP address contained in the sub-TLV. the sub-TLV. If the TLV contains a Remote Endpoint sub-TLV whose
If the TLV does not contain a Remote Endpoint sub-TLV, or if it value field is all zeroes, then the tunnel's remote endpoint is the
contains a Remote Endpoint sub-TLV whose value field is all zeroes, IP address specified as the Next Hop of the BGP Update containing the
then the tunnel's remote endpoint is the IP address specified as the Tunnel Encapsulation attribute.
Next Hop of the BGP Update containing the Tunnel Encapsulation
attribute.
The procedure for sending a packet through a particular tunnel type The procedure for sending a packet through a particular tunnel type
to a particular remote endpoint depends upon the tunnel type, and is to a particular remote endpoint depends upon the tunnel type, and is
outside the scope of this document. The contents of the tunnel outside the scope of this document. The contents of the tunnel
encapsulation header MAY be influenced by the Encapsulation sub-TLV. encapsulation header MAY be influenced by the Encapsulation sub-TLV.
Note that some tunnel types may require the execution of an explicit Note that some tunnel types may require the execution of an explicit
tunnel setup protocol before they can be used for carrying data. tunnel setup protocol before they can be used for carrying data.
Other tunnel types may not require any tunnel setup protocol. Other tunnel types may not require any tunnel setup protocol.
Whenever a new Tunnel Type TLV is defined, the specification of that Whenever a new Tunnel Type TLV is defined, the specification of that
TLV must describe (or reference) the procedures for creating the TLV must describe (or reference) the procedures for creating the
encapsulation header used to forward packets through that tunnel encapsulation header used to forward packets through that tunnel
type. type.
If a Tunnel Encapsulation attribute specifies several tunnels, the If a Tunnel Encapsulation attribute specifies several tunnels, the
way in which a router chooses which one to use is a matter of policy, 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 subject to the following constraint: if a router can determine that a
given tunnel is not functional, it MUST NOT use that tunnel. In given tunnel is not functional, it MUST NOT use that tunnel. In
skipping to change at page 18, line 23 skipping to change at page 25, line 45
etc. Choosing between two such tunnels is a matter of local policy. etc. Choosing between two such tunnels is a matter of local policy.
Once router R has decided to send packet P through a particular Once router R has decided to send packet P through a particular
tunnel, it encapsulates packet P appropriately and then forwards it tunnel, it encapsulates packet P appropriately and then forwards it
according to the route that leads to the tunnel's remote endpoint. according to the route that leads to the tunnel's remote endpoint.
This route may itself be a BGP route with a Tunnel Encapsulation This route may itself be a BGP route with a Tunnel Encapsulation
attribute. If so, the encapsulated packet is treated as the payload attribute. If so, the encapsulated packet is treated as the payload
and is encapsulated according to the Tunnel Encapsulation attribute and is encapsulated according to the Tunnel Encapsulation attribute
of that route. That is, tunnels may be "stacked". of that route. That is, tunnels may be "stacked".
5. Routing Considerations 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.
5.1. No Impact on BGP Decision Process 6. Routing Considerations
6.1. No Impact on BGP Decision Process
The presence of the Tunnel Encapsulation attribute does not affect The presence of the Tunnel Encapsulation attribute does not affect
the BGP bestpath selection algorithm. the BGP bestpath selection algorithm.
Under certain circumstances, this may need to counter-intuitive Under certain circumstances, this may lead to counter-intuitive
consequences. For example, suppose: consequences. For example, suppose:
o router R1 receives a BGP UPDATE message from router R2, such that o router R1 receives a BGP UPDATE message from router R2, such that
* the NLRI of that UPDATE is prefix X, * the NLRI of that UPDATE is prefix X,
* the UPDATE contains a Tunnel Encapsulation attribute specifying * the UPDATE contains a Tunnel Encapsulation attribute specifying
two tunnels, T1 and T2, two tunnels, T1 and T2,
* R1 cannot use tunnel T1 or tunnel T2, either because the tunnel * R1 cannot use tunnel T1 or tunnel T2, either because the tunnel
skipping to change at page 19, line 13 skipping to change at page 26, line 43
* R1 can use at least one of the two tunnels * R1 can use at least one of the two tunnels
Since the Tunnel Encapsulation attribute does not affect bestpath Since the Tunnel Encapsulation attribute does not affect bestpath
selection, R1 may well install the route from R2 rather than the selection, R1 may well install the route from R2 rather than the
route from R3, even though R2's route contains no usable tunnels. route from R3, even though R2's route contains no usable tunnels.
This possibility must be kept in mind whenever a Remote Endpoint sub- This possibility must be kept in mind whenever a Remote Endpoint sub-
TLV carried by a given UPDATE specifies an IP address that is TLV carried by a given UPDATE specifies an IP address that is
different than the next hop of that UPDATE. different than the next hop of that UPDATE.
5.2. Looping, Infinite Stacking, Etc. 6.2. Looping, Infinite Stacking, Etc.
Consider a packet destined for address X. Suppose a BGP UPDATE for Consider a packet destined for address X. Suppose a BGP UPDATE for
address prefix X carries a Tunnel Encapsulation attribute that address prefix X carries a Tunnel Encapsulation attribute that
specifies a remote tunnel endpoint of Y. And suppose that a BGP specifies a remote tunnel endpoint of Y. And suppose that a BGP
UPDATE for address prefix Y carries a Tunnel Encapsulation attribute UPDATE for address prefix Y carries a Tunnel Encapsulation attribute
that specifies a Remote Endpoint of X. It is easy to see that this 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 will cause an infinite number of encapsulation headers to be put on
the given packet. the given packet.
This could happen as a result of misconfiguration, either accidental This could happen as a result of misconfiguration, either accidental
skipping to change at page 19, line 43 skipping to change at page 27, line 25
destined for X, it will apply the encapsulation and send the destined for X, it will apply the encapsulation and send the
encapsulated packet to Y. Y will decapsulate the packet and forward 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 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 possible that the path from Y to X will traverse R. This would cause
a long-lasting routing loop. a long-lasting routing loop.
These possibilities must also be kept in mind whenever the Remote These possibilities must also be kept in mind whenever the Remote
Endpoint for a given prefix differs from the BGP next hop for that Endpoint for a given prefix differs from the BGP next hop for that
prefix. prefix.
6. Recursive Next Hop Resolution 7. Recursive Next Hop Resolution
Suppose that: Suppose that:
o a given packet P must be forwarded by router R1; 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 o the path along which P is to be forwarded is determined by BGP
UPDATE U1; UPDATE U1;
o UPDATE U1 does not have a Tunnel Encapsulation attribute; o UPDATE U1 does not have a Tunnel Encapsulation attribute;
o the next hop of UPDATE U1 is router R2; 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 o the best path to router R2 is a BGP route that was advertised in
UPDATE U2; UPDATE U2;
o UPDATE U2 has a Tunnel Encapsulation attribute. o UPDATE U2 has a Tunnel Encapsulation attribute.
Then packet P SHOULD be sent through one of the tunnels identified in Then packet P SHOULD be sent through one of the tunnels identified in
the Tunnel Encapsulation attribute of UPDATE U2. See Section 4 for the Tunnel Encapsulation attribute of UPDATE U2. See Section 5 for
further details. 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
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 Note that if UPDATE U1 and UPDATE U2 both have Tunnel Encapsulation
attributes, packet P will be carried through a pair of nested attributes, packet P will be carried through a pair of nested
tunnels. P will first be encapsulated based on the Tunnel tunnels. P will first be encapsulated based on the Tunnel
Encapsulation attribute of U1. This encapsulated packet then becomes Encapsulation attribute of U1. This encapsulated packet then becomes
the payload, and is encapsulated based on the Tunnel Encapsulation the payload, and is encapsulated based on the Tunnel Encapsulation
attribute of U2. This is another way of "stacking" tunnels (see also attribute of U2. This is another way of "stacking" tunnels (see also
Section 4. Section 5.
7. Use of Virtual Network Identifiers and Embedded Labels when Imposing 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 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 Three of the tunnel types that can be specified in a Tunnel
Encapsulation TLV have virtual network identifier fields in their Encapsulation TLV have virtual network identifier fields in their
encapsulation headers. In the VXLAN and VXLAN-GPE encapsulations, encapsulation headers. In the VXLAN and VXLAN-GPE encapsulations,
this field is called the VNI field; in the NVGRE encapsulation, this this field is called the VNI field; in the NVGRE encapsulation, this
field is called the VSID field. field is called the VSID field.
When one of these tunnel encapsulations is imposed on a packet, the When one of these tunnel encapsulations is imposed on a packet, the
setting of the virtual network identifier field in the encapsulation setting of the virtual network identifier field in the encapsulation
header depends upon the contents of the Encapsulation sub-TLV (if one header depends upon the contents of the Encapsulation sub-TLV (if one
is present). When the Tunnel Encapsulation attribute is being is present). When the Tunnel Encapsulation attribute is being
carried on a BGP UPDATE of a labeled address family, the setting of carried on a BGP UPDATE of a labeled address family, the setting of
the virtual network identifier field also depends upon the contents the virtual network identifier field also depends upon the contents
of the Embedded Label Handling sub-TLV (if present). of the Embedded Label Handling sub-TLV (if present).
This section specifies the procedures for choosing the value to set This section specifies the procedures for choosing the value to set
in the virtual network identifier field of the encapsulation header. in the virtual network identifier field of the encapsulation header.
These procedures apply only when the tunnel type is VXLAN, VXLAN-GPE, These procedures apply only when the tunnel type is VXLAN, VXLAN-GPE,
or NVGRE. or NVGRE.
7.1. Unlabeled Address Families 8.2.1. Unlabeled Address Families
This sub-section applies when: This sub-section applies when:
o the Tunnel Encapsulation attribute is carried on a BGP UPDATE of o the Tunnel Encapsulation attribute is carried on a BGP UPDATE of
an unlabeled address family, and an unlabeled address family, and
o at least one of the attribute's TLVs identifies a tunnel type that o at least one of the attribute's TLVs identifies a tunnel type that
uses a virtual network identifier, and uses a virtual network identifier, and
o it has been determined to send a packet through one of those o it has been determined to send a packet through one of those
skipping to change at page 21, line 20 skipping to change at page 29, line 34
If the TLV identifying the tunnel contains an Encapsulation sub-TLV If the TLV identifying the tunnel contains an Encapsulation sub-TLV
whose V bit is set, the virtual network identifier field of the whose V bit is set, the virtual network identifier field of the
encapsulation header is set to the value of the virtual network encapsulation header is set to the value of the virtual network
identifier field of the Encapsulation sub-TLV. identifier field of the Encapsulation sub-TLV.
Otherwise, the virtual network identifier field of the encapsulation Otherwise, the virtual network identifier field of the encapsulation
header is set to a configured value; if there is no configured value, header is set to a configured value; if there is no configured value,
the tunnel cannot be used. the tunnel cannot be used.
7.2. Labeled Address Families 8.2.2. Labeled Address Families
This sub-section applies when: This sub-section applies when:
o the Tunnel Encapsulation attribute is carried on a BGP UPDATE of a o the Tunnel Encapsulation attribute is carried on a BGP UPDATE of a
labeled address family, and labeled address family, and
o at least one of the attribute's TLVs identifies a tunnel type that o at least one of the attribute's TLVs identifies a tunnel type that
uses a virtual network identifier, and uses a virtual network identifier, and
o it has been determined to send a packet through one of those o it has been determined to send a packet through one of those
tunnels. tunnels.
7.2.1. When a Valid VNI has been Signaled 8.2.2.1. When a Valid VNI has been Signaled
If the TLV identifying the tunnel contains an Encapsulation sub-TLV If the TLV identifying the tunnel contains an Encapsulation sub-TLV
whose V bit is set, the virtual network identifier field of the whose V bit is set, the virtual network identifier field of the
encapsulation header is set as follows: encapsulation header is set as follows:
o If the TLV contains an Embedded Label Handling sub-TLV whose value o If the TLV contains an Embedded Label Handling sub-TLV whose value
is 1, then the virtual network identifier field of the is 1, then the virtual network identifier field of the
encapsulation header is set to the value of the virtual network encapsulation header is set to the value of the virtual network
identifier field of the Encapsulation sub-TLV. identifier field of the Encapsulation sub-TLV.
skipping to change at page 22, line 7 skipping to change at page 30, line 21
the Tunnel Encapsulation attribute) appears at the top of the MPLS the Tunnel Encapsulation attribute) appears at the top of the MPLS
label stack in the encapsulation payload. label stack in the encapsulation payload.
o If the TLV does not contain an Embedded Label Handling sub-TLV, or 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, if contains an Embedded Label Handling sub-TLV whose value is 2,
the embedded label is ignored entirely, and the virtual network the embedded label is ignored entirely, and the virtual network
identifier field of the encapsulation header is set to the value identifier field of the encapsulation header is set to the value
of the virtual network identifier field of the Encapsulation sub- of the virtual network identifier field of the Encapsulation sub-
TLV. TLV.
7.2.2. When a Valid VNI has not been Signaled 8.2.2.2. When a Valid VNI has not been Signaled
If the TLV identifying the tunnel does not contain an Encapsulation If the TLV identifying the tunnel does not contain an Encapsulation
sub-TLV whose V bit is set, the virtual network identifier field of sub-TLV whose V bit is set, the virtual network identifier field of
the encapsulation header is set as follows: the encapsulation header is set as follows:
o If the TLV contains an Embedded Label Handling sub-TLV whose value o If the TLV contains an Embedded Label Handling sub-TLV whose value
is 1, then the virtual network identifier field of the is 1, then the virtual network identifier field of the
encapsulation header is set to a configured value. encapsulation header is set to a configured value.
If there is no configured value, the tunnel cannot be used. If there is no configured value, the tunnel cannot be used.
skipping to change at page 22, line 31 skipping to change at page 30, line 45
label stack in the encapsulation payload. label stack in the encapsulation payload.
o If the TLV does not contain an Embedded Label Handling sub-TLV, or 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 if it contains an Embedded Label Handling sub-TLV whose value is
2, the embedded label is copied into the virtual network 2, the embedded label is copied into the virtual network
identifier field of the encapsulation header. identifier field of the encapsulation header.
The embedded label does not appear in the MPLS label stack of the The embedded label does not appear in the MPLS label stack of the
payload. payload.
7.2.3. Applicability Restrictions 9. Applicability Restrictions
In a given UPDATE of a labeled address family, the label embedded in 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 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 whose address appears as the next hop. Certain of the procedures of
Section 7.2.1 or Section 7.2.2 cause the embedded label to be carried Section 8.2.2.1 or Section 8.2.2.2 cause the embedded label to be
by a data packet to the router whose address appears in the Remote carried by a data packet to the router whose address appears in the
Endpoint sub-TLV. If the Remote Endpoint sub-TLV does not identify Remote Endpoint sub-TLV. If the Remote Endpoint sub-TLV does not
the same router that is the next hop, sending the packet through the identify the same router that is the next hop, sending the packet
tunnel may cause the label to be misinterpreted at the tunnel's through the tunnel may cause the label to be misinterpreted at the
remote endpoint. This may cause misdelivery of the packet. tunnel's remote endpoint. This may cause misdelivery of the packet.
Therefore the embedded label MUST NOT be carried by a data 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 traveling through a tunnel unless it is known that the label will be
properly interpreted at the tunnel's remote endpoint. How this is properly interpreted at the tunnel's remote endpoint. How this is
known is outside the scope of this document. known is outside the scope of this document.
Note that if the Tunnel Encapsulation attribute is attached to a VPN- 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 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 [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 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. route, it is very likely that the embedded label has been changed.
Therefore use of the Tunnel Encapsulation attribute in an "Inter-AS Therefore use of the Tunnel Encapsulation attribute in an "Inter-AS
option b" scenario is not supported. option b" scenario is not supported.
8. Scoping 10. Scoping
The Tunnel Encapsulation attribute is defined as a transitive The Tunnel Encapsulation attribute is defined as a transitive
attribute, so that it may be passed along by BGP speakers that do not attribute, so that it may be passed along by BGP speakers that do not
recognize it. However, it is intended that the Tunnel Encapsulation recognize it. However, it is intended that the Tunnel Encapsulation
attribute be used only within a well-defined scope, e.g., within a attribute be used only within a well-defined scope, e.g., within a
set of Autonomous Systems that belong to a single administrative set of Autonomous Systems that belong to a single administrative
entity. If the attribute is distributed beyond its intended scope, entity. If the attribute is distributed beyond its intended scope,
packets may be sent through tunnels in a manner that is not intended. packets may be sent through tunnels in a manner that is not intended.
To prevent the Tunnel Encapsulation attribute from being distributed To prevent the Tunnel Encapsulation attribute from being distributed
skipping to change at page 23, line 33 skipping to change at page 31, line 46
filtering SHOULD be possible on a per-BGP-session basis. For each filtering SHOULD be possible on a per-BGP-session basis. For each
session, filtering of the attribute on incoming UPDATEs MUST be session, filtering of the attribute on incoming UPDATEs MUST be
enabled by default. enabled by default.
In addition, any BGP speaker that understands the attribute MUST be In addition, any BGP speaker that understands the attribute MUST be
able to filter the attribute from outgoing BGP UPDATE messages. This able to filter the attribute from outgoing BGP UPDATE messages. This
filtering SHOULD be possible on a per-BGP-session basis. For each filtering SHOULD be possible on a per-BGP-session basis. For each
session, filtering of the attribute on outgoing UPDATEs MUST be session, filtering of the attribute on outgoing UPDATEs MUST be
enabled by default. enabled by default.
9. Error Handling 11. Error Handling
The Tunnel Encapsulation attribute is a sequence of TLVs, each of 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 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- 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 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 also be the final octet of its final sub-TLV. If this is not the
case, the TLV MUST be considered malformed. A TLV that is found to case, the TLV MUST be considered to be malformed. A TLV that is
be malformed for this reason MUST NOT be processed, and MUST be found to be malformed for this reason MUST NOT be processed, and MUST
stripped from the Tunnel Encapsulation attribute before be stripped from the Tunnel Encapsulation attribute before the
redistribution. Subsequent TLVs in the Tunnel Encapsulation attribute is propagated. Subsequent TLVs in the Tunnel Encapsulation
attribute may still be valid, in which case they MUST be processed attribute may still be valid, in which case they MUST be processed
and redistributed normally. and redistributed normally.
If a Tunnel Encapsulation attribute does not have any valid TLVs, or If a Tunnel Encapsulation attribute does not have any valid TLVs, or
it does not have the transitive bit set, the "Attribute Discard" it does not have the transitive bit set, the "Attribute Discard"
procedure of [ERRORS] is applied. procedure of [RFC7606] is applied.
If a Tunnel Encapsulation attribute can be parsed correctly, but If a Tunnel Encapsulation attribute can be parsed correctly, but
contains a TLV that is not recognized (i.e., the tunnel type is not contains a TLV whose tunnel type is not recognized by a particular
recognized) by a particular BGP speaker, the attribute is NOT BGP speaker, that BGP speaker MUST NOT consider the attribute to be
considered to be malformed. The unrecognized TLV MUST be ignored, malformed. Rather, the TLV with the unrecognized tunnel type MUST be
and the BGP speaker MUST interpret the attribute as if the ignored, and the BGP speaker MUST interpret the attribute as if that
unrecognized TLV had not been present. If the route carrying the TLV had not been present. If the route carrying the Tunnel
Tunnel Encapsulation attribute is redistributed with the attribute, Encapsulation attribute is propagated with the attribute, the
the unrecognized TLV SHOULD remain in the attribute. unrecognized TLV SHOULD remain in the attribute.
If a TLV of a Tunnel Encapsulation attribute contains a sub-TLV that 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 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. process that TLV as if the unrecognized sub-TLV had not been present.
If the route carrying the Tunnel Encapsulation attribute is If the route carrying the Tunnel Encapsulation attribute is
redistributed with the attribute, the unrecognized TLV SHOULD remain propagated with the attribute, the unrecognized TLV SHOULD remain in
in the attribute. the attribute.
In general, if a TLV contains a sub-TLV that is malformed (e.g., 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), 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. 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 This document specifies one exception to this rule -- if a TLV
contains a malformed Remote Endpoint sub-TLV (as defined in contains a malformed Remote Endpoint sub-TLV (as defined in
Section 2.1, the entire TLV MUST be ignored, and SHOULD be removed Section 3.1, the entire TLV MUST be ignored, and SHOULD be removed
from the Tunnel Encapsulation attribute before the route carrying from the Tunnel Encapsulation attribute before the route carrying
that attribute is redistributed. that attribute is redistributed.
A TLV that does not contain the Remote Endpoint sub-TLV MUST be A TLV that does not contain the Remote Endpoint sub-TLV MUST be
treated as if it contained a malformed Remote Endpoint sub-TLV. treated as if it contained a malformed Remote Endpoint sub-TLV.
A TLV identifying a particular tunnel type may contain a sub-TLV that A TLV identifying a particular tunnel type may contain a sub-TLV that
is meaningless for that tunnel type. For example, perhaps the TLV is meaningless for that tunnel type. For example, perhaps the TLV
contains a "UDP Destination Port" sub-TLV, but the identified tunnel contains a "UDP Destination Port" sub-TLV, but the identified tunnel
type does not use UDP encapsulation at all. Sub-TLVs of this sort 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 SHOULD be treated as no-ops. That is, they SHOULD NOT affect the
creation of the encapsulation header. However, the sub-TLV MUST NOT creation of the encapsulation header. However, the sub-TLV MUST NOT
be considered to be malformed, and MUST NOT be removed from the TLV be considered to be malformed, and MUST NOT be removed from the TLV
before the route carrying the Tunnel Encapsulation attribute is before the route carrying the Tunnel Encapsulation attribute is
redistributed. 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 There is no significance to the order in which the TLVs occur within
the Tunnel Encapsulation attribute. Multiple TLVs may occur for a the Tunnel Encapsulation attribute. Multiple TLVs may occur for a
given tunnel type; each such TLV is regarded as describing a given tunnel type; each such TLV is regarded as describing a
different tunnel. different tunnel.
10. IANA Considerations 12. IANA Considerations
12.1. Subsequent Address Family Identifiers
IANA is requested to modify the "Subsequent Address Family IANA is requested to modify the "Subsequent Address Family
Identifiers" registry to indicate that the Encapsulation SAFI is Identifiers" registry to indicate that the Encapsulation SAFI is
deprecated. This document should be the reference. deprecated. This document should be the reference.
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 change the registration policy of the "BGP IANA is requested to change the registration policy of the "BGP
Tunnel Encapsulation Attribute Sub-TLVs" registry to the following: Tunnel Encapsulation Attribute Sub-TLVs" registry to the following:
o The values 0 and 255 are reserved. o The values 0 and 255 are reserved.
o The values in the range 1-127 are to be allocated using the o The values in the range 1-127 are to be allocated using the
"Standards Action" registration procedure. "Standards Action" registration procedure.
o The values in the range 128-251 are to be allocated using the o The values in the range 128-251 are to be allocated using the
"First Come, First Served" registration procedure. "First Come, First Served" registration procedure.
skipping to change at page 25, line 36 skipping to change at page 34, line 22
IANA is requested to assign a codepoint from the "BGP Tunnel IANA is requested to assign a codepoint from the "BGP Tunnel
Encapsulation Attribute Sub-TLVs" registry for "UDP Destination Encapsulation Attribute Sub-TLVs" registry for "UDP Destination
Port", with this document being the reference. Port", with this document being the reference.
IANA is requested to assign a codepoint from the "BGP Tunnel IANA is requested to assign a codepoint from the "BGP Tunnel
Encapsulation Attribute Sub-TLVs" registry for "Embedded Label Encapsulation Attribute Sub-TLVs" registry for "Embedded Label
Handling", with this document being the reference. Handling", with this document being the reference.
IANA is requested to assign a codepoint from the "BGP Tunnel IANA is requested to assign a codepoint from the "BGP Tunnel
Encapsulation Tunnel Types" registry for "GTP". Encapsulation Attribute Sub-TLVs" registry for "MPLS Label Stack",
with this document being the reference.
IANA is requested to assign a codepoint from 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 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 types 8 (VXLAN), 9 (NVGRE), 11 (MPLS-in-GRE), and 12 (VXLAN-GPE) in
the "BGP Tunnel Encapsulation Tunnel Types" registry. the "BGP Tunnel Encapsulation Tunnel Types" registry.
11. Security Considerations 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 The Tunnel Encapsulation attribute can cause traffic to be diverted
from its normal path, especially when the Remote Endpoint sub-TLV is from its normal path, especially when the Remote Endpoint sub-TLV is
used. This can have serious consequences if the attribute is added used. This can have serious consequences if the attribute is added
or modified illegitimately, as it enables traffic to be "hijacked". or modified illegitimately, as it enables traffic to be "hijacked".
The Remote Endpoint sub-TLV contains both an IP address and an AS The Remote Endpoint sub-TLV contains both an IP address and an AS
number. BGP Origin Validation [RFC6811] can be used to obtain number. BGP Origin Validation [RFC6811] can be used to obtain
assurance that the given IP address belongs to the given AS. While assurance that the given IP address belongs to the given AS. While
this provides some protection against misconfiguration, it does not this provides some protection against misconfiguration, it does not
skipping to change at page 26, line 25 skipping to change at page 35, line 30
Remote Endpoint sub-TLV is correct, and is the same AS that is Remote Endpoint sub-TLV is correct, and is the same AS that is
specified in the Remote Endpoint sub-TLV. specified in the Remote Endpoint sub-TLV.
One then has some level of assurance that the tunneled traffic is 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 going to the same destination AS that it would have gone to had the
Tunnel Encapsulation attribute not been present. However, this may Tunnel Encapsulation attribute not been present. However, this may
not suit all use cases, and in any event is not very strong not suit all use cases, and in any event is not very strong
protection against hijacking. protection against hijacking.
For these reasons, BGP Origin Validation should not be relied upon For these reasons, BGP Origin Validation should not be relied upon
exclusively, and the filtering procedures of Section 8 should always exclusively, and the filtering procedures of Section 10 should always
be in place. be in place.
Increased protection can be obtained by using BGP Path Validation Increased protection can be obtained by using BGP Path Validation
[BGPSEC] to ensure that the route carrying the Tunnel Encapsulation [BGPSEC] to ensure that the route carrying the Tunnel Encapsulation
attribute, and the routes to the Remote Endpoint of each specified attribute, and the routes to the Remote Endpoint of each specified
tunnel, have not been altered illegitimately. tunnel, have not been altered illegitimately.
If BGP Origin Validation is used as specified above, and the tunnel If BGP Origin Validation is used as specified above, and the tunnel
specified in a particular TLV of a Tunnel Encapsulation attribute is specified in a particular TLV of a Tunnel Encapsulation attribute is
therefore regarded as "suspicious", that tunnel should not be used. therefore regarded as "suspicious", that tunnel should not be used.
Other tunnels specified in (other TLVs of) the Tunnel Encapsulation Other tunnels specified in (other TLVs of) the Tunnel Encapsulation
attribute may still be used. attribute may still be used.
12. Acknowledgments 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 think Ron Bonica, John Drake, Satoru Matsushima, The authors wish to think Ron Bonica, John Drake, Satoru Matsushima,
Dhananjaya Rao, John Scudder, Ravi Singh, Thomas Morin, and Xiaohu Xu Dhananjaya Rao, John Scudder, Ravi Singh, Thomas Morin, Xiaohu Xu,
for their review, comments, and/or helpful discussions. and Zhaohui Zhang for their review, comments, and/or helpful
discussions.
13. Contributor Addresses 15. Contributor Addresses
Below is a list of other contributing authors in alphabetical order: Below is a list of other contributing authors in alphabetical order:
Randy Bush Randy Bush
Internet Initiative Japan Internet Initiative Japan
5147 Crystal Springs 5147 Crystal Springs
Bainbridge Island, Washington 98110 Bainbridge Island, Washington 98110
United States United States
Email: randy@psg.com Email: randy@psg.com
Robert Raszuk Robert Raszuk
Mirantis Inc. Bloomberg LP
615 National Ave. #100 731 Lexington Ave
Mountain View, California 94043 New York City, NY 10022
United States United States
Email: robert@raszuk.net Email: robert@raszuk.net
14. References 16. References
14.1. Normative References
[ERRORS] Chen, E., Scudder, J., Mohapatra, P., and K. Patel, 16.1. Normative References
"Revised Error Handling for BGP UPDATE Messages",
internet-draft draft-ietf-idr-error-handling-19, April
2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP Subsequent Address Family Identifier (SAFI) and the BGP
Tunnel Encapsulation Attribute", RFC 5512, Tunnel Encapsulation Attribute", RFC 5512,
DOI 10.17487/RFC5512, April 2009, DOI 10.17487/RFC5512, April 2009,
<http://www.rfc-editor.org/info/rfc5512>. <http://www.rfc-editor.org/info/rfc5512>.
14.2. Informative References [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", [BGPSEC] Lepinski, M. and S. Turner, "An Overview of BGPsec",
internet-draft draft-ietf-sidr-bgpsec-overview, June 2015. internet-draft draft-ietf-sidr-bgpsec-overview, June 2015.
[Ethertypes]
"IANA Ethertype Registry",
<http://www.iana.org/assignments/ieee-802-numbers/
ieee-802-numbers.xhtml>.
[EVPN-Inter-Subnet] [EVPN-Inter-Subnet]
Sajassi, A., "Integrated Routing and Bridging in EVPN", Sajassi, A., Salem, S., Thoria, S., Rekhter, Y., Drake,
internet-draft draft-ietf-bess-evpn-inter-subnet- J., Yong, L., Dunbar, L., Henderickx, W., Rabadan, J.,
forwarding, November 2014. Balus, F., and D. Cai, "Integrated Routing and Bridging in
EVPN", internet-draft draft-ietf-bess-evpn-inter-subnet-
forwarding, October 2015.
[GTP-U] 3GPP, "GPRS Tunneling Protocol User Plane, TS 29.281", [GTP-U] 3GPP, "GPRS Tunneling Protocol User Plane, TS 29.281",
2014. 2014.
[NVGRE] Garg, P. and Y. Wang, "NVGRE: Network Virtualization using [Prefix-SID-Attribute]
Generic Routing Encapsulation", internet-draft draft- Previdi, S., Filsfils, C., Lindem, A., Patel, K.,
sridharan-virtualization-nvgre, April 2015. Sreekantiah, A., Ray, S., and H. Gredler, "Segment Routing
Prefix SID extensions for BGP", internet-draft draft-ietf-
idr-bgp-prefix-sid-02, October 2015.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>. <http://www.rfc-editor.org/info/rfc2474>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000, DOI 10.17487/RFC2784, March 2000,
<http://www.rfc-editor.org/info/rfc2784>. <http://www.rfc-editor.org/info/rfc2784>.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, DOI 10.17487/RFC2890, September 2000, RFC 2890, DOI 10.17487/RFC2890, September 2000,
<http://www.rfc-editor.org/info/rfc2890>. <http://www.rfc-editor.org/info/rfc2890>.
[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., [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
"Encapsulating MPLS in IP or Generic Routing Encapsulation "Encapsulating MPLS in IP or Generic Routing Encapsulation
(GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,
<http://www.rfc-editor.org/info/rfc4023>. <http://www.rfc-editor.org/info/rfc4023>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>. 2006, <http://www.rfc-editor.org/info/rfc4364>.
[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. [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811, Austein, "BGP Prefix Origin Validation", RFC 6811,
DOI 10.17487/RFC6811, January 2013, DOI 10.17487/RFC6811, January 2013,
<http://www.rfc-editor.org/info/rfc6811>. <http://www.rfc-editor.org/info/rfc6811>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<http://www.rfc-editor.org/info/rfc7348>. <http://www.rfc-editor.org/info/rfc7348>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510, "Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015, DOI 10.17487/RFC7510, April 2015,
<http://www.rfc-editor.org/info/rfc7510>. <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>.
[vEPC] Matsushima, S. and R. Wakikawa, "Stateless User-Plane [vEPC] Matsushima, S. and R. Wakikawa, "Stateless User-Plane
Architecture for Virtualized EPC", internet-draft draft- Architecture for Virtualized EPC", internet-draft draft-
matsushima-stateless-uplane-vepc-04, March 2015. matsushima-stateless-uplane-vepc-04, March 2015.
[VXLAN-GPE] [VXLAN-GPE]
Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F.,
Smith, M., Agarwal, P., Xu, X., Elzur, U., Garg, P., Smith, M., Agarwal, P., Xu, X., Elzur, U., Garg, P.,
Melman, D., and R. Manur, "Generic Protocol Extension for Melman, D., and R. Manur, "Generic Protocol Extension for
VXLAN", internet-draft draft-ietf-nvo3-vxlan-gpe, May VXLAN", internet-draft draft-ietf-nvo3-vxlan-gpe, May
2015. 2015.
 End of changes. 109 change blocks. 
228 lines changed or deleted 681 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/