draft-ietf-idr-tunnel-encaps-15.txt   draft-ietf-idr-tunnel-encaps-16.txt 
IDR Working Group K. Patel IDR Working Group K. Patel
Internet-Draft Arrcus, Inc Internet-Draft Arrcus, Inc
Obsoletes: 5512 (if approved) G. Van de Velde Obsoletes: 5512, 5566, 5640 (if G. Van de Velde
Intended status: Standards Track Nokia approved) Nokia
Expires: June 3, 2020 S. Sangli Intended status: Standards Track S. Sangli
Juniper Networks, Inc Expires: January 14, 2021 J. Scudder
December 01, 2019 Juniper Networks
July 13, 2020
The BGP Tunnel Encapsulation Attribute The BGP Tunnel Encapsulation Attribute
draft-ietf-idr-tunnel-encaps-15.txt draft-ietf-idr-tunnel-encaps-16
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 the of tunnels. For each such tunnel, the attribute can provide the
information needed to create the tunnel and the corresponding information needed to create the tunnel and the corresponding
encapsulation header. The attribute can also provide information encapsulation header. The attribute can also provide information
that aids in choosing whether a particular packet is to be sent that aids in choosing whether a particular packet is to be sent
through a particular tunnel. RFC 5512 states that the attribute is through a particular tunnel. RFC 5512 states that the attribute is
only carried in BGP UPDATEs that have the "Encapsulation Subsequent only carried in BGP UPDATEs that use the "Encapsulation Subsequent
Address Family (Encapsulation SAFI)". This document deprecates the Address Family (Encapsulation SAFI)". This document deprecates the
Encapsulation SAFI (which has never been used in production), and Encapsulation SAFI (which has never been used in production), and
specifies semantics for the attribute when it is carried in UPDATEs specifies semantics for the attribute when it is carried in UPDATEs
of certain other SAFIs. This document adds support for additional of certain other SAFIs. This document adds support for additional
tunnel types, and allows a remote tunnel endpoint address to be Tunnel Types, and allows a remote tunnel endpoint address to be
specified for each tunnel. This document also provides support for specified for each tunnel. This document also provides support for
specifying fields of any inner or outer encapsulations that may be specifying fields of any inner or outer encapsulations that may be
used by a particular tunnel. used by a particular tunnel.
This document obsoletes RFC 5512. This document obsoletes RFC 5512. Since RFCs 5566 and 5640 rely on
RFC 5512, they are likewise obsoleted.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 June 3, 2020.
This Internet-Draft will expire on January 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
1.1. Brief Summary of RFC 5512 . . . . . . . . . . . . . . . . 4 1.1. Brief Summary of RFC 5512 . . . . . . . . . . . . . . . . 4
1.2. Deficiencies in RFC 5512 . . . . . . . . . . . . . . . . 4 1.2. Deficiencies in RFC 5512 . . . . . . . . . . . . . . . . 4
1.3. Brief Summary of Changes from RFC 5512 . . . . . . . . . 5 1.3. Brief Summary of Changes from RFC 5512 . . . . . . . . . 5
1.4. Impact on RFC 5566 . . . . . . . . . . . . . . . . . . . 6 1.4. Use Case for The Tunnel Encapsulation Attribute . . . . . 6
2. The Tunnel Encapsulation Attribute . . . . . . . . . . . . . 6 2. The Tunnel Encapsulation Attribute . . . . . . . . . . . . . 7
3. Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . . . . . 8 3. Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . . . . . 9
3.1. The Tunnel Endpoint Sub-TLV . . . . . . . . . . . . . . . 8 3.1. The Tunnel Egress Endpoint Sub-TLV . . . . . . . . . . . 9
3.2. Encapsulation Sub-TLVs for Particular Tunnel Types . . . 10 3.1.1. Validating the Address Field . . . . . . . . . . . . 11
3.2.1. VXLAN . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Encapsulation Sub-TLVs for Particular Tunnel Types . . . 12
3.2.2. VXLAN-GPE . . . . . . . . . . . . . . . . . . . . . . 12 3.2.1. VXLAN . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.3. NVGRE . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.2. VXLAN GPE . . . . . . . . . . . . . . . . . . . . . . 14
3.2.4. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.3. NVGRE . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.5. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.4. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.6. MPLS-in-GRE . . . . . . . . . . . . . . . . . . . . . 15 3.2.5. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.7. IP-in-IP . . . . . . . . . . . . . . . . . . . . . . 16 3.2.6. MPLS-in-GRE . . . . . . . . . . . . . . . . . . . . . 17
3.3. Outer Encapsulation Sub-TLVs . . . . . . . . . . . . . . 16 3.3. Outer Encapsulation Sub-TLVs . . . . . . . . . . . . . . 18
3.3.1. IPv4 DS Field . . . . . . . . . . . . . . . . . . . . 16 3.3.1. DS Field . . . . . . . . . . . . . . . . . . . . . . 18
3.3.2. UDP Destination Port . . . . . . . . . . . . . . . . 17 3.3.2. UDP Destination Port . . . . . . . . . . . . . . . . 18
3.4. Sub-TLVs for Aiding Tunnel Selection . . . . . . . . . . 17 3.4. Sub-TLVs for Aiding Tunnel Selection . . . . . . . . . . 19
3.4.1. Protocol Type Sub-TLV . . . . . . . . . . . . . . . . 17 3.4.1. Protocol Type Sub-TLV . . . . . . . . . . . . . . . . 19
3.4.2. Color Sub-TLV . . . . . . . . . . . . . . . . . . . . 17 3.4.2. Color Sub-TLV . . . . . . . . . . . . . . . . . . . . 19
3.5. Embedded Label Handling Sub-TLV . . . . . . . . . . . . . 18 3.5. Embedded Label Handling Sub-TLV . . . . . . . . . . . . . 20
3.6. MPLS Label Stack Sub-TLV . . . . . . . . . . . . . . . . 19 3.6. MPLS Label Stack Sub-TLV . . . . . . . . . . . . . . . . 21
3.7. Prefix-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 20 3.7. Prefix-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 22
4. Extended Communities Related to the Tunnel Encapsulation 4. Extended Communities Related to the Tunnel Encapsulation
Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1. Encapsulation Extended Community . . . . . . . . . . . . 21 4.1. Encapsulation Extended Community . . . . . . . . . . . . 23
4.2. Router's MAC Extended Community . . . . . . . . . . . . . 23 4.2. Router's MAC Extended Community . . . . . . . . . . . . . 25
4.3. Color Extended Community . . . . . . . . . . . . . . . . 23 4.3. Color Extended Community . . . . . . . . . . . . . . . . 25
5. Semantics and Usage of the Tunnel Encapsulation attribute . . 23 5. Special Considerations for IP-in-IP Tunnels . . . . . . . . 25
6. Routing Considerations . . . . . . . . . . . . . . . . . . . 27 6. Semantics and Usage of the Tunnel Encapsulation attribute . . 26
6.1. Impact on BGP Decision Process . . . . . . . . . . . . . 27 7. Routing Considerations . . . . . . . . . . . . . . . . . . . 28
6.2. Looping, Infinite Stacking, Etc. . . . . . . . . . . . . 27 7.1. Impact on the BGP Decision Process . . . . . . . . . . . 28
7. Recursive Next Hop Resolution . . . . . . . . . . . . . . . . 28 7.2. Looping, Infinite Stacking, Etc. . . . . . . . . . . . . 29
8. Use of Virtual Network Identifiers and Embedded Labels when 8. Recursive Next Hop Resolution . . . . . . . . . . . . . . . . 29
Imposing a Tunnel Encapsulation . . . . . . . . . . . . . . . 28 9. Use of Virtual Network Identifiers and Embedded Labels when
8.1. Tunnel Types without a Virtual Network Identifier Field . 29 Imposing a Tunnel Encapsulation . . . . . . . . . . . . . . . 30
8.2. Tunnel Types with a Virtual Network Identifier Field . . 29 9.1. Tunnel Types without a Virtual Network Identifier Field . 30
8.2.1. Unlabeled Address Families . . . . . . . . . . . . . 30 9.2. Tunnel Types with a Virtual Network Identifier Field . . 31
8.2.2. Labeled Address Families . . . . . . . . . . . . . . 30 9.2.1. Unlabeled Address Families . . . . . . . . . . . . . 31
9. Applicability Restrictions . . . . . . . . . . . . . . . . . 31 9.2.2. Labeled Address Families . . . . . . . . . . . . . . 32
10. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. Applicability Restrictions . . . . . . . . . . . . . . . . . 33
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 32 11. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 12. Validation and Error Handling . . . . . . . . . . . . . . . . 34
12.1. Subsequent Address Family Identifiers . . . . . . . . . 34 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
12.2. BGP Path Attributes . . . . . . . . . . . . . . . . . . 34 13.1. Subsequent Address Family Identifiers . . . . . . . . . 36
12.3. Extended Communities . . . . . . . . . . . . . . . . . . 35 13.2. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . 36
12.4. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . 35 13.3. Flags Field of VXLAN Encapsulation sub-TLV . . . . . . . 36
12.5. Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 36 13.4. Flags Field of VXLAN GPE Encapsulation sub-TLV . . . . . 37
12.6. Flags Field of Vxlan Encapsulation sub-TLV . . . . . . . 36 13.5. Flags Field of NVGRE Encapsulation sub-TLV . . . . . . . 37
12.7. Flags Field of Vxlan-GPE Encapsulation sub-TLV . . . . . 36 13.6. Embedded Label Handling sub-TLV . . . . . . . . . . . . 37
12.8. Flags Field of NVGRE Encapsulation sub-TLV . . . . . . . 36 13.7. Extended Color Community . . . . . . . . . . . . . . . . 37
12.9. Embedded Label Handling sub-TLV . . . . . . . . . . . . 36 14. Security Considerations . . . . . . . . . . . . . . . . . . . 37
13. Security Considerations . . . . . . . . . . . . . . . . . . . 37 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 16. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 38
15. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 38 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 17.1. Normative References . . . . . . . . . . . . . . . . . . 39
16.1. Normative References . . . . . . . . . . . . . . . . . . 38 17.2. Informative References . . . . . . . . . . . . . . . . . 41
16.2. Informative References . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
This document obsoletes RFC 5512. The deficiencies of RFC 5512, and 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. 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 The material from RFC 5512 that is retained has been incorporated
into this document. into this document. Since [RFC5566] and [RFC5640] rely on RFC 5512,
they are likewise obsoleted.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.1. Brief Summary of RFC 5512 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.
[RFC5512] only allows the Tunnel Encapsulation attribute to be [RFC5512] only allows the Tunnel Encapsulation attribute to be
attached to BGP UPDATE messages of the Encapsulation Address Family. attached to BGP UPDATE messages of the Encapsulation Address Family.
These UPDATE messages have an AFI (Address Family Identifier) of 1 or These UPDATE messages have an AFI (Address Family Identifier) of 1 or
2, and a SAFI of 7. In an UPDATE of the Encapsulation SAFI, the NLRI 2, and a SAFI of 7. In an UPDATE of the Encapsulation SAFI, the NLRI
(Network Layer Reachability Information) is an address of the BGP (Network Layer Reachability Information) is an address of the BGP
speaker originating the UPDATE. Consider the following scenario: speaker originating the UPDATE. Consider the following scenario:
o BGP speaker R1 has received and installed UPDATE U; o BGP speaker R1 has received and selected UPDATE U for local use;
o UPDATE U's SAFI is the Encapsulation SAFI; o UPDATE U's SAFI is the Encapsulation SAFI;
o UPDATE U has the address R2 as its NLRI; o UPDATE U has the address R2 as its NLRI;
o UPDATE U has a Tunnel Encapsulation attribute. o UPDATE U has a Tunnel Encapsulation attribute.
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 route 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 tunnel egress Encapsulation attribute. The IP address of the tunnel egress
endpoint of each such tunnel is R2. Packet P is known as the endpoint of each such tunnel is R2. Packet P is known as the
tunnel's "payload". tunnel's "payload".
1.2. Deficiencies in RFC 5512 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
skipping to change at page 5, line 8 skipping to change at page 5, line 8
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 tunnel egress endpoint address of a given tunnel; specify the tunnel egress endpoint address of a given tunnel;
[RFC5512] assumes that the tunnel egress endpoint of each tunnel [RFC5512] assumes that the tunnel egress endpoint of each tunnel
is specified as the NLRI of an UPDATE of the Encapsulation-SAFI. is specified as 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 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 encapsulation, there is no way to signal the values of any of the
fields of the outer encapsulation. fields of the outer encapsulation.
o In [RFC5512]'s specification of the sub-TLVs, each sub-TLV has o In [RFC5512]'s specification of the sub-TLVs, each sub-TLV has
one-octet length field. In some cases, a two-octet length field one-octet length field. In some cases, a two-octet length field
may be needed. may be needed.
1.3. Brief Summary of Changes from RFC 5512 1.3. Brief Summary of Changes from RFC 5512
In this document we address these deficiencies by: This document addresses these deficiencies by:
o Deprecating the Encapsulation SAFI. o Deprecating the Encapsulation SAFI.
o Defining a new "Tunnel Endpoint sub-TLV" that can be included in o Defining a new "Tunnel Egress Endpoint sub-TLV" that can be
any of the TLVs contained in the Tunnel Encapsulation attribute. included in any of the TLVs contained in the Tunnel Encapsulation
This sub-TLV can be used to specify the remote endpoint address of attribute. This sub-TLV can be used to specify the remote
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 o Defining a number of new sub-TLVs that provide additional
information that is useful when forming the encapsulation header information that is useful when forming the encapsulation header
used to send a packet through a particular tunnel. used to send a packet through a particular tunnel.
o Defining the sub-TLV type field so that a sub-TLV whose type is in o Defining the sub-TLV type field so that a sub-TLV whose type is in
the range from 0 to 127 inclusive has a one-octet length field, the range from 0 to 127 inclusive has a one-octet length field,
but a sub-TLV whose type is in the range from 128 to 255 inclusive but a sub-TLV whose type is in the range from 128 to 255 inclusive
has a two-octet length field. has a two-octet length field.
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 (Virtual Extensible Local Area Network, [RFC7348]), [RFC5512]: VXLAN (Virtual Extensible Local Area Network, [RFC7348]),
VXLAN-GPE (Generic Protocol Extension for VXLAN, VXLAN GPE (Generic Protocol Extension for VXLAN,
[I-D.ietf-nvo3-vxlan-gpe]), NVGRE (Network Virtualization Using [I-D.ietf-nvo3-vxlan-gpe]), NVGRE (Network Virtualization Using
Generic Routing Encapsulation [RFC7637]), and MPLS-in-GRE (MPLS in Generic Routing Encapsulation [RFC7637]), and MPLS-in-GRE (MPLS in
Generic Routing Encapsulation [RFC2784], [RFC2890], [RFC4023]). Generic Routing Encapsulation [RFC4023]). MPLS-in-UDP [RFC7510] is
MPLS-in-UDP [RFC7510] is also supported, but an Encapsulation sub-TLV also supported, but an Encapsulation sub-TLV for it is not needed.
for it is not needed.
Some of the encapsulations mentioned in the previous paragraph need Some of the encapsulations mentioned in the previous paragraph need
to be further encapsulated inside UDP and/or IP. [RFC5512] provides to be further encapsulated inside UDP and/or IP. [RFC5512] provides
no way to specify that certain information is to appear in these no way to specify that certain information is to appear in these
outer IP and/or UDP encapsulations. This document provides a outer IP and/or UDP encapsulations. This document provides a
framework for including such information in the TLVs of the Tunnel framework for including such information in the TLVs of the Tunnel
Encapsulation attribute. Encapsulation attribute.
When the Tunnel Encapsulation attribute is attached to a BGP UPDATE When the Tunnel Encapsulation attribute is attached to a BGP UPDATE
whose AFI/SAFI identifies one of the labeled address families, it is whose AFI/SAFI identifies one of the labeled address families, it is
not always obvious whether the label embedded in the NLRI is to not always obvious whether the label embedded in the NLRI is to
appear somewhere in the tunnel encapsulation header (and if so, appear somewhere in the tunnel encapsulation header (and if so,
where), or whether it is to appear in the payload, or whether it can where), or whether it is to appear in the payload, or whether it can
be omitted altogether. This is especially true if the tunnel be omitted altogether. This is especially true if the tunnel
encapsulation header itself contains a "virtual network identifier". encapsulation header itself contains a "virtual network identifier".
This document provides a mechanism that allows one to signal (by This document provides a mechanism that allows one to signal (by
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.
1.4. Impact on RFC 5566 1.4. Use Case for The Tunnel Encapsulation Attribute
[RFC5566] uses the mechanisms defined in [RFC5512]. While this Consider the case of a router R1 forwarding an IP packet P. Let D be
document obsoletes [RFC5512], it does not address the issue of how to P's IP destination address. R1 must look up D in its forwarding
use the mechanisms of [RFC5566] without also using the Encapsulation table. Suppose that the "best match" route for D is route Q, where Q
SAFI. Those issues are considered to be outside the scope of this is a BGP-distributed route whose "BGP next hop" is router R2. And
document. suppose further that the routers along the path from R1 to R2 have
entries for R2 in their forwarding tables, but do NOT have entries
for D in their forwarding tables. For example, the path from R1 to
R2 may be part of a "BGP-free core", where there are no BGP-
distributed routes at all in the core. Or, as in [RFC5565], D may be
an IPv4 address while the intermediate routers along the path from R1
to R2 may support only IPv6.
In cases such as this, in order for R1 to properly forward packet P,
it must encapsulate P and send P "through a tunnel" to R2. For
example, R1 may encapsulate P using GRE, L2TPv3, IP in IP, etc.,
where the destination IP address of the encapsulation header is the
address of R2.
In order for R1 to encapsulate P for transport to R2, R1 must know
what encapsulation protocol to use for transporting different sorts
of packets to R2. R1 must also know how to fill in the various
fields of the encapsulation header. With certain encapsulation
types, this knowledge may be acquired by default or through manual
configuration. Other encapsulation protocols have fields such as
session id, key, or cookie that must be filled in. It would not be
desirable to require every BGP speaker to be manually configured with
the encapsulation information for every one of its BGP next hops.
This document specifies a way in which BGP itself can be used by a
given BGP speaker to tell other BGP speakers, "if you need to
encapsulate packets to be sent to me, here's the information you need
to properly form the encapsulation header". A BGP speaker signals
this information to other BGP speakers by using a new BGP attribute
type value, the BGP Tunnel Encapsulation Attribute. The Tunnel
Encapsulation attribute MAY be used in any BGP UPDATE message whose
AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6 Unicast), 1/4 (IPv4 Labeled
Unicast), 2/4 (IPv6 Labeled Unicast), 1/128 (VPN-IPv4 Labeled
Unicast), 2/128 (VPN-IPv6 Labeled Unicast), or 25/70 (Ethernet VPN,
usually known as EVPN)).
In a given BGP update, the encapsulation information is specified in
the BGP Tunnel Encapsulation Attribute. This attribute specifies the
encapsulation protocols that may be used as well as whatever
additional information (if any) is needed in order to properly use
those protocols. Other attributes, e.g., communities or extended
communities, may also be included.
2. The Tunnel Encapsulation Attribute 2. The Tunnel Encapsulation Attribute
The Tunnel Encapsulation attribute is an optional transitive BGP Path The Tunnel Encapsulation attribute is an optional transitive BGP Path
attribute. IANA has assigned the value 23 as the type code of the 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 attribute. The attribute is composed of a set of Type-Length-Value
(TLV) encodings. Each TLV contains information corresponding to a (TLV) encodings. Each TLV contains information corresponding to a
particular tunnel type. A TLV is structured as shown in Figure 1: particular Tunnel Type. A Tunnel Encapsulation TLV, also known as
Tunnel TLV, is structured as shown in Figure 1:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Type (2 Octets) | Length (2 Octets) | | Tunnel Type (2 Octets) | Length (2 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Value | | Value |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Tunnel Encapsulation TLV Value Field Figure 1: Tunnel Encapsulation TLV Value Field
o Tunnel Type (2 octets): identifies a type of tunnel. The field o Tunnel Type (2 octets): identifies a type of tunnel. The field
contains values from the IANA Registry "BGP Tunnel Encapsulation contains values from the IANA Registry "BGP Tunnel Encapsulation
Attribute Tunnel Types". Attribute Tunnel Types".
Note that for tunnel types whose names are of the form "X-in-Y", 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 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 "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 equivalent of specifying a Tunnel Type "Y" and including in its
TLV a Protocol Type sub-TLV (see Section 3.4.1) specifying TLV a Protocol Type sub-TLV (see Section 3.4.1) specifying
protocol "X". If the tunnel type is "X-in-Y", it is unnecessary, protocol "X". If the Tunnel Type is "X-in-Y", it is unnecessary,
though harmless, to include a Protocol Type sub-TLV specifying though harmless, to explicitly include a Protocol Type sub-TLV
"X". specifying "X". Also, for "X-in-Y" type tunnels, a Protocol Type
sub-TLV specifying anything other than "X" MUST be ignored; this
is discussed further in Section 12.
o Length (2 octets): the total number of octets of the value field. o Length (2 octets): the total number of octets of the value field.
o Value (variable): comprised of multiple sub-TLVs. o Value (variable): comprised of multiple sub-TLVs.
Each sub-TLV consists of three fields: a 1-octet type, a 1-octet or Each sub-TLV consists of three fields: a 1-octet type, a 1-octet or
2-octet length field (depending on the type), and zero or more octets 2-octet length field (depending on the type), and zero or more octets
of value. A sub-TLV is structured as shown in Figure 2: of value. A sub-TLV is structured as shown in Figure 2:
+--------------------------------+ +--------------------------------+
| Sub-TLV Type (1 Octet) | | Sub-TLV Type (1 Octet) |
+--------------------------------+ +--------------------------------+
| Sub-TLV Length (1 or 2 Octets) | | Sub-TLV Length (1 or 2 Octets) |
+--------------------------------+ +--------------------------------+
| Sub-TLV Value (Variable) | | Sub-TLV Value (Variable) |
+--------------------------------+ +--------------------------------+
Table 1: Tunnel Encapsulation Sub-TLV Format Figure 2: Encapsulation Sub-TLV Value Field
o Sub-TLV Type (1 octet): each sub-TLV type defines a certain o Sub-TLV Type (1 octet): each sub-TLV type defines a certain
property about the tunnel TLV that contains this sub-TLV. property about the Tunnel TLV that contains this sub-TLV. The
field contains values from the IANA Registry "BGP Tunnel
Encapsulation Attribute Sub-TLVs".
o Sub-TLV Length (1 or 2 octets): the total number of octets of the o Sub-TLV Length (1 or 2 octets): the total number of octets of the
sub-TLV value field. The Sub-TLV Length field contains 1 octet if sub-TLV value field. The Sub-TLV Length field contains 1 octet if
the Sub-TLV Type field contains a value in the range from 0-127. the Sub-TLV Type field contains a value in the range from 0-127.
The Sub-TLV Length field contains two octets if the Sub-TLV Type The Sub-TLV Length field contains two octets if the Sub-TLV Type
field contains a value in the range from 128-255. field contains a value in the range from 128-255.
o Sub-TLV Value (variable): encodings of the value field depend on o Sub-TLV Value (variable): encodings of the value field depend on
the sub-TLV type as enumerated above. The following sub-sections the sub-TLV type as enumerated above. The following sub-sections
define the encoding in detail. define the encoding in detail.
3. Tunnel Encapsulation Attribute Sub-TLVs 3. Tunnel Encapsulation Attribute Sub-TLVs
In this section, we specify a number of sub-TLVs. These sub-TLVs can This section specifies a number of sub-TLVs. These sub-TLVs can be
be included in a TLV of the Tunnel Encapsulation attribute. included in a TLV of the Tunnel Encapsulation attribute.
3.1. The Tunnel Endpoint Sub-TLV 3.1. The Tunnel Egress Endpoint Sub-TLV
The Tunnel Endpoint sub-TLV specifies the address of the endpoint of The Tunnel Egress Endpoint sub-TLV specifies the address of the
the tunnel, that is, the address of the router that will decapsulate egress endpoint of the tunnel, that is, the address of the router
the payload. It is a sub-TLV whose value field contains three sub- that will decapsulate the payload. It is a sub-TLV whose value field
fields: contains three subfields:
1. a four-octet Autonomous System (AS) number sub-field 1. a reserved subfield
2. a two-octet Address Family sub-field 2. a two-octet Address Family subfield
3. an address sub-field, whose length depends upon the Address 3. an Address subfield, 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 | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Address ~ | Address Family | Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Tunnel Endpoint Sub-TLV Value Field Figure 3: Tunnel Egress Endpoint Sub-TLV Value Field
The Reserved subfield SHOULD be originated as zero. It MUST be
disregarded on receipt, and it MUST be propagated unchanged.
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. This document assumes that the Address
Address Family is either IPv4 or IPv6; use of other address families Family is either IPv4 or IPv6; use of other address families is
is outside the scope of this document. 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 Tunnel Endpoint sub-TLV must
contain the value 10 (0xa).
If the Address Family subfield contains the value for IPv6, the If the Address Family subfield contains the value for IPv6, the
address sub-field must contain an IPv6 address (a /128 IPv6 prefix). address subfield MUST contain an IPv6 address (a /128 IPv6 prefix).
In this case, the length field of Tunnel Endpoint sub-TLV must
contain the value 22 (0x16). IPv6 link local addresses are not valid
values of the IP address field.
In a given BGP UPDATE, the address family (IPv4 or IPv6) of a Tunnel In a given BGP UPDATE, the address family (IPv4 or IPv6) of a Tunnel
Endpoint sub-TLV is independent of the address family of the UPDATE Egress Endpoint sub-TLV is independent of the address family of the
itself. For example, an UPDATE whose NLRI is an IPv4 address may UPDATE itself. For example, an UPDATE whose NLRI is an IPv4 address
have a Tunnel Encapsulation attribute containing Tunnel Endpoint sub- may have a Tunnel Encapsulation attribute containing Tunnel Egress
TLVs that contain IPv6 addresses. Also, different tunnels Endpoint sub-TLVs that contain IPv6 addresses. Also, different
represented in the Tunnel Encapsulation attribute may have Tunnel tunnels represented in the Tunnel Encapsulation attribute may have
Endpoints of different address families. tunnel egress endpoints of different address families.
A two-octet AS number can be carried in the AS number field by There is one special case: the Tunnel Egress Endpoint sub-TLV MAY
setting the two high order octets to zero, and carrying the number in have a value field whose Address Family subfield contains 0. This
the two low order octets of the field. means that the tunnel's egress endpoint is the address of the next
hop. If the Address Family subfield contains 0, the Address subfield
is omitted. In this case, the length field of Tunnel Egress Endpoint
sub-TLV MUST contain the value 6 (0x06).
The AS number in the sub-TLV MUST be the number of the AS to which When the Tunnel Encapsulation attribute is carried in an UPDATE
the IP address in the sub-TLV belongs. message of one of the AFI/SAFIs specified above, each TLV MUST have
one, and one only, Tunnel Egress Endpoint sub-TLV. If a TLV does not
have a Tunnel Egress Endpoint sub-TLV, that TLV should be treated as
if it had a malformed Tunnel Egress Endpoint sub-TLV (see below).
There is one special case: the Tunnel Endpoint sub-TLV MAY have a If any of the following conditions hold, the Tunnel Egress Endpoint
value field whose Address Family subfield contains 0. This means sub-TLV is considered to be "malformed":
that the tunnel's egress endpoint is the UPDATE's BGP next hop. If
the Address Family subfield contains 0, the Address subfield is
omitted, and the Autonomous System number field is set to 0.
If any of the following conditions hold, the Tunnel Endpoint sub-TLV o The length of the sub-TLV's Value field is other than 6 plus the
is considered to be "malformed": defined length for the address family given in its Address Family
subfield. Therefore, for address family behaviors defined in this
document, the permitted values are:
o The sub-TLV contains the value for IPv4 in its Address Family * 10, if the Address Family subfield contains the value for IPv4.
subfield, but the length of the sub-TLV's value field is other
than 10 (0xa).
o The sub-TLV contains the value for IPv6 in its Address Family * 22, if the Address Family subfield contains the value for IPv6.
subfield, but the length of the sub-TLV's value field is other
than 22 (0x16).
o The sub-TLV contains the value zero in its Address Family field, * 0, if the Address Family subfield contains the value zero.
but the length of the sub-TLV's value field is other than 6, or
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 listed in the
address (e.g., it's an IPv4 broadcast address). relevant Special-Purpose IP Address Registry [RFC6890] as either
not a valid destination, or not forwardable.
o It can be determined that the IP address in the sub-TLV's address o It can be determined according to the procedures below
subfield does not belong to the non-zero AS whose number is in the (Section 3.1.1) that the IP address in the sub-TLV's address
its Autonomous System subfield. (See section Section 13 for subfield does not belong to the Autonomous System (AS) that
discussion of one way to determine this.) originated the route that contains the attribute.
If the Tunnel Endpoint sub-TLV is malformed, the TLV containing it is If the Tunnel Egress Endpoint sub-TLV is malformed, the TLV
also considered to be malformed, and the entire TLV MUST be ignored. containing it is also considered to be malformed. However, the
However, the Tunnel Encapsulation attribute MUST NOT be considered to Tunnel Encapsulation attribute MUST NOT be considered to be malformed
be malformed in this case; other TLVs in the attribute MUST be in this case; other TLVs in the attribute MUST be processed (if they
processed (if they can be parsed correctly). can be parsed correctly).
When redistributing a route that is carrying a Tunnel Encapsulation Error Handling is detailed in Section 11.
attribute containing a TLV that itself contains a malformed Tunnel
Endpoint sub-TLV, the TLV MUST be removed from the attribute before
redistribution.
See Section 11 for further discussion of how to handle errors that If the Tunnel Egress Endpoint sub-TLV contains an IPv4 or IPv6
are encountered when parsing the Tunnel Encapsulation attribute. address that is valid but not reachable, the sub-TLV is NOT
considered to be malformed.
If the Tunnel Endpoint sub-TLV contains an IPv4 or IPv6 address that 3.1.1. Validating the Address Field
is valid but not reachable, the sub-TLV is NOT considered to be
malformed. This section details a procedure that MAY be applied to validate that
when traffic is sent to the IP address depicted in the Address Field,
it will go to the same AS as it would go to if the Tunnel
Encapsulation Attribute were not present. See Section 13 for
discussion of the limitations of this procedure.
The Route Origin ASN (Autonomous System Number) of a BGP route that
includes a Tunnel Encapsulation Attribute can be determined by
inspection of the AS_PATH attribute, according to the procedure
specified in [RFC6811] section 2. Call this value Route_AS.
In order to determine the Route Origin ASN of the address depicted in
the Address Field of the Tunnel Egress Endpoint sub-TLV, it is
necessary to determine the forwarding route, that is, the route
installed in the Forwarding Information Base that will be used to
forward traffic toward that address. The Address Field's Route
Origin ASN is the Route Origin ASN of that route, or the
distinguished value "NONE2" if the forwarding route has no AS Path,
for example if that route's source is a protocol other than BGP.
(Note that this is a distinct case from a route that has an empty AS
Path.) Call this value Egress_AS.
If Route_AS does not equal Egress_AS, then the Tunnel Egress Endpoint
sub-TLV is considered not to be valid. In some cases a network
operator who controls a set of Autonomous Systems might wish to allow
a Tunnel Egress Endpoint to reside in an AS other than Route_AS;
configuration MAY allow for such a case, in which case the check
becomes, if Egress_AS is not within the configured set of permitted
AS numbers, then the Tunnel Egress Endpoint sub-TLV is considered not
to be valid.
Note that if the forwarding route changes, this procedure MUST be
reapplied. As a result, a sub-TLV that was formerly considered valid
might become not valid, or vice-versa.
3.2. Encapsulation Sub-TLVs for Particular Tunnel Types 3.2. Encapsulation Sub-TLVs for Particular Tunnel Types
This section defines Tunnel Encapsulation sub-TLVs for the following This section defines Encapsulation sub-TLVs for the following tunnel
tunnel types: VXLAN ([RFC7348]), VXLAN-GPE types: VXLAN ([RFC7348]), VXLAN GPE ([I-D.ietf-nvo3-vxlan-gpe]),
([I-D.ietf-nvo3-vxlan-gpe]), NVGRE ([RFC7637]), MPLS-in-GRE NVGRE ([RFC7637]), MPLS-in-GRE ([RFC4023]), L2TPv3 ([RFC3931]), and
([RFC2784], [RFC2890], [RFC4023]), L2TPv3 ([RFC3931]), and GRE GRE ([RFC2784]).
([RFC2784], [RFC2890], [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 Sections 5 and 8. given TLV are given in Sections 5 and 8.
There are also tunnel types for which it is not necessary to define Recall that the Tunnel Type itself is identified by the Tunnel Type
an Encapsulation sub-TLV, because there are no fields in the field in the attribute header (Section 2); the Encapsulation sub-
TLV's structure is inferred from this. Regardless of the Tunnel
Type, the sub-TLV type of the Encapsulation sub-TLV is 1. There are
also tunnel types for which it is not necessary to define an
Encapsulation sub-TLV, because there are no fields in the
encapsulation header whose values need to be signaled from the tunnel encapsulation header whose values need to be signaled from the tunnel
egress endpoint. egress endpoint.
3.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 (value 8), the length of the sub-TLV is
value field in the encapsulation sub-TLV: 12 octets. The following is the structure of 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 3: VXLAN Encapsulation Sub-TLV Figure 4: VXLAN Encapsulation Sub-TLV
V: This bit is set to 1 to indicate that a "valid" VN-ID (Virtual V: This bit is set to 1 to indicate that a VN-ID (Virtual Network
Network Identifier) is present in the encapsulation sub-TLV. Identifier) is present in the Encapsulation sub-TLV. If set to 0,
Please see Section 8. the VN-ID field is disregarded. 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 MAC Address is present
present in the encapsulation sub-TLV. in the Encapsulation sub-TLV. If set to 0, the MAC Address field
is disregarded.
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 MUST always be set to 0 by the originator of further use. They MUST always be set to 0 by the originator of
the sub-TLV. Intermediate routers MUST propagate them without the sub-TLV. Intermediate routers MUST propagate them without
modification. Any receiving routers MUST ignore these bits upon a modification. Any receiving routers MUST ignore these bits upon a
receipt of the sub-TLV. receipt of the sub-TLV.
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 MUST be set to ID value. If the V bit is not set, the VN-ID field MUST be set to
zero. zero on transmission and disregarded on receipt.
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 MUST be Ethernet MAC address. If the M bit is not set, this field MUST be
set to all zeroes. set to all zeroes on transmission and disregarded on receipt.
Reserved: MUST be set to zero on transmission and disregarded on
receipt.
When forming the VXLAN encapsulation header: When forming the VXLAN 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 VXLAN header. The flags field of the VXLAN header is field of the VXLAN header. The flags field of the VXLAN header is
set as per [RFC7348]. set as per [RFC7348].
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 5 of [RFC7348]). section 5 of [RFC7348]).
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 8 to see how the VNI field of the VXLAN encapsulation o Section 8 describes how the VNI field of the VXLAN encapsulation
header is set. header is set.
Note that in order to send an IP packet or an MPLS packet through a Note that in order to send an IP packet or an MPLS packet through a
VXLAN tunnel, the packet must first be encapsulated in an ethernet VXLAN tunnel, the packet must first be encapsulated in an Ethernet
header, which becomes the "inner ethernet header" described in header, which becomes the "inner Ethernet header" described in
[RFC7348]. The VXLAN Encapsulation sub-TLV may contain information [RFC7348]. The VXLAN Encapsulation sub-TLV may contain information
(e.g.,the MAC address) that is used to form this ethernet header. (e.g.,the MAC address) that is used to form this Ethernet header.
3.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 GPE tunnels.
When the tunnel type is VXLAN-GPE, the following is the structure of When the Tunnel Type is VXLAN GPE (value 12), the length of the sub-
the value field in the encapsulation sub-TLV: TLV is 8 octets and following is the structure of 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 4: 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 in the encapsulation sub-TLV. Please see Section 8.
R: The bits designated "R" above are reserved for future use.
They MUST always be set to 0 by the originator of the sub-TLV.
Intermediate routers MUST propagate them without modification.
Any receiving routers MUST ignore these bits upon a receipt of the
sub-TLV.
Version (Ver): Indicates VXLAN GPE protocol version. (See the Version (Ver): Indicates VXLAN GPE protocol version. (See the
"Version Bits" section of [I-D.ietf-nvo3-vxlan-gpe].) If the "Version Bits" section of [I-D.ietf-nvo3-vxlan-gpe].) 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.
V: This bit is set to 1 to indicate that a VN-ID is present in the
Encapsulation sub-TLV. If set to 0, the VN-ID field is
disregarded. Please see Section 8.
R: The bits designated "R" above are reserved for future use.
They MUST always be set to 0 by the originator of the sub-TLV.
Intermediate routers MUST propagate them without modification.
Any receiving routers MUST ignore these bits upon a receipt.
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 MUST be set to zero. value. If the V bit is not set, this field MUST be set to zero on
transmission and disregarded on receipt.
When forming the VXLAN-GPE encapsulation header: Reserved (two fields): MUST be set to zero on transmission and
disregarded on receipt.
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 [I-D.ietf-nvo3-vxlan-gpe]. of the VXLAN GPE header are set as per [I-D.ietf-nvo3-vxlan-gpe].
o See Section 8 to see how the VNI field of the VXLAN-GPE o Section 8 describes how the VNI field of the VXLAN GPE
encapsulation header is set. encapsulation header is set.
3.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 (value 9), the length of the sub-TLV is
value field in the encapsulation sub-TLV: 12 octets. The following is the structure of 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 5: 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 V: This bit is set to 1 to indicate that a VN-ID is present in the
present in the encapsulation sub-TLV. Please see Section 8. Encapsulation sub-TLV. If set to 0, the VN-ID field is
disregarded. 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 MAC Address is present
present in the encapsulation sub-TLV. in the Encapsulation sub-TLV. If set to 0, the MAC Address field
is disregarded.
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 MUST always be set to 0 by the originator of further use. They MUST always be set to 0 by the originator of
the sub-TLV. Intermediate routers MUST propagate them without the sub-TLV. Intermediate routers MUST propagate them without
modification. Any receiving routers MUST ignore these bits upon a modification. Any receiving routers MUST ignore these bits upon
receipt of the sub-TLV. receipt.
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 MUST be set to ID value. If the V bit is not set, the VN-ID field MUST be set to
zero. zero on transmission and disregarded on receipt.
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 MUST be Ethernet MAC address. If the M bit is not set, this field MUST be
set to all zeroes. set to all zeroes on transmission and disregarded on receipt.
Reserved (two fields): MUST be set to zero on transmission and
disregarded on receipt.
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 [RFC7637]. 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 [RFC7637]). 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 8 to see how the VSID (Virtual Subnet Identifier) o Section 8 describes how the VSID (Virtual Subnet Identifier) field
field of the NVGRE encapsulation header is set. of the NVGRE encapsulation header is set.
3.2.4. L2TPv3 3.2.4. L2TPv3
When the tunnel type of the TLV is L2TPv3 over IP, the following is When the Tunnel Type of the TLV is L2TPv3 over IP (value 1), the
the structure of the value field of the encapsulation sub-TLV: length of the sub-TLV is 8 octets. The following is the structure of
the value field of 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID (4 octets) | | Session ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Cookie (Variable) | | Cookie (Variable) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: L2TPv3 Encapsulation Sub-TLV Figure 7: L2TPv3 Encapsulation Sub-TLV
Session ID: a non-zero 4-octet value locally assigned by the Session ID: a non-zero 4-octet value locally assigned by the
advertising router that serves as a lookup key in the incoming advertising router that serves as a lookup key for the incoming
packet's context. packet's context.
Cookie: an optional, variable length (encoded in octets -- 0 to 8 Cookie: an optional, variable length (encoded in octets -- 0 to 8
octets) value used by L2TPv3 to check the association of a octets) value used by L2TPv3 to check the association of a
received data message with the session identified by the Session received data message with the session identified by the Session
ID. Generation and usage of the cookie value is as specified in ID. Generation and usage of the cookie value is as specified in
[RFC3931]. [RFC3931].
The length of the cookie is not encoded explicitly, but can be The length of the cookie is not encoded explicitly, but can be
calculated as (sub-TLV length - 4). calculated as (sub-TLV length - 4).
3.2.5. GRE 3.2.5. GRE
When the tunnel type of the TLV is GRE, the following is the When the Tunnel Type of the TLV is GRE (value 2), the length of the
structure of the value field of the encapsulation sub-TLV: sub-TLV is 4 octets. The following is the structure of the value
field of 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Key (4 octets) | | GRE Key (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: GRE Encapsulation Sub-TLV Figure 8: 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. Note that the key is optional. Unless a key
obtained is beyond the scope of this document. The key is value is being advertised, the GRE Encapsulation sub-TLV MUST NOT
inserted into the GRE encapsulation header of the payload packets be present.
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.6. MPLS-in-GRE 3.2.6. MPLS-in-GRE
When the tunnel type is MPLS-in-GRE, the following is the structure When the Tunnel Type is MPLS-in-GRE (value 11), the length of the
of the value field in an optional encapsulation sub-TLV: sub-TLV is 4 octets. The following is the structure of the value
field of 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE-Key (4 Octets) | | GRE-Key (4 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: MPLS-in-GRE Encapsulation Sub-TLV Figure 9: 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. Note that the key is optional. Unless a key
obtained is beyond the scope of this document. The key is value is being advertised, the MPLS-in-GRE Encapsulation sub-TLV
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 MPLS-in-GRE encapsulation sub-TLV
MUST NOT be present. MUST NOT be present.
Note that the GRE tunnel type defined in Section 3.2.5 can be used Note that the GRE Tunnel Type defined in Section 3.2.5 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 (Section 3.4.1) specifying MPLS also includes a Protocol Type sub-TLV (Section 3.4.1) specifying MPLS
as the protocol to be encapsulated. That is, if a TLV specifies as the protocol to be encapsulated.
MPLS-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 packets.
While it is not really necessary to have both the GRE and MPLS-in-GRE While it is not really necessary to have both the GRE and MPLS-in-GRE
tunnel types, both are included for reasons of backwards tunnel types, both are included for reasons of backwards
compatibility. compatibility.
3.2.7. IP-in-IP
When the tunnel type of the TLV is IP-in-IP, it does not have Virtual
Network Identifier. See for Section 8.1 Embedded Label handling on
IP-in-IP tunnels.
3.3. Outer Encapsulation Sub-TLVs 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
is treated as if it were an unknown type of sub-TLV. MUST be treated as if it were an unknown type of sub-TLV.
3.3.1. IPv4 DS Field 3.3.1. 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
Differentiated Services (DS) Field sub-TLV can be carried in the TLV Differentiated Services (DS) Field sub-TLV, whose type code is 7, can
of any such tunnel type. It specifies the setting of the one-octet be carried in the TLV of any such Tunnel Type. It specifies the
Differentiated Services field in the outer IP encapsulation (see setting of the one-octet Differentiated Services field in the outer
[RFC2474]). The value field is always a single octet. IPv4 or IPv6 encapsulation (see [RFC2474]). The value field is
always a single octet.
3.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, whose
value field of this sub-TLV is always a two-octet field, containing type code is 8. The value field of this sub-TLV is always a two-
the port value. octet field, containing the port value.
3.4. Sub-TLVs for Aiding Tunnel Selection 3.4. Sub-TLVs for Aiding Tunnel Selection
3.4.1. Protocol Type Sub-TLV 3.4.1. Protocol Type Sub-TLV
The protocol type sub-TLV MAY be included in a given TLV to indicate The Protocol Type sub-TLV, whose type code is 2, MAY be included in a
the type of the payload packets that may be encapsulated with the given TLV to indicate the type of the payload packets that are
tunnel parameters that are being signaled in the TLV. The value allowed to be encapsulated with the tunnel parameters that are being
field of the sub-TLV contains a 2-octet value from IANA's ethertype signaled in the TLV. Packets with other payload types MUST NOT be
registry [Ethertypes]. encapsulated in the relevant tunnel. The value field of the sub-TLV
contains a 2-octet value from IANA's "ETHER TYPES" registry
[Ethertypes].
For example, if we want to use three L2TPv3 sessions, one carrying For example, if there are three L2TPv3 sessions, one carrying IPv4
IPv4 packets, one carrying IPv6 packets, and one carrying MPLS packets, one carrying IPv6 packets, and one carrying MPLS packets,
packets, the egress router will include three TLVs of L2TPv3 the egress router will include three TLVs of L2TPv3 encapsulation
encapsulation type, each specifying a different Session ID and a type, each specifying a different Session ID and a different payload
different payload type. The protocol type sub-TLV for these will be type. The Protocol Type sub-TLV for these will be IPv4 (protocol
IPv4 (protocol type = 0x0800), IPv6 (protocol type = 0x86dd), and type = 0x0800), IPv6 (protocol type = 0x86dd), and MPLS (protocol
MPLS (protocol type = 0x8847), respectively. This informs the type = 0x8847), respectively. This informs the ingress routers of
ingress routers of the appropriate encapsulation information to use the appropriate encapsulation information to use with each of the
with each of the given protocol types. Insertion of the specified given protocol types. Insertion of the specified Session ID at the
Session ID at the ingress routers allows the egress to process the ingress routers allows the egress to process the incoming packets
incoming packets correctly, according to their protocol type. correctly, according to their protocol type.
3.4.2. Color Sub-TLV Note that it is unnecessary to explicitly include this sub-TLV in
tunnels whose names are of the form "X-in-Y", as discussed in
Section 2.
The color sub-TLV MAY be encoded as a way to "color" the 3.4.2. Color Sub-TLV
corresponding tunnel TLV. The value field of the sub-TLV is eight
octets long, and 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.
Note that the high-order octet of this sub-TLV's value field MUST be The Color sub-TLV, whose type code is 4, MAY be used as a way to
set to 3, and the next octet MUST be set to 0x0b. (Otherwise the "color" the corresponding Tunnel TLV. The value field of the sub-TLV
value field is not identical to a Color Extended Community.) is eight octets long, and 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.
If a Color sub-TLV is not of the proper length, or the first two If the Length field of a Color sub-TLV has a value other than 8, or
octets of its value field are not 0x030b, the sub-TLV should be the first two octets of its value field are not 0x030b, the sub-TLV
treated as if it were an unrecognized sub-TLV (see Section 11). should be treated as if it were an unrecognized sub-TLV (see
Section 11).
3.5. Embedded Label Handling Sub-TLV 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. The term "embedded label" is used to refer to the MPLS
MPLS label that is embedded in an NLRI, and the term "labeled address 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 a "Virtual Network" identifier of
sort. The Encapsulation sub-TLVs for these tunnel types may some sort. The Encapsulation sub-TLVs for these tunnel types may
optionally specify a value for the virtual network identifier. optionally specify a value for the virtual network identifier.
Suppose a Tunnel Encapsulation attribute is attached to an UPDATE of Suppose a Tunnel Encapsulation attribute is attached to an UPDATE of
an embedded address family, and it is decided to use a particular a labeled address family, and it is decided to use a particular
tunnel (specified in one of the attribute's TLVs) for transmitting a tunnel (specified in one of the attribute's TLVs) for transmitting a
packet that is being forwarded according to that UPDATE. When packet that is being forwarded according to that UPDATE. When
forming the encapsulation header for that packet, different forming the encapsulation header for that packet, different
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, whose type code is 9, may be
Tunnel Encapsulation attribute. If the Tunnel Encapsulation included in any TLV of the Tunnel Encapsulation attribute. If the
attribute is attached to an UPDATE of a non-labeled address family, Tunnel Encapsulation attribute is attached to an UPDATE of a non-
the sub-TLV is treated as a no-op. If the sub-TLV is contained in a labeled address family, then the sub-TLV MUST be disregarded. If the
TLV whose tunnel type does not have a virtual network identifier in sub-TLV is contained in a TLV whose Tunnel Type does not have a
its encapsulation header, the sub-TLV is treated as a no-op. In virtual network identifier in its encapsulation header, the sub-TLV
those cases where the sub-TLV is treated as a no-op, it SHOULD NOT be MUST be disregared. In those cases where the sub-TLV is ignored, it
stripped from the TLV before the UPDATE is forwarded. SHOULD NOT be stripped from the TLV before the route is propagated.
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 8 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.
3.6. MPLS Label Stack Sub-TLV 3.6. MPLS Label Stack Sub-TLV
This sub-TLV allows an MPLS label stack ([RFC3032]) to be associated This sub-TLV, whose type code is 10, allows an MPLS label stack
with a particular tunnel. ([RFC3032]) to be associated with a particular tunnel.
The value field of this sub-TLV is a sequence of MPLS label stack The length of the sub-TLV is a multiple of 4 octets and the value
entries. The first entry in the sequence is the "topmost" label, the field of this sub-TLV is a sequence of MPLS label stack entries. The
final entry in the sequence is the "bottommost" label. When this first entry in the sequence is the "topmost" label, the final entry
label stack is pushed onto a packet, this ordering MUST be preserved. in the sequence is the "bottommost" label. When this label stack is
pushed onto a packet, this ordering MUST be preserved.
Each label stack entry has the following format: Each label stack entry has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL | | Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: MPLS Label Stack Sub-TLV Figure 10: MPLS Label Stack Sub-TLV
The fields are as defined in [RFC3032], [RFC5462].
If a packet is to be sent through the tunnel identified in a 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, 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 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 packet before any other labels are pushed onto the packet.
other labels are pushed onto the packet.
In particular, if the Tunnel Encapsulation attribute is attached to a In particular, if the Tunnel Encapsulation attribute is attached to a
BGP UPDATE of a labeled address family, the contents of the MPLS 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 Label Stack sub-TLV MUST be pushed onto the packet before the label
embedded in the NLRI is pushed onto the packet. embedded in the NLRI is pushed onto the packet.
If the MPLS label stack sub-TLV is included in a TLV identifying a If the MPLS Label Stack sub-TLV is included in a TLV identifying a
tunnel type that uses virtual network identifiers (see Section 8), Tunnel Type that uses virtual network identifiers (see Section 8),
the contents of the MPLS label stack sub-TLV MUST be pushed onto the the contents of the MPLS Label Stack sub-TLV MUST be pushed onto the
packet before the procedures of Section 8 are applied. packet before the procedures of Section 8 are applied.
The number of label stack entries in the sub-TLV MUST be determined 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 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 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 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 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, the S bits of all the entries being pushed MUST be cleared.
stack entries are pushed onto a packet that does not already have a When the label stack entries are pushed onto a packet that does not
label stack, the S bit of the bottommost label stack entry MUST be already have a label stack, the S bit of the bottommost label stack
set, and the S bit of all the other label stack entries MUST be entry MUST be set, and the S bit of all the other label stack entries
cleared. MUST be cleared.
By default, the TC (Traffic Class) field ([RFC3032], [RFC5462]) of The TC (Traffic Class) field ([RFC3270], [RFC5129]) of each label
each label stack entry is set to 0. This may of course be changed by stack entry SHOULD be set to 0, unless changed by policy at the
policy at the originator of the sub-TLV. When pushing the label originator of the sub-TLV. When pushing the label stack onto a
stack onto a packet, the TC of the label stack entries is preserved packet, the TC of each label stack SHOULD be preserved, unless local
by default. However, local policy at the router that is pushing on policy results in a modification.
the stack MAY cause modification of the TC values.
By default, the TTL (Time to Live) field of each label stack entry is The TTL (Time to Live) field of each label stack entry SHOULD be set
set to 255. This may be changed by policy at the originator of the to 255, unless changed to some other non-zero value by policy at the
sub-TLV. When pushing the label stack onto a packet, the TTL of the originator of the sub-TLV. When pushing the label stack onto a
label stack entries is preserved by default. However, local policy packet, the TTL of each label stack entry SHOULD be preserved, unless
at the router that is pushing on the stack MAY cause modification of local policy results in a modification to some other non-zero value.
the TTL values. If any label stack entry in the sub-TLV has a TTL If any label stack entry in the sub-TLV has a TTL value of zero, the
value of zero, the router that is pushing the stack on a packet MUST router that is pushing the stack on a packet MUST change the value to
change the value to a non-zero value. a non-zero value, either 255 or some other value as determined by
policy as discussed above.
Note that this sub-TLV can appear within a TLV identifying any type Note that this sub-TLV can appear within a TLV identifying any type
of tunnel, not just within a TLV identifying an MPLS tunnel. of tunnel, not just within a TLV identifying an MPLS tunnel.
However, if this sub-TLV appears within a TLV identifying an MPLS 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 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 that would be played by an MPLS Encapsulation sub-TLV. Therefore, an
MPLS Encapsulation sub-TLV is not defined. MPLS Encapsulation sub-TLV is not defined.
3.7. Prefix-SID Sub-TLV 3.7. Prefix-SID Sub-TLV
[I-D.ietf-idr-bgp-prefix-sid] defines a BGP Path attribute known as [RFC8669] defines a BGP Path attribute known as the "Prefix-SID
the "Prefix-SID Attribute". This attribute is defined to contain a Attribute". This attribute is defined to contain a sequence of one
sequence of one or more TLVs, where each TLV is either a "Label- or more TLVs, where each TLV is either a "Label-Index" TLV, or an
Index" TLV, or an "Originator SRGB (Source Routing Global Block)" "Originator SRGB (Source Routing Global Block)" TLV.
TLV.
In this document, we define a Prefix-SID sub-TLV. The value field of This document defines a Prefix-SID sub-TLV, whose type code is 11.
the Prefix-SID sub-TLV can be set to any valid value of the value The value field of the Prefix-SID sub-TLV can be set to any permitted
field of a BGP Prefix-SID attribute, as defined in value of the value field of a BGP Prefix-SID attribute [RFC8669].
[I-D.ietf-idr-bgp-prefix-sid].
[RFC8669] only defines behavior when the Prefix-SID Attribute is
attached to routes of type IPv4/IPv6 Labeled Unicast ([RFC4760],
[RFC8277]), and it only defines values of the Prefix-SID Attribute
when attached to routes of those types. Therefore, similar
limitations exist for the Prefix-SID sub-TLV: although it MAY be
encoded in any BGP UPDATE message where the Tunnel Encapsulation
attribute is allowed (see Section 5), the encoded information MUST be
ignored just as the base specification that defines the encoding
requires. So, in the case of the values specified in [RFC8669], they
MUST be ignored if received with routes of type other than IPv4/IPv6
Labeled Unicast.
The Prefix-SID sub-TLV can occur in a TLV identifying any type of 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, that SRGB tunnel. If an Originator SRGB is specified in the sub-TLV, that SRGB
MUST be interpreted to be the SRGB used by the tunnel's egress MUST be interpreted to be the SRGB used by the tunnel's egress
endpoint. The Label-Index, if present, is the Segment Routing SID endpoint. The Label-Index, if present, is the Segment Routing SID
that the tunnel's egress endpoint uses to represent the prefix that the tunnel's egress endpoint uses to represent the prefix
appearing in the NLRI field of the BGP UPDATE to which the Tunnel appearing in the NLRI field of the BGP UPDATE to which the Tunnel
Encapsulation attribute is attached. Encapsulation attribute is attached.
If a Label-Index is present in the prefix-SID sub-TLV, then when a 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 packet is sent through the tunnel identified by the TLV, the
corresponding MPLS label MUST be pushed on the packet's label stack. corresponding MPLS label MUST be pushed on the packet's label stack.
The corresponding MPLS label is computed from the Label-Index value The corresponding MPLS label is computed from the Label-Index value
and the SRGB of the route's originator. and the SRGB of the route's originator, as specified in section 4.1
of [RFC8669].
If the Originator SRGB is not present, it is assumed that the
originator's SRGB is known by other means. Such "other means" are
outside the scope of this document.
The corresponding MPLS label is pushed on after the processing of the 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. 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 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 UPDATE's NLRI, or a label determined by the procedures of Section 8,
are pushed on the stack. are pushed on the stack.
The Prefix-SID sub-TLV has slightly different semantics than the The Prefix-SID sub-TLV has slightly different semantics than the
Prefix-SID attribute. When the Prefix-SID attribute is attached to a Prefix-SID attribute. When the Prefix-SID attribute is attached to a
given route, the BGP speaker that originally attached the attribute given route, the BGP speaker that originally attached the attribute
is expected to be in the same Segment Routing domain as the BGP is expected to be in the same Segment Routing domain as the BGP
speakers who receive the route with the attached attribute. The speakers who receive the route with the attached attribute. The
Label-Index tells the receiving BGP speakers that the prefix-SID is Label-Index tells the receiving BGP speakers what the prefix-SID is
for the advertised prefix in that Segment Routing domain. When the 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 Prefix-SID sub-TLV is used, the receiving BGP speaker need not even
tunnel need even not be in the same Segment Routing Domain as the be in the same Segment Routing Domain as the tunnel's egress
tunnel's egress endpoint, and there is no implication that the endpoint, and there is no implication that the prefix-SID for the
prefix-SID for the advertised prefix is the same in the Segment advertised prefix is the same in the Segment Routing domains of the
Routing domains of the BGP speaker that originated the sub-TLV and BGP speaker that originated the sub-TLV and the BGP speaker that
the BGP speaker that received it. received it.
4. Extended Communities Related to the Tunnel Encapsulation Attribute 4. Extended Communities Related to the Tunnel Encapsulation Attribute
4.1. Encapsulation Extended Community 4.1. Encapsulation Extended Community
The Encapsulation Extended Community is a Transitive Opaque Extended The Encapsulation Extended Community is a Transitive Opaque Extended
Community. This Extended Community may be attached to a route of any Community.
AFI/SAFI to which the Tunnel Encapsulation attribute may be attached.
Each such Extended Community identifies a particular tunnel type. If
the Encapsulation Extended Community identifies a particular tunnel
type, its semantics are exactly equivalent to the semantics of a
Tunnel Encapsulation attribute Tunnel TLV for which the following
three conditions all hold:
1. it identifies the same tunnel type, The Encapsulation Extended Community encoding is as shown below
2. it has a Tunnel Endpoint sub-TLV for which one of the following 0 1 2 3
two conditions holds: 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 | 0x0c | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Tunnel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Encapsulation Extended Community
The value of the high-order octet of the extended type field is 0x03,
which indicates it's transitive. The value of the low-order octet of
the extended type field is 0x0c.
The last two octets of the value field encode a tunnel type.
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, its semantics
are the same as semantics of a Tunnel Encapsulation attribute Tunnel
TLV for which the following three conditions all hold:
1. it identifies the same Tunnel Type,
2. it has a Tunnel Egress Endpoint sub-TLV for which one of the
following two conditions holds:
A. its "Address Family" subfield contains zero, or A. its "Address Family" subfield contains zero, or
B. its "Address" subfield contains the same IP address that B. its "Address" subfield contains the address of the next hop
appears in the next hop field of the route to which the field of the route to which the Tunnel Encapsulation
Tunnel Encapsulation attribute is attached attribute is attached
3. it has no other sub-TLVs. 3. it has no other sub-TLVs.
We will refer to such a Tunnel TLV as a "barebones" Tunnel TLV. Such a Tunnel TLV is called a "barebones" Tunnel TLV.
The Encapsulation Extended Community was first defined in [RFC5512]. The Encapsulation Extended Community was first defined in [RFC5512].
While it provides only a small subset of the functionality of the While it provides only a small subset of the functionality of the
Tunnel Encapsulation attribute, it is used in a number of deployed Tunnel Encapsulation attribute, it is used in a number of deployed
applications, and is still needed for backwards compatibility. To applications, and is still needed for backwards compatibility. In
ensure backwards compatibility, this specification establishes the situations where a tunnel could be encoded using a barebones TLV, it
following rules: MUST be encoded using the corresponding Encapsulation Extended
Community.
1. If the Tunnel Encapsulation attribute of a given route contains a
barebones Tunnel TLV identifying a particular tunnel type, an
Encapsulation Extended Community identifying the same tunnel type
SHOULD be attached to the route.
2. If the Encapsulation Extended Community identifying a particular
tunnel type is attached to a given route, the corresponding
barebones Tunnel TLV MAY be omitted from the Tunnel Encapsulation
attribute.
3. Suppose a particular route has both (a) an Encapsulation Extended
Community specifying a particular tunnel type, and (b) a Tunnel
Encapsulation attribute with a barebones Tunnel TLV specifying
that same tunnel type. Both (a) and (b) MUST be interpreted as
denoting the same tunnel.
In short, in situations where one could use either the Encapsulation
Extended Community or a barebones Tunnel TLV, one may use either or
both. However, to ensure backwards compatibility with applications
that do not support the Tunnel Encapsulation attribute, it is
preferable to use the Encapsulation Extended Community. If the
Extended Community (identifying a particular tunnel type) is present,
the corresponding Tunnel TLV is optional.
Note that for tunnel types of the form "X-in-Y", e.g., MPLS-in-GRE, 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 the Encapsulation Extended Community implies that only packets of the
specified payload type "X" are to be carried through the tunnel of specified payload type "X" are to be carried through the tunnel of
type "Y". type "Y". Packets with other payload types MUST NOT be carried
through such tunnels. See also Section 2.
In the remainder of this specification, when we speak of a route as In the remainder of this specification, when a route is referred to
containing a Tunnel Encapsulation attribute with a TLV identifying a as containing a Tunnel Encapsulation attribute with a TLV identifying
particular tunnel type, we are implicitly including the case where a particular Tunnel Type, it implicitly includes the case where the
the route contains a Tunnel Encapsulation Extended Community route contains a Tunnel Encapsulation Extended Community identifying
identifying that tunnel type. that Tunnel Type.
4.2. Router's MAC Extended Community 4.2. Router's MAC Extended Community
[I-D.ietf-bess-evpn-inter-subnet-forwarding] defines a Router's MAC [I-D.ietf-bess-evpn-inter-subnet-forwarding] defines a Router's MAC
Extended Community. This Extended Community provides information Extended Community. This Extended Community provides information
that may conflict with information in one or more of the that may conflict with information in one or more of the
Encapsulation Sub-TLVs of a Tunnel Encapsulation attribute. In case Encapsulation Sub-TLVs of a Tunnel Encapsulation attribute. In case
of such a conflict, the information in the Encapsulation Sub-TLV of such a conflict, the information in the Encapsulation Sub-TLV
takes precedence. takes precedence.
skipping to change at page 23, line 33 skipping to change at page 25, line 35
Community with the following encoding: Community with the following encoding:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x03 | 0x0b | Reserved | | 0x03 | 0x0b | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color Value | | Color Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Color Extended Community Figure 12: Color Extended Community
For the use of this Extended Community please see Section 7. The value of the high-order octet of the extended type field is 0x03,
which indicates it is transitive. The value of the low-order octet
of the extended type field for this community is 0x0b. The color
value is user defined and configured locally. The two octet Reserved
field MUST be set to zero by the sender and ignored by the receiver.
The Color Value field is encoded as 4 octet value by the
administrator and is outside the scope of this document. For the use
of this Extended Community please see Section 7.
5. Semantics and Usage of the Tunnel Encapsulation attribute 5. Special Considerations for IP-in-IP Tunnels
In certain situations with an IP fabric underlay, one could have a
tunnel overlay with the tunnel type IP-in-IP. The egress BGP speaker
can advertise the IP-in-IP tunnel endpoint address in the Tunnel
Egress Endpoint sub-TLV. When the Tunnel type of the TLV is IP-in-
IP, it will not have a Virtual Network Identifier. However, the
tunnel egress endpoint address can be used in identifying the
forwarding table to use for making the forwarding decisions to
forward the payload. See the second bullet point of Section 9.1 for
further discussion.
6. 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 messages 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 (Ethernet VPN, usually known as EVPN)). Use of the Tunnel or 25/70 (Ethernet VPN, usually known as EVPN)). Use of the Tunnel
Encapsulation attribute in BGP UPDATE messages of other AFI/SAFIs is Encapsulation attribute in BGP UPDATE messages of other AFI/SAFIs is
outside the scope of this document. outside the scope of this document.
It has been suggested that it may sometimes be useful to attach a There is no significance to the order in which the TLVs occur within
Tunnel Encapsulation attribute to a BGP UPDATE message that is also the Tunnel Encapsulation attribute. Multiple TLVs may occur for a
carrying a PMSI (Provider Multicast Service Interface) Tunnel given Tunnel Type; each such TLV is regarded as describing a
attribute [RFC6514]. If the PMSI Tunnel attribute specifies an IP different tunnel.
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
one of the AFI/SAFIs specified in the previous paragraph, each TLV
MUST have a Tunnel Endpoint sub-TLV. If a TLV that does not have a
Tunnel Endpoint sub-TLV, that TLV should be treated as if it had a
malformed Tunnel 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
tunnel is considered feasible if it has the following three tunnel is considered feasible if it has the following three
properties: properties:
* The tunnel type is supported (i.e., router R knows how to set * The Tunnel Type is supported (i.e., router R knows how to set
up tunnels of that type, how to create the encapsulation header up tunnels of that type, how to create the encapsulation header
for tunnels of that type, etc.) for tunnels of that type, etc.)
* The tunnel is of a type that can be used to carry packet P * The tunnel is of a type that can be used to carry packet P
(e.g., an MPLS-in-UDP tunnel would not be a feasible tunnel for (e.g., an MPLS-in-UDP tunnel would not be a feasible tunnel for
carrying an IP packet, UNLESS the IP packet can first be carrying an IP packet, UNLESS the IP packet can first be
converted to an MPLS packet). encapsulated in a MPLS packet).
* The tunnel is specified in a TLV whose Tunnel Endpoint sub-TLV * The tunnel is specified in a TLV whose Tunnel Egress Endpoint
identifies an IP address that is reachable. sub-TLV identifies an IP address that is reachable. This IP
address may be reachable via one or more forwarding tables.
Local policy may determine these forwarding tables and is
outside the scope of this document. The reachability condition
is evaluated as per [RFC4271].
Then router R MUST send packet P through one of the feasible tunnels Then router R MUST send packet P through one of the feasible tunnels
identified in the Tunnel Encapsulation attribute of UPDATE U. 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 feasibile tunnels), router R may choose any one
tunnels, based upon local policy. If any tunnel TLV contains one or of those tunnels, based upon local policy. If any Tunnel TLV
more Color sub-TLVs (Section 3.4.2) and/or the Protocol Type sub-TLV contains one or more Color sub-TLVs (Section 3.4.2) and/or the
(Section 3.4.1), the choice of tunnel may be influenced by these sub- Protocol Type sub-TLV (Section 3.4.1), the choice of tunnel may be
TLVs. influenced by these sub-TLVs.
If a particular tunnel is not feasible at some moment because its The reachability to the address of the egress endpoint of the tunnel
Tunnel Endpoint cannot be reached at that moment, the tunnel may may change over time, directly impacting the feasibility of the
become feasible at a later time (when its endpoint becomes tunnel. A tunnel that is not feasible at some moment, may become
reachable). Router R should take note of this. If router R is feasible at a later time when its egress endpoint address is
already using a different tunnel, it MAY switch to the tunnel that reachable. The router MAY start using the newly feasible tunnel
just became feasible, or it MAY decide to continue using the tunnel instead of an existing one. How this decision is made is outside the
that it is already using. How this decision is made is outside the
scope of this document. scope of this document.
In addition to the sub-TLVs already defined, additional sub-TLVs may
be defined that affect the choice of tunnel to be used, or that
affect the contents of the tunnel encapsulation header. The
documents that define any such additional sub-TLVs must specify the
effect that including the sub-TLV is to have.
Once it is determined to send a packet through the tunnel specified Once it is determined to send a packet through the tunnel specified
in a particular TLV of a particular Tunnel Encapsulation attribute, in a particular Tunnel TLV of a particular Tunnel Encapsulation
then the tunnel's egress endpoint address is the IP address contained attribute, then the tunnel's egress endpoint address is the IP
in the sub-TLV. If the TLV contains a Tunnel Endpoint sub-TLV whose address contained in the sub-TLV. If the Tunnel TLV contains a
value field is all zeroes, then the tunnel's egress endpoint is the Tunnel Egress Endpoint sub-TLV whose value field is all zeroes, then
IP address specified as the Next Hop of the BGP Update containing the the tunnel's egress endpoint is the address of the Next Hop of the
Tunnel Encapsulation attribute. The address of the tunnel egress BGP Update containing the Tunnel Encapsulation attribute. The
endpoint generally appears in a "destination address" field of the address of the tunnel egress endpoint generally appears in a
encapsulation. "destination address" field of the encapsulation.
The full set of procedures for sending a packet through a particular The full set of procedures for sending a packet through a particular
tunnel type to a particular tunnel egress endpoint depends upon the Tunnel Type to a particular tunnel egress endpoint depends upon the
tunnel type, and is outside the scope of this document. Note that tunnel type, and is outside the scope of this document. Note that
some tunnel types may require the execution of an explicit tunnel some tunnel types may require the execution of an explicit tunnel
setup protocol before they can be used for carrying data. Other setup protocol before they can be used for carrying data. Other
tunnel types may not require any tunnel setup protocol. tunnel types may not require any tunnel setup protocol.
Sending a packet through a tunnel always requires that the packet be Sending a packet through a tunnel always requires that the packet be
encapsulated, with an encapsulation header that is appropriate for encapsulated, with an encapsulation header that is appropriate for
the tunnel type. The contents of the tunnel encapsulation header MAY the Tunnel Type. The contents of the tunnel encapsulation header MAY
be influenced by the Encapsulation sub-TLV. If there is no be influenced by the Encapsulation sub-TLV. If there is no
Encapsulation sub-TLV present, the router transmitting the packet Encapsulation sub-TLV present, the router transmitting the packet
through the tunnel must have a priori knowledge (e.g., by through the tunnel must have a priori knowledge (e.g., by
provisioning) of how to fill in the various fields in the provisioning) of how to fill in the various fields in the
encapsulation header. encapsulation header.
Whenever a new Tunnel Type TLV is defined, the specification of that Whenever a new Tunnel Type is defined, the specification of that TLV
TLV should describe (or reference) the procedures for creating the should 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. If a tunnel type codepoint is assigned in the IANA "BGP Tunnel type. The Tunnel Type codepoint will be assigned in the IANA "BGP
Encapsulation Tunnel Types" registry, but there is no corresponding Tunnel Encapsulation Tunnel Types" registry.
specification that defines an Encapsulation sub-TLV for that tunnel
type, the transmitting endpoint of such a tunnel is presumed to know
a priori how to form the encapsulation header for that tunnel type.
If a Tunnel Encapsulation attribute specifies several tunnels, the 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 In addition to the reachability to the address of the egress endpoint
given tunnel is not functional, it MUST NOT use that tunnel. In of the tunnel, other policy factors MAY be used to determine the
particular, if the tunnel is identified in a TLV that has a Tunnel feasibility of the tunnel. The policy factors are beyond the scope
Endpoint sub-TLV, and if the IP address specified in the sub-TLV is of this document.
not reachable from router R, then the tunnel MUST be considered non-
functional. Other means of determining whether a given tunnel is
functional MAY be used; specification of such means is outside the
scope of this specification. Of course, if a non-functional tunnel
later becomes functional, router R SHOULD reevaluate its choice of
tunnels.
If router R determines that it cannot use any of the tunnels
specified in the Tunnel Encapsulation attribute, it MAY either drop
packet P, or it MAY transmit packet P as it would had the Tunnel
Encapsulation attribute not been present. This is a matter of local
policy. By default, the packet SHOULD be transmitted as if the
Tunnel Encapsulation attribute had not been present.
A Tunnel Encapsulation attribute may contain several TLVs that all A Tunnel Encapsulation attribute may contain several TLVs that all
specify the same tunnel type. Each TLV should be considered as specify the same Tunnel Type. Each TLV should be considered as
specifying a different tunnel. Two tunnels of the same type may have specifying a different tunnel. Two tunnels of the same type may have
different Tunnel Endpoint sub-TLVs, different Encapsulation sub-TLVs, different Tunnel Egress Endpoint sub-TLVs, different Encapsulation
etc. Choosing between two such tunnels is a matter of local policy. sub-TLVs, etc. Choosing between two such tunnels is a matter of
local policy.
Once router R has decided to send packet P through a particular 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 egress endpoint. according to the route that leads to the tunnel's egress 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".
Notwithstanding anything said in this document, a BGP speaker MAY Notwithstanding anything said in this document, a BGP speaker MAY
have local policy that influences the choice of tunnel, and the way have local policy that influences the choice of tunnel, and the way
the encapsulation is formed. A BGP speaker MAY also have a local the encapsulation is formed. A BGP speaker MAY also have a local
policy that tells it to ignore the Tunnel Encapsulation attribute policy that tells it to ignore the Tunnel Encapsulation attribute
entirely or in part. Of course, interoperability issues must be entirely or in part. Of course, interoperability issues must be
considered when such policies are put into place. considered when such policies are put into place.
6. Routing Considerations 7. Routing Considerations
6.1. Impact on BGP Decision Process 7.1. Impact on the BGP Decision Process
The presence of the Tunnel Encapsulation attribute affects the BGP The presence of the Tunnel Encapsulation attribute affects the BGP
bestpath selection algorithm. For all the tunnels described in the best route selection algorithm. If a route includes the Tunnel
Tunnel Encapsulation attribute for a path, if no Tunnel Endpoint Encapsulation attribute, and if that attribute includes no tunnel
address is feasible, then that path MUST NOT be considered resolvable which is feasible, then that route MUST NOT be considered resolvable
for the purposes of Route Resolvability Condition [RFC4271] section for the purposes of Route Resolvability Condition [RFC4271] section
9.1.2.1. 9.1.2.1.
6.2. Looping, Infinite Stacking, Etc. 7.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 tunnel egress endpoint of Y. And suppose that a BGP specifies a tunnel egress 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 Tunnel Endpoint of X. It is easy to see that this that specifies a tunnel egress endpoint of X. It is easy to see that
will cause an infinite number of encapsulation headers to be put on this will cause an infinite number of encapsulation headers to be put
the given packet. on the given packet. [RFC4271] describes an analogous case as
mutually recursive routes.
This could happen as a result of misconfiguration, either accidental This could happen as a result of misconfiguration, either accidental
or intentional. It could also happen if the Tunnel Encapsulation or intentional. It could also happen if the Tunnel Encapsulation
attribute were altered by a malicious agent. Implementations should attribute were altered by a malicious agent. Implementations should
be aware of this. This document does not specify a maximum number of be aware that such an attack will result in unresolvable BGP routes
recursions; that is an implementation-specific matter. due to the mutually recursive relationship. This document does not
specify a maximum number of recursions; that is an implementation-
specific matter.
Improper setting (or malicious altering) of the Tunnel Encapsulation Improper setting (or malicious altering) of the Tunnel Encapsulation
attribute could also cause data packets to loop. Suppose a BGP attribute could also cause data packets to loop. Suppose a BGP
UPDATE for address prefix X carries a Tunnel Encapsulation attribute UPDATE for address prefix X carries a Tunnel Encapsulation attribute
that specifies a tunnel egress endpoint of Y. Suppose router R that specifies a tunnel egress endpoint of Y. Suppose router R
receives and processes the update. When router R receives a packet receives and processes the advertisement. When router R receives a
destined for X, it will apply the encapsulation and send the packet 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. The control plane itself cannot detect a long-lasting routing loop. The control plane itself cannot detect
this situation, though a TTL field in the payload packets would this situation, though a TTL field in the payload packets would
presumably prevent any given packet from looping infinitely. prevent any given packet from looping infinitely.
These possibilities must also be kept in mind whenever the Tunnel During the deployment of techniques as described in this document,
Endpoint for a given prefix differs from the BGP next hop for that operators are encouraged to avoid mutually recursive route and/or
prefix. tunnel dependencies. There is greater potential for such scenarios
to arise when the tunnel egress endpoint for a given prefix differs
from the address of the next hop for that prefix.
7. Recursive Next Hop Resolution 8. 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 address of 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 MUST be sent through one of the tunnels identified in Then packet P MUST be sent through one of the tunnels identified in
the Tunnel Encapsulation attribute of UPDATE U2. See Section 5 for the Tunnel Encapsulation attribute of UPDATE U2. See Section 6 for
further details. further details.
However, suppose that one of the TLVs in U2's Tunnel Encapsulation However, suppose that one of the TLVs in U2's Tunnel Encapsulation
attribute contains the Color Sub-TLV. In that case, packet P MUST attribute contains the Color Sub-TLV. In that case, packet P MUST
NOT be sent through the tunnel identified in that TLV, unless U1 is NOT be sent through the tunnel contained in that TLV, unless U1 is
carrying the Color Extended Community that is identified in U2's carrying the Color Extended Community that is identified in U2's
Color Sub-TLV. Color Sub-TLV.
Note that if UPDATE U1 and UPDATE U2 both have Tunnel Encapsulation The procedures in this section presuppose that U1's address of the
attributes, packet P will be carried through a pair of nested next hop resolves to a BGP route, and that U2's next hop resolves
tunnels. P will first be encapsulated based on the Tunnel (perhaps after further recursion) to a non-BGP route.
Encapsulation attribute of U1. This encapsulated packet then becomes
the payload, and is encapsulated based on the Tunnel Encapsulation
attribute of U2. This is another way of "stacking" tunnels (see also
Section 5).
The procedures in this section presuppose that U1's next hop resolves
to a BGP route, and that U2's next hop resolves (perhaps after
further recursion) to a non-BGP route.
8. Use of Virtual Network Identifiers and Embedded Labels when Imposing 9. 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, If the TLV specifying a tunnel contains an MPLS Label Stack sub-TLV,
then when sending a packet through that tunnel, the procedures of then when sending a packet through that tunnel, the procedures of
Section 3.6 are applied before the procedures of this section. Section 3.6 are applied before the procedures of this section.
If the TLV specifying a tunnel contains a Prefix-SID sub-TLV, the 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 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 section. If the TLV also contains an MPLS Label Stack sub-TLV, the
procedures of Section 3.6 are applied before the procedures of procedures of Section 3.6 are applied before the procedures of
Section 3.7. Section 3.7.
8.1. Tunnel Types without a Virtual Network Identifier Field 9.1. Tunnel Types without a Virtual Network Identifier Field
If a Tunnel Encapsulation attribute is attached to an UPDATE of a If a Tunnel Encapsulation attribute is attached to an UPDATE of a
labeled address family, there will be one or more labels specified in labeled address family, there will be one or more labels specified in
the UPDATE's NLRI. the UPDATE's NLRI.
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, the label or labels from the NLRI are pushed on the packet's is 1, the label or labels from the NLRI are pushed on the packet's
label stack. label stack.
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 ignored completely. The tunnel is 2, the embedded label is ignored completely. In this case the
assumed to have terminated at the corresponding VRF. tunnel encapsulation is presumed to provide complete information
regarding the forwarding context required.
The resulting MPLS packet is then further encapsulated, as specified The resulting MPLS packet is then further encapsulated, as specified
by the TLV. by the TLV.
8.2. Tunnel Types with a Virtual Network Identifier Field 9.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 (Virtual Network Identifier) field; in this field is called the VNI (Virtual Network Identifier) field; in
the NVGRE encapsulation, this field is called the VSID (Virtual the NVGRE encapsulation, this field is called the VSID (Virtual
Subnet Identifier) field. Subnet Identifier) 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 in 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.
8.2.1. Unlabeled Address Families 9.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 in 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
tunnels. tunnels.
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.
8.2.2. Labeled Address Families 9.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 in 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.
8.2.2.1. When a Valid VNI has been Signaled 9.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 to the value of the virtual network
identifier field of the Encapsulation sub-TLV. However, the Embedded
Label Handling sub-TLV will determine label processing as described
below.
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, the embedded label (from the NLRI of the route that is
encapsulation header is set to the value of the virtual network carrying the Tunnel Encapsulation attribute) appears at the top of
identifier field of the Encapsulation sub-TLV. the MPLS label stack in the encapsulation payload.
The embedded label (from the NLRI of the route that is carrying
the Tunnel Encapsulation attribute) appears at the top of the MPLS
label stack in the encapsulation payload.
o If the TLV does not contain an Embedded Label Handling sub-TLV, or 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, it 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.
identifier field of the encapsulation header is set to the value
of the virtual network identifier field of the Encapsulation sub-
TLV.
8.2.2.2. When a Valid VNI has not been Signaled 9.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.
The embedded label (from the NLRI of the route that is carrying The embedded label (from the NLRI of the route that is carrying
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 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 lower 3 octets of the
identifier field of the encapsulation header. virtual network identifier field of the encapsulation header.
In this case, the payload may or may not contain an MPLS label In this case, the payload may or may not contain an MPLS label
stack, depending upon other factors. If the payload does contain stack, depending upon other factors. If the payload does contain
an MPLS label stack, the embedded label does not appear in that an MPLS label stack, the embedded label does not appear in that
stack. stack.
9. Applicability Restrictions 10. 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 represented by the address of the next hop. Certain of the
Section 8.2.2.1 or Section 8.2.2.2 cause the embedded label to be procedures of Section 9.2.2.1 or Section 9.2.2.2 cause the embedded
carried by a data packet to the router whose address appears in the label to be carried by a data packet to the router whose address
Tunnel Endpoint sub-TLV. If the Tunnel Endpoint sub-TLV does not appears in the Tunnel Egress Endpoint sub-TLV. If the Tunnel Egress
identify the same router that is the next hop, sending the packet Endpoint sub-TLV does not identify the same router represented by the
through the tunnel may cause the label to be misinterpreted at the address of the next hop, sending the packet through the tunnel may
tunnel's egress endpoint. This may cause misdelivery of the packet. cause the label to be misinterpreted at the tunnel's egress endpoint.
This may cause misdelivery of the packet. Avoidance of this
Therefore the embedded label MUST NOT be carried by a data packet unfortunate outcome is a matter of network planning and design, and
traveling through a tunnel unless it is known that the label will be is outside the scope of this document.
properly interpreted at the tunnel's egress endpoint. How this is
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 Tunnel Endpoint sub-TLV contains [RFC4364]) is being used, and if the Tunnel Egress Endpoint sub-TLV
an IP address that is not in same AS as the router receiving the contains an IP address that is not in same AS as the router receiving
route, it is very likely that the embedded label has been changed. the route, it is very likely that the embedded label has been
Therefore use of the Tunnel Encapsulation attribute in an "Inter-AS changed. Therefore use of the Tunnel Encapsulation attribute in an
option b" scenario is not supported. "Inter-AS option b" scenario is not supported.
10. Scoping 11. 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
beyond its intended scope, any BGP speaker that understands the beyond its intended scope, any BGP speaker that understands the
attribute MUST be able to filter the attribute from incoming BGP attribute MUST be able to filter the attribute from incoming BGP
UPDATE messages. When the attribute is filtered from an incoming UPDATE messages. When the attribute is filtered from an incoming
UPDATE, the attribute is neither processed nor redistributed. This UPDATE, the attribute is neither processed nor distributed. This
filtering SHOULD be possible on a per-BGP-session basis. For each filtering SHOULD be possible on a per-BGP-session basis; finer
session, filtering of the attribute on incoming UPDATEs MUST be granularities (for example, per route and/or per attribute TLV) MAY
enabled by default. be supported. For each external BGP (EBGP) session, filtering of the
attribute on incoming UPDATEs MUST be 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 EBGP session, filtering of the attribute on outgoing UPDATEs MUST be
enabled by default. enabled by default.
11. Error Handling 12. Validation and 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 to be malformed. A TLV that is case, the TLV MUST be considered to be malformed. A TLV that is
found to be malformed for this reason MUST NOT be processed, and MUST found to be malformed for this reason MUST NOT be processed, and MUST
be stripped from the Tunnel Encapsulation attribute before the be stripped from the Tunnel Encapsulation attribute. In this case,
attribute is propagated. Subsequent TLVs in the Tunnel Encapsulation the "Treat-as-withdraw" procedure of [RFC7606] is applied.
attribute may still be valid, in which case they MUST be processed
and redistributed normally.
If a Tunnel Encapsulation attribute does not have any valid TLVs, or 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 "Treat-as-withdraw"
procedure of [RFC7606] 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 whose tunnel type is not recognized by a particular contains a TLV whose Tunnel Type is not recognized by a particular
BGP speaker, that BGP speaker MUST NOT consider the attribute to be BGP speaker, that BGP speaker MUST NOT consider the attribute to be
malformed. Rather, the TLV with the unrecognized tunnel type MUST be malformed. Rather, it MUST interpret the attribute as if that TLV
ignored, and the BGP speaker MUST interpret the attribute as if that had not been present. If the route carrying the Tunnel Encapsulation
TLV had not been present. If the route carrying the Tunnel attribute is propagated with the attribute, the unrecognized TLV MUST
Encapsulation attribute is propagated with the attribute, the remain in the attribute.
unrecognized TLV MUST remain in the attribute.
If a TLV of a Tunnel Encapsulation attribute contains a sub-TLV that
is not recognized by a particular BGP speaker, the BGP speaker MUST
process that TLV as if the unrecognized sub-TLV had not been present.
If the route carrying the Tunnel Encapsulation attribute is
propagated with the attribute, the unrecognized TLV MUST remain in
the attribute.
If the type code of a sub-TLV appears as "reserved" in the IANA "BGP
Tunnel Encapsulation Attribute Sub-TLVs" registry, the sub-TLV MUST
be treated as an unrecognized sub-TLV.
In general, if a TLV contains a sub-TLV that is malformed (e.g.,
contains a length field whose value is not legal for that sub-TLV),
the sub-TLV should be treated as if it were an unrecognized sub-TLV.
This document specifies one exception to this rule -- within a tunnel
encapsulation attribute that is carried by a BGP UPDATE whose AFI/
SAFI is one of those explicitly listed in the second paragraph of
Section 5, if a TLV contains a malformed Tunnel Endpoint sub-TLV (as
defined in Section 3.1), the entire TLV MUST be ignored, and MUST be
removed from the Tunnel Encapsulation attribute before the route
carrying that attribute is redistributed.
Within a tunnel encapsulation attribute that is carried by a BGP
UPDATE whose AFI/SAFI is one of those explicitly listed in the second
paragraph of Section 5, a TLV that does not contain exactly one
Tunnel Endpoint sub-TLV MUST be treated as if it contained a
malformed Tunnel Endpoint sub-TLV.
A TLV identifying a particular tunnel type may contain a sub-TLV that
is meaningless for that tunnel type. For example, perhaps the TLV
contains a "UDP Destination Port" sub-TLV, but the identified tunnel
type does not use UDP encapsulation at all. Sub-TLVs of this sort
MUST be treated as a no-op. That is, they MUST NOT affect the
creation of the encapsulation header. However, the sub-TLV MUST NOT
be considered to be malformed, and MUST NOT be removed from the TLV
before the route carrying the Tunnel Encapsulation attribute is
redistributed. (This allows for the possibility that such sub-TLVs
may be given a meaning, in the context of the specified tunnel type,
in the future.)
There is no significance to the order in which the TLVs occur within
the Tunnel Encapsulation attribute. Multiple TLVs may occur for a
given tunnel type; each such TLV is regarded as describing a
different tunnel.
The following sub-TLVs defined in this document MUST NOT occur more The following sub-TLVs defined in this document MUST NOT occur more
than once in a given Tunnel TLV: Tunnel Endpoint (discussed above), than once in a given Tunnel TLV: Tunnel Egress Endpoint (discussed
Encapsulation, IPv4 DS, UDP Destination Port, Embedded Label below), Encapsulation, DS, UDP Destination Port, Embedded Label
Handling, MPLS Label Stack, Prefix-SID. If a Tunnel TLV has more Handling, MPLS Label Stack, Prefix-SID. If a Tunnel TLV has more
than one of any of these sub-TLVs, all but the first occurrence of than one of any of these sub-TLVs, all but the first occurrence of
each such sub-TLV type MUST be treated as a no-op. However, the each such sub-TLV type MUST be disregarded. However, the Tunnel TLV
Tunnel TLV containing them MUST NOT be considered to be malformed, containing them MUST NOT be considered to be malformed, and all the
and all the sub-TLVs MUST be propagated if the route carrying the sub-TLVs MUST be propagated if the route carrying the Tunnel
Tunnel Encapsulation attribute is propagated. Encapsulation attribute is propagated.
The following sub-TLVs defined in this document may appear zero or The following sub-TLVs defined in this document may appear zero or
more times in a given Tunnel TLV: Protocol Type, Color. Each more times in a given Tunnel TLV: Protocol Type, Color. Each
occurrence of such sub-TLVs is meaningful. For example, the Color occurrence of such sub-TLVs is meaningful. For example, the Color
sub-TLV may appear multiple times to assign multiple colors to a sub-TLV may appear multiple times to assign multiple colors to a
tunnel. tunnel.
12. IANA Considerations If a TLV of a Tunnel Encapsulation attribute contains a sub-TLV that
is not recognized by a particular BGP speaker, the BGP speaker MUST
process that TLV as if the unrecognized sub-TLV had not been present.
If the route carrying the Tunnel Encapsulation attribute is
propagated with the attribute, the unrecognized sub-TLV MUST remain
in the attribute.
12.1. Subsequent Address Family Identifiers In general, if a TLV contains a sub-TLV that is malformed (e.g.,
contains a length field whose value is not legal for that sub-TLV),
the sub-TLV should be treated as if it were an unrecognized sub-TLV.
This document specifies one exception to this rule -- if a TLV
contains a malformed Tunnel Egress Endpoint sub-TLV (as defined in
Section 3.1), the entire TLV MUST be ignored, and MUST be removed
from the Tunnel Encapsulation attribute before the route carrying
that attribute is distributed.
IANA is requested to modify the "Subsequent Address Family Within a Tunnel Encapsulation attribute that is carried by a BGP
Identifiers" registry to indicate that the Encapsulation SAFI is UPDATE whose AFI/SAFI is one of those explicitly listed in the second
deprecated. This document should be the reference. paragraph of Section 6, a TLV that does not contain exactly one
Tunnel Egress Endpoint sub-TLV MUST be treated as if it contained a
malformed Tunnel Egress Endpoint sub-TLV.
12.2. BGP Path Attributes A TLV identifying a particular Tunnel Type may contain a sub-TLV that
is meaningless for that Tunnel Type. For example, perhaps the TLV
contains a UDP Destination Port sub-TLV, but the identified tunnel
type does not use UDP encapsulation at all, or a tunnel of the form
"X-in-Y" contains a Protocol Type sub-TLV that specifies something
other than "X". Sub-TLVs of this sort MUST be disregarded. That is,
they MUST NOT affect the creation of the encapsulation header.
However, the sub-TLV MUST NOT be considered to be malformed, and MUST
NOT be removed from the TLV before the route carrying the Tunnel
Encapsulation attribute is distributed. An implementation MAY log a
message when it encounters such a sub-TLV.
IANA has previously assigned value 23 from the "BGP Path Attributes" 13. IANA Considerations
Registry to "Tunnel Encapsulation Attribute". IANA is requested to 13.1. Subsequent Address Family Identifiers
add this document as a reference.
12.3. Extended Communities IANA is requested to modify the "Subsequent Address Family
Identifiers" registry to indicate that the Encapsulation SAFI (value
7) is obsoleted. This document should be the reference.
IANA has previously assigned values from the "Transitive Opaque Because this document obsoletes RFC 5512, IANA is asked to change all
Extended Community" type Registry to the "Color Extended Community" registration information that references [RFC5512] to instead
(sub-type 0x0b), and to the "Encapsulation Extended reference this document.
Community"(0x030c). IANA is requested to add this document as a
reference for both assignments.
12.4. BGP Tunnel Encapsulation Attribute Sub-TLVs 13.2. BGP Tunnel Encapsulation Attribute Sub-TLVs
IANA is requested to add the following note to the "BGP Tunnel IANA is requested to add the following note to the "BGP Tunnel
Encapsulation Attribute Sub-TLVs" registry: Encapsulation Attribute Sub-TLVs" registry:
If the Sub-TLV Type is in the range from 0 to 127 inclusive, the If the Sub-TLV Type is in the range from 0 to 127 inclusive, the
Sub-TLV Length field contains one octet. If the Sub-TLV Type is Sub-TLV Length field contains one octet. If the Sub-TLV Type is
in the range from 128-255 inclusive, the Sub-TLV Length field in the range from 128-255 inclusive, the Sub-TLV Length field
contains two octets. contains two octets.
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-63 and 128-191 are to be allocated using o The values in the range 1-63 and 128-191 are to be allocated using
the "Standards Action" registration procedure. the "Standards Action" registration procedure.
o The values in the range 64-125 and 192-252 are to be allocated o The values in the range 64-125 and 192-252 are to be allocated
using the "First Come, First Served" registration procedure. using the "First Come First Served" registration procedure.
o The values in the range 126-127 and 253-254 are reserved for o The values in the range 126-127 and 253-254 are reserved for
experimental use; IANA shall not allocate values from this range. experimental use; IANA shall not allocate values from this range.
IANA has assigned the following codepoints in the "BGP Tunnel IANA has assigned the following codepoints in the "BGP Tunnel
Encapsulation Attribute Sub-TLVs registry: Encapsulation Attribute Sub-TLVs registry":
6: Remote Endpoint
IANA is requested to change the name of "Remote Endpoint" to
"Tunnel Egress Endpoint".
7: IPv4 DS Field
8: UDP Destination Port
9: Embedded Label Handling
10: MPLS Label Stack
11: Prefix SID
IANA has previously 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 Value 6: Remote Endpoint (note: IANA please rename to "Tunnel
types 8 (VXLAN), 9 (NVGRE), 11 (MPLS-in-GRE), and 12 (VXLAN-GPE) in Egress Endpoint")
the "BGP Tunnel Encapsulation Tunnel Types" registry.
IANA is requested to add this document as a reference for tunnel Value 7: IPv4 DS Field (note: IANA please rename to "DS Field")
types 1 (L2TPv3), 2 (GRE), and 7 (IP in IP) in the "BGP Tunnel
Encapsulation Tunnel Types" registry.
12.6. Flags Field of Vxlan Encapsulation sub-TLV 13.3. Flags Field of VXLAN Encapsulation sub-TLV
IANA is requested to add this document as a reference for creating IANA is requested to add this document as a reference for creating
the flags field of the Vxlan Encapsulation sub-TLV registry. the flags field of the VXLAN Encapsulation sub-TLV registry.
IANA is requested to add this document as a reference for flag bits V IANA is requested to add this document as a reference for flag bits V
and M in the "Flags field of Vxlan Encapsulation sub-TLV" registry. and M in the "Flags field of VXLAN Encapsulation sub-TLV" registry.
12.7. Flags Field of Vxlan-GPE Encapsulation sub-TLV 13.4. Flags Field of VXLAN GPE Encapsulation sub-TLV
IANA is requested to add this document as a reference for creating IANA is requested to add this document as a reference for creating
the flags field of the Vxlan-GPE Encapsulation sub-TLV registry. the flags field of the VXLAN GPE Encapsulation sub-TLV registry.
IANA is requested to add this document as a reference for flag bit V IANA is requested to add this document as a reference for flag bit V
in the "Flags field of Vxlan-GPE Encapsulation sub-TLV" registry. in the "Flags field of VXLAN GPE Encapsulation sub-TLV" registry.
12.8. Flags Field of NVGRE Encapsulation sub-TLV 13.5. Flags Field of NVGRE Encapsulation sub-TLV
IANA is requested to add this document as a reference for creating IANA is requested to add this document as a reference for creating
the flags field of the NVGRE Encapsulation sub-TLV registry. the flags field of the NVGRE Encapsulation sub-TLV registry.
IANA is requested to add this document as a reference for flag bits V IANA is requested to add this document as a reference for flag bits V
and M in the "Flags field of NVGRE Encapsulation sub-TLV" registry. and M in the "Flags field of NVGRE Encapsulation sub-TLV" registry.
12.9. Embedded Label Handling sub-TLV 13.6. Embedded Label Handling sub-TLV
IANA is requested to add this document as a reference for creating IANA is requested to add this document as a reference for creating
the sub-TLV's value field of the Embedded Label Handling sub-TLV the sub-TLV's value field of the Embedded Label Handling sub-TLV
registry. registry.
IANA is requested to add this document as a reference for value of 1 IANA is requested to add this document as a reference for value of 1
(Payload of MPLS with embedded label) and 2 (no embedded label in (Payload of MPLS with embedded label) and 2 (no embedded label in
payload) in the "sub-TLV's value field of the Embedded Label Handling payload) in the "sub-TLV's value field of the Embedded Label Handling
sub-TLV" registry. sub-TLV" registry.
13. Security Considerations 13.7. Extended Color Community
The Tunnel Encapsulation attribute can cause traffic to be diverted
from its normal path, especially when the Tunnel Endpoint sub-TLV is
used. This can have serious consequences if the attribute is added
or modified illegitimately, as it enables traffic to be "hijacked".
The Tunnel Endpoint sub-TLV contains both an IP address and an AS IANA is requested to add this document as a reference for the "Color
number. BGP Origin Validation [RFC6811] can be used to obtain Extended Community" entry in the Transitive Opaque Extended Community
assurance that the given IP address belongs to the given AS. While Sub-Types registry.
this provides some protection against misconfiguration, it does not
prevent a malicious agent from inserting a sub-TLV that will appear
valid.
Before sending a packet through the tunnel identified in a particular 14. Security Considerations
TLV of a Tunnel Encapsulation attribute, it may be advisable to use
BGP Origin Validation to obtain the following additional assurances:
o the origin AS of the route carrying the Tunnel Encapsulation As Section 11 discusses, it is intended that the Tunnel Encapsulation
attribute is correct; attribute be used only within a well-defined scope, e.g., within a
set of Autonomous Systems that belong to a single administrative
entity. As long as the filtering mechanisms discussed in that
section are applied diligently, an attacker outside the scope would
not be able to use the Tunnel Encapsulation attribute in an attack.
This leaves open the questions of attackers within the scope (for
example, a compromised router) and failures in filtering that allow
an external attack to succeed.
o the origin AS of the route to the IP address specified in the As [RFC4272] discusses, BGP is vulnerable to traffic diversion
Tunnel Endpoint sub-TLV is correct, and is the same AS that is attacks. The Tunnel Encapsulation attribute adds a new means by
specified in the Tunnel Endpoint sub-TLV. which an attacker could cause traffic to be diverted from its normal
path, especially when the Tunnel Egress Endpoint sub-TLV is used.
Such an attack would differ from pre-existing vulnerabilities in that
traffic could be tunneled to a distant target across intervening
network infrastructure, allowing an attack to potentially succeed
more easily, since less infrastructure would have to be subverted.
Potential consequences include "hijacking" of traffic (insertion of
an undesired node in the path) or denial of service (directing
traffic to a node that doesn't desire to receive it).
In order to further mitigate the risk of diversion of traffic from
its intended destination, Section 3.1.1 provides an optional
procedure to check that the destination given in a Tunnel Egress
Endpoint sub-TLV is within the AS that was the source of the route.
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. As RFC 4272
not suit all use cases, and in any event is not very strong discusses, it's possible for an attacker to announce an inaccurate
protection against hijacking. AS_PATH, therefore an attacker with the ability to inject a Tunnel
Egress Endpoint sub-TLV could equally craft an AS_PATH that would
For these reasons, BGP Origin Validation should not be relied upon pass the validation procedures of Section 3.1.1. BGP Origin
exclusively, and the filtering procedures of Section 10 should always Validation [RFC6811] and BGPsec [RFC8205] provide means to increase
be in place. assurance that the origins being validated have not been falsified.
Increased protection can be obtained by using BGPSEC [RFC8205] to
ensure that the route carrying the Tunnel Encapsulation attribute,
and the routes to the Tunnel Endpoint of each specified tunnel, have
not been altered illegitimately.
If BGP Origin Validation is used as specified above, and the tunnel
specified in a particular TLV of a Tunnel Encapsulation attribute is
therefore regarded as "suspicious", that tunnel should not be used.
Other tunnels specified in (other TLVs of) the Tunnel Encapsulation
attribute may still be used.
14. Acknowledgments 15. Acknowledgments
This document contains text from RFC5512, co-authored by Pradosh This document contains text from RFC 5512, authored by Pradosh
Mohapatra. The authors of the current document wish to thank Pradosh Mohapatra and Eric Rosen. The authors of the current document wish
for his contribution. RFC5512 itself built upon prior work by Gargi to thank them for their contribution. RFC 5512 itself built upon
Nalawade, Ruchi Kapoor, Dan Tappan, David Ward, Scott Wainner, Simon prior work by Gargi Nalawade, Ruchi Kapoor, Dan Tappan, David Ward,
Barber, Lili Wang, and Chris Metz, whom we also thank for their Scott Wainner, Simon Barber, Lili Wang, and Chris Metz, whom the
contributions. authors also thank for their contributions. Eric Rosen was the
principal author of earlier versions of this document.
The authors wish to thank Lou Berger, Ron Bonica, Martin Djernaes, The authors wish to thank Lou Berger, Ron Bonica, Martin Djernaes,
John Drake, Satoru Matsushima, Dhananjaya Rao, John Scudder, Ravi John Drake, Satoru Matsushima, Dhananjaya Rao, Ravi Singh, Thomas
Singh, Thomas Morin, Xiaohu Xu, and Zhaohui Zhang for their review, Morin, Xiaohu Xu, and Zhaohui Zhang for their review, comments, and/
comments, and/or helpful discussions. or helpful discussions. Alvaro Retana provided an especially
comprehensive review.
15. Contributor Addresses 16. 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
skipping to change at page 38, line 44 skipping to change at page 39, line 23
Robert Raszuk Robert Raszuk
Bloomberg LP Bloomberg LP
731 Lexington Ave 731 Lexington Ave
New York City, NY 10022 New York City, NY 10022
United States United States
Email: robert@raszuk.net Email: robert@raszuk.net
Eric C. Rosen Eric C. Rosen
16. References 17. References
16.1. Normative References
[I-D.ietf-idr-bgp-prefix-sid] 17.1. Normative References
Previdi, S., Filsfils, C., Lindem, A., Sreekantiah, A.,
and H. Gredler, "Segment Routing Prefix SID extensions for
BGP", draft-ietf-idr-bgp-prefix-sid-27 (work in progress),
June 2018.
[I-D.ietf-nvo3-vxlan-gpe] [I-D.ietf-nvo3-vxlan-gpe]
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-08 (work Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-09 (work
in progress), October 2019. in progress), December 2019.
[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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://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,
<https://www.rfc-editor.org/info/rfc2784>. <https://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,
<https://www.rfc-editor.org/info/rfc2890>. <https://www.rfc-editor.org/info/rfc2890>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>. <https://www.rfc-editor.org/info/rfc3032>.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, DOI 10.17487/RFC3270, May 2002,
<https://www.rfc-editor.org/info/rfc3270>.
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
"Layer Two Tunneling Protocol - Version 3 (L2TPv3)", "Layer Two Tunneling Protocol - Version 3 (L2TPv3)",
RFC 3931, DOI 10.17487/RFC3931, March 2005, RFC 3931, DOI 10.17487/RFC3931, March 2005,
<https://www.rfc-editor.org/info/rfc3931>. <https://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,
<https://www.rfc-editor.org/info/rfc4023>. <https://www.rfc-editor.org/info/rfc4023>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007, DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>. <https://www.rfc-editor.org/info/rfc4760>.
[RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
Subsequent Address Family Identifier (SAFI) and the BGP Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January
Tunnel Encapsulation Attribute", RFC 5512, 2008, <https://www.rfc-editor.org/info/rfc5129>.
DOI 10.17487/RFC5512, April 2009,
<https://www.rfc-editor.org/info/rfc5512>.
[RFC5566] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel [RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load-
Encapsulation Attribute", RFC 5566, DOI 10.17487/RFC5566, Balancing for Mesh Softwires", RFC 5640,
June 2009, <https://www.rfc-editor.org/info/rfc5566>. DOI 10.17487/RFC5640, August 2009,
<https://www.rfc-editor.org/info/rfc5640>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153,
RFC 6890, DOI 10.17487/RFC6890, April 2013,
<https://www.rfc-editor.org/info/rfc6890>.
[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,
<https://www.rfc-editor.org/info/rfc7348>. <https://www.rfc-editor.org/info/rfc7348>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015,
<https://www.rfc-editor.org/info/rfc7510>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages", Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015, RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>. <https://www.rfc-editor.org/info/rfc7606>.
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
Virtualization Using Generic Routing Encapsulation", Virtualization Using Generic Routing Encapsulation",
RFC 7637, DOI 10.17487/RFC7637, September 2015, RFC 7637, DOI 10.17487/RFC7637, September 2015,
<https://www.rfc-editor.org/info/rfc7637>. <https://www.rfc-editor.org/info/rfc7637>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
16.2. Informative References [RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah,
A., and H. Gredler, "Segment Routing Prefix Segment
Identifier Extensions for BGP", RFC 8669,
DOI 10.17487/RFC8669, December 2019,
<https://www.rfc-editor.org/info/rfc8669>.
17.2. Informative References
[Ethertypes] [Ethertypes]
"IANA Ethertype Registry", "IANA Ethertype Registry",
<http://www.iana.org/assignments/ieee-802-numbers/ieee- <http://www.iana.org/assignments/ieee-802-numbers/ieee-
802-numbers.xhtml>. 802-numbers.xhtml>.
[I-D.ietf-bess-evpn-inter-subnet-forwarding] [I-D.ietf-bess-evpn-inter-subnet-forwarding]
Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. Sajassi, A., Salam, S., Thoria, S., Drake, J., and J.
Rabadan, "Integrated Routing and Bridging in EVPN", draft- Rabadan, "Integrated Routing and Bridging in EVPN", draft-
ietf-bess-evpn-inter-subnet-forwarding-08 (work in ietf-bess-evpn-inter-subnet-forwarding-09 (work in
progress), March 2019. progress), June 2020.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
"Definition of the Differentiated Services Field (DS RFC 4272, DOI 10.17487/RFC4272, January 2006,
Field) in the IPv4 and IPv6 Headers", RFC 2474, <https://www.rfc-editor.org/info/rfc4272>.
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[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, <https://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, DOI 10.17487/RFC5462, February Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
2009, <https://www.rfc-editor.org/info/rfc5462>. 2009, <https://www.rfc-editor.org/info/rfc5462>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation
Encodings and Procedures for Multicast in MPLS/BGP IP Subsequent Address Family Identifier (SAFI) and the BGP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, Tunnel Encapsulation Attribute", RFC 5512,
<https://www.rfc-editor.org/info/rfc6514>. DOI 10.17487/RFC5512, April 2009,
<https://www.rfc-editor.org/info/rfc5512>.
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009,
<https://www.rfc-editor.org/info/rfc5565>.
[RFC5566] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel
Encapsulation Attribute", RFC 5566, DOI 10.17487/RFC5566,
June 2009, <https://www.rfc-editor.org/info/rfc5566>.
[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,
<https://www.rfc-editor.org/info/rfc6811>. <https://www.rfc-editor.org/info/rfc6811>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015,
<https://www.rfc-editor.org/info/rfc7510>.
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205, September Specification", RFC 8205, DOI 10.17487/RFC8205, September
2017, <https://www.rfc-editor.org/info/rfc8205>. 2017, <https://www.rfc-editor.org/info/rfc8205>.
[RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address
Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
<https://www.rfc-editor.org/info/rfc8277>.
Authors' Addresses Authors' Addresses
Keyur Patel Keyur Patel
Arrcus, Inc Arrcus, Inc
2077 Gateway Pl 2077 Gateway Pl
San Jose, CA 95110 San Jose, CA 95110
United States United States
Email: keyur@arrcus.com Email: keyur@arrcus.com
Gunter Van de Velde Gunter Van de Velde
Nokia Nokia
Copernicuslaan 50 Copernicuslaan 50
Antwerpen 2018 Antwerpen 2018
Belgium Belgium
Email: gunter.van_de_velde@nokia.com Email: gunter.van_de_velde@nokia.com
Srihari R. Sangli Srihari R. Sangli
Juniper Networks, Inc Juniper Networks
10 Technology Park Drive
Westford, Massachusetts 01886
United States
Email: ssangli@juniper.net Email: ssangli@juniper.net
John Scudder
Juniper Networks
Email: jgs@juniper.net
 End of changes. 256 change blocks. 
809 lines changed or deleted 852 lines changed or added

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