draft-ietf-idr-tunnel-encaps-20.txt   draft-ietf-idr-tunnel-encaps-21.txt 
IDR Working Group K. Patel IDR Working Group K. Patel
Internet-Draft Arrcus, Inc Internet-Draft Arrcus, Inc
Obsoletes: 5512, 5566, 5640 (if G. Van de Velde Obsoletes: 5512, 5566 (if approved) G. Van de Velde
approved) Nokia Updates: 5640 (if approved) Nokia
Intended status: Standards Track S. Sangli Intended status: Standards Track S. Sangli
Expires: May 14, 2021 J. Scudder Expires: July 11, 2021 J. Scudder
Juniper Networks Juniper Networks
November 10, 2020 January 7, 2021
The BGP Tunnel Encapsulation Attribute The BGP Tunnel Encapsulation Attribute
draft-ietf-idr-tunnel-encaps-20 draft-ietf-idr-tunnel-encaps-21
Abstract Abstract
RFC 5512 defines a BGP Path Attribute known as the "Tunnel This document defines a BGP Path Attribute known as the "Tunnel
Encapsulation Attribute". This attribute allows one to specify a set Encapsulation Attribute", which can be used with BGP UPDATEs of
of tunnels. For each such tunnel, the attribute can provide the various SAFIs to provide information needed to create tunnels and
information needed to create the tunnel and the corresponding their corresponding encapsulation headers. It provides encodings for
encapsulation header. The attribute can also provide information a number of Tunnel Types along with procedures for choosing between
that aids in choosing whether a particular packet is to be sent alternate tunnels and routing packets into tunnels.
through a particular tunnel. RFC 5512 states that the attribute is
only carried in BGP UPDATEs that use the "Encapsulation Subsequent
Address Family (Encapsulation SAFI)". This document deprecates the
Encapsulation SAFI (which has never been used in production), and
specifies semantics for the attribute when it is carried in UPDATEs
of certain other SAFIs. This document adds support for additional
Tunnel Types, and allows a remote tunnel endpoint address to be
specified for each tunnel. This document also provides support for
specifying fields of any inner or outer encapsulations that may be
used by a particular tunnel.
This document obsoletes RFC 5512. Since RFCs 5566 and 5640 rely on This document obsoletes RFC 5512, which provided an earlier
RFC 5512, they are likewise obsoleted. definition of the Tunnel Encapsulation Attribute. RFC 5512 was never
deployed in production. Since RFC 5566 relies on RFC 5512, it is
likewise obsoleted. This document updates RFC 5640 by indicating
that the Load-Balancing Block sub-TLV may be included in any Tunnel
Encapsulation Attribute where load balancing is desired.
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 May 14, 2021. This Internet-Draft will expire on July 11, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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. Use Case for The Tunnel Encapsulation Attribute . . . . . 5 1.3. Use Case for The Tunnel Encapsulation Attribute . . . . . 5
1.4. Brief Summary of Changes from RFC 5512 . . . . . . . . . 6 1.4. Brief Summary of Changes from RFC 5512 . . . . . . . . . 6
1.5. Effects of Obsoleting RFCs 5566 and 5640 . . . . . . . . 7 1.5. Update to RFC 5640 . . . . . . . . . . . . . . . . . . . 7
1.6. Effects of Obsoleting RFC 5566 . . . . . . . . . . . . . 7
2. The Tunnel Encapsulation Attribute . . . . . . . . . . . . . 8 2. The Tunnel Encapsulation Attribute . . . . . . . . . . . . . 8
3. Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . . . . . 9 3. Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . . . . . 9
3.1. The Tunnel Egress Endpoint Sub-TLV . . . . . . . . . . . 9 3.1. The Tunnel Egress Endpoint Sub-TLV (type code 6) . . . . 9
3.1.1. Validating the Address Field . . . . . . . . . . . . 11 3.1.1. Validating the Address Subfield . . . . . . . . . . . 11
3.2. Encapsulation Sub-TLVs for Particular Tunnel Types . . . 12 3.2. Encapsulation Sub-TLVs for Particular Tunnel Types (type
3.2.1. VXLAN . . . . . . . . . . . . . . . . . . . . . . . . 12 code 1) . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.2. NVGRE . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.1. VXLAN (tunnel type 8) . . . . . . . . . . . . . . . . 12
3.2.3. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.2. NVGRE (tunnel type 9) . . . . . . . . . . . . . . . . 14
3.2.4. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.3. L2TPv3 (tunnel type 1) . . . . . . . . . . . . . . . 16
3.2.5. MPLS-in-GRE . . . . . . . . . . . . . . . . . . . . . 17 3.2.4. GRE (tunnel type 2) . . . . . . . . . . . . . . . . . 16
3.2.5. MPLS-in-GRE (tunnel type 11) . . . . . . . . . . . . 17
3.3. Outer Encapsulation Sub-TLVs . . . . . . . . . . . . . . 17 3.3. Outer Encapsulation Sub-TLVs . . . . . . . . . . . . . . 17
3.3.1. DS Field . . . . . . . . . . . . . . . . . . . . . . 18 3.3.1. DS Field (type code 7) . . . . . . . . . . . . . . . 18
3.3.2. UDP Destination Port . . . . . . . . . . . . . . . . 18 3.3.2. UDP Destination Port (type code 8) . . . . . . . . . 18
3.4. Sub-TLVs for Aiding Tunnel Selection . . . . . . . . . . 18 3.4. Sub-TLVs for Aiding Tunnel Selection . . . . . . . . . . 19
3.4.1. Protocol Type Sub-TLV . . . . . . . . . . . . . . . . 19 3.4.1. Protocol Type Sub-TLV (type code 2) . . . . . . . . . 19
3.4.2. Color Sub-TLV . . . . . . . . . . . . . . . . . . . . 19 3.4.2. Color Sub-TLV (type code 4) . . . . . . . . . . . . . 20
3.5. Embedded Label Handling Sub-TLV . . . . . . . . . . . . . 20 3.5. Embedded Label Handling Sub-TLV (type code 9) . . . . . . 20
3.6. MPLS Label Stack Sub-TLV . . . . . . . . . . . . . . . . 21 3.6. MPLS Label Stack Sub-TLV (type code 10) . . . . . . . . . 21
3.7. Prefix-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 23 3.7. Prefix-SID Sub-TLV (type code 11) . . . . . . . . . . . . 23
4. Extended Communities Related to the Tunnel Encapsulation 4. Extended Communities Related to the Tunnel Encapsulation
Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1. Encapsulation Extended Community . . . . . . . . . . . . 24 4.1. Encapsulation Extended Community . . . . . . . . . . . . 24
4.2. Router's MAC Extended Community . . . . . . . . . . . . . 25 4.2. Router's MAC Extended Community . . . . . . . . . . . . . 25
4.3. Color Extended Community . . . . . . . . . . . . . . . . 25 4.3. Color Extended Community . . . . . . . . . . . . . . . . 26
5. Special Considerations for IP-in-IP Tunnels . . . . . . . . . 26 5. Special Considerations for IP-in-IP Tunnels . . . . . . . . . 26
6. Semantics and Usage of the Tunnel Encapsulation attribute . . 26 6. Semantics and Usage of the Tunnel Encapsulation attribute . . 26
7. Routing Considerations . . . . . . . . . . . . . . . . . . . 29 7. Routing Considerations . . . . . . . . . . . . . . . . . . . 29
7.1. Impact on the BGP Decision Process . . . . . . . . . . . 29 7.1. Impact on the BGP Decision Process . . . . . . . . . . . 29
7.2. Looping, Mutual Recursion, Etc. . . . . . . . . . . . . . 29 7.2. Looping, Mutual Recursion, Etc. . . . . . . . . . . . . . 29
8. Recursive Next Hop Resolution . . . . . . . . . . . . . . . . 30 8. Recursive Next Hop Resolution . . . . . . . . . . . . . . . . 30
9. Use of Virtual Network Identifiers and Embedded Labels when 9. Use of Virtual Network Identifiers and Embedded Labels when
Imposing a Tunnel Encapsulation . . . . . . . . . . . . . . . 30 Imposing a Tunnel Encapsulation . . . . . . . . . . . . . . . 31
9.1. Tunnel Types without a Virtual Network Identifier Field . 31 9.1. Tunnel Types without a Virtual Network Identifier Field . 31
9.2. Tunnel Types with a Virtual Network Identifier Field . . 31 9.2. Tunnel Types with a Virtual Network Identifier Field . . 31
9.2.1. Unlabeled Address Families . . . . . . . . . . . . . 31 9.2.1. Unlabeled Address Families . . . . . . . . . . . . . 32
9.2.2. Labeled Address Families . . . . . . . . . . . . . . 32 9.2.2. Labeled Address Families . . . . . . . . . . . . . . 32
10. Applicability Restrictions . . . . . . . . . . . . . . . . . 33 10. Applicability Restrictions . . . . . . . . . . . . . . . . . 33
11. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 11. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
12. Operational Considerations . . . . . . . . . . . . . . . . . 34 12. Operational Considerations . . . . . . . . . . . . . . . . . 35
13. Validation and Error Handling . . . . . . . . . . . . . . . . 35 13. Validation and Error Handling . . . . . . . . . . . . . . . . 35
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
14.1. Obsoleting RFC 5512 . . . . . . . . . . . . . . . . . . 36 14.1. Obsoleting RFC 5512 . . . . . . . . . . . . . . . . . . 36
14.2. Obsoleting Code Points Assigned by RFCs 5566 and 5640 . 36 14.2. Obsoleting Code Points Assigned by RFCs 5566 . . . . . . 37
14.3. BGP Tunnel Encapsulation Parameters Grouping . . . . . . 37 14.3. BGP Tunnel Encapsulation Parameters Grouping . . . . . . 37
14.4. Subsequent Address Family Identifiers . . . . . . . . . 37 14.4. BGP Tunnel Encapsulation Attribute Tunnel Types . . . . 37
14.5. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . 37 14.5. Subsequent Address Family Identifiers . . . . . . . . . 37
14.6. Flags Field of VXLAN Encapsulation sub-TLV . . . . . . . 38 14.6. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . 37
14.7. Flags Field of NVGRE Encapsulation sub-TLV . . . . . . . 38 14.7. Flags Field of VXLAN Encapsulation sub-TLV . . . . . . . 38
14.8. Embedded Label Handling sub-TLV . . . . . . . . . . . . 39 14.8. Flags Field of NVGRE Encapsulation sub-TLV . . . . . . . 39
14.9. Color Extended Community Flags . . . . . . . . . . . . . 39 14.9. Embedded Label Handling sub-TLV . . . . . . . . . . . . 39
15. Security Considerations . . . . . . . . . . . . . . . . . . . 39 14.10. Color Extended Community Flags . . . . . . . . . . . . . 39
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 15. Security Considerations . . . . . . . . . . . . . . . . . . . 40
17. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 40 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41
17. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 41
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
18.1. Normative References . . . . . . . . . . . . . . . . . . 41 18.1. Normative References . . . . . . . . . . . . . . . . . . 42
18.2. Informative References . . . . . . . . . . . . . . . . . 43 18.2. Informative References . . . . . . . . . . . . . . . . . 44
Appendix A. Impact on RFC 8365 . . . . . . . . . . . . . . . . . 45 Appendix A. Impact on RFC 8365 . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
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. Since [RFC5566] and [RFC5640] rely on RFC 5512, into this document. Since [RFC5566] relies on RFC 5512, it is
they are likewise obsoleted. 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, for
"Encapsulation sub-TLV", contain information that may be used to form example, the "Encapsulation sub-TLV", contain information that may be
the encapsulation header for the specified Tunnel Type. Other sub- used to form the encapsulation header for the specified Tunnel Type.
TLVs, e.g., the "color sub-TLV" and the "protocol sub-TLV", contain Other sub- TLVs, for example, the "color sub-TLV" and the "protocol
information that aids in determining whether particular packets sub-TLV", contain information that aids in determining whether
should be sent through the tunnel that the TLV identifies. particular packets 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 selected UPDATE U for local use; o BGP speaker R1 has received and selected UPDATE U for local use;
skipping to change at page 6, line 20 skipping to change at page 6, line 18
the encapsulation information for every one of its BGP next hops. 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 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 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 encapsulate packets to be sent to me, here's the information you need
to properly form the encapsulation header". A BGP speaker signals to properly form the encapsulation header". A BGP speaker signals
this information to other BGP speakers by using a new BGP attribute this information to other BGP speakers by using a new BGP attribute
type value, the BGP Tunnel Encapsulation Attribute. This attribute type value, the BGP Tunnel Encapsulation Attribute. This attribute
specifies the encapsulation protocols that may be used as well as specifies the encapsulation protocols that may be used as well as
whatever additional information (if any) is needed in order to whatever additional information (if any) is needed in order to
properly use those protocols. Other attributes, e.g., communities or properly use those protocols. Other attributes, for example,
extended communities, may also be included. communities or extended communities, may also be included.
1.4. Brief Summary of Changes from RFC 5512 1.4. Brief Summary of Changes from RFC 5512
This document addresses these deficiencies by: This document addresses the deficiencies identified in Section 1.2
by:
o Deprecating the Encapsulation SAFI. o Deprecating the Encapsulation SAFI.
o Defining a new "Tunnel Egress Endpoint sub-TLV" (Section 3.1) that o Defining a new "Tunnel Egress Endpoint sub-TLV" (Section 3.1) that
can be included in any of the TLVs contained in the Tunnel can be included in any of the TLVs contained in the Tunnel
Encapsulation attribute. This sub-TLV can be used to specify the Encapsulation attribute. This sub-TLV can be used to specify the
remote endpoint address of a particular tunnel. remote 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
skipping to change at page 7, line 39 skipping to change at page 7, line 37
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 describes (Section 4.1) how the Tunnel circumstances. This document describes (Section 4.1) how the Tunnel
Encapsulation Extended Community can be used in a backwards- Encapsulation Extended Community can be used in a backwards-
compatible fashion. It is possible to combine Tunnel Encapsulation compatible fashion. It is possible to combine Tunnel Encapsulation
Extended Communities and Tunnel Encapsulation attributes in the same Extended Communities and Tunnel Encapsulation attributes in the same
BGP UPDATE in this manner. BGP UPDATE in this manner.
1.5. Effects of Obsoleting RFCs 5566 and 5640 1.5. Update to RFC 5640
This specification obsoletes RFCs 5566 and 5640. This has the effect This document updates [RFC5640] by indicating that the Load-Balancing
of, in turn, obsoleting a number of code points defined in those Block sub-TLV MAY be included in any Tunnel Encapsulation Attribute
documents. From the "BGP Tunnel Encapsulation Attribute Tunnel where loadbalancing is desired.
Types" registry, "Transmit tunnel endpoint" (type code 3), "IPsec in
Tunnel-mode" (type code 4), "IP in IP tunnel with IPsec Transport
Mode" (type code 5), and "MPLS-in-IP tunnel with IPsec Transport
Mode" (type code 6) are obsoleted. From the "BGP Tunnel
Encapsulation Attribute Sub-TLVs" registry, "IPsec Tunnel
Authenticator" (type code 3) and "Load-Balancing Block" (type code 5)
are obsoleted. See Section 14.2.
Because RFC 8365 depends on RFC 5640, it is similarly obsoleted. 1.6. Effects of Obsoleting RFC 5566
This is further discussed in Appendix A.
This specification obsoletes RFC 5566. This has the effect of, in
turn, obsoleting a number of code points defined in that document.
From the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry,
"Transmit tunnel endpoint" (type code 3), "IPsec in Tunnel-mode"
(type code 4), "IP in IP tunnel with IPsec Transport Mode" (type code
5), and "MPLS-in-IP tunnel with IPsec Transport Mode" (type code 6)
are obsoleted. From the "BGP Tunnel Encapsulation Attribute Sub-
TLVs" registry, "IPsec Tunnel Authenticator" (type code 3) is
obsoleted. See Section 14.2.
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 Tunnel Encapsulation TLV, also known as particular Tunnel Type. A Tunnel Encapsulation TLV, also known as
Tunnel TLV, is structured as shown in Figure 1: 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 (Variable) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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". See Section 3.4.1 for discussion of Attribute Tunnel Types". See Section 3.4.1 for discussion of
special treatment of tunnel types with names of the form "X-in-Y". special treatment of tunnel types with names of the form "X-in-Y".
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) |
+--------------------------------+ +--------------------------------+
skipping to change at page 9, line 11 skipping to change at page 9, line 11
+--------------------------------+ +--------------------------------+
Figure 2: Encapsulation Sub-TLV Value Field 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. The property about the Tunnel TLV that contains this sub-TLV. The
field contains values from the IANA Registry "BGP Tunnel field contains values from the IANA Registry "BGP Tunnel
Encapsulation Attribute Sub-TLVs". 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
This section specifies a number of sub-TLVs. These sub-TLVs can be This section specifies a number of sub-TLVs. These sub-TLVs can be
included in a TLV of the Tunnel Encapsulation attribute. included in a TLV of the Tunnel Encapsulation attribute.
3.1. The Tunnel Egress Endpoint Sub-TLV 3.1. The Tunnel Egress Endpoint Sub-TLV (type code 6)
The Tunnel Egress Endpoint sub-TLV, whose type code is 6, specifies The Tunnel Egress Endpoint sub-TLV specifies the address of the
the address of the egress endpoint of the tunnel, that is, the egress endpoint of the tunnel, that is, the address of the router
address of the router that will decapsulate the payload. Its value that will decapsulate the payload. Its Value field contains three
field contains three subfields: subfields:
1. a reserved subfield 1. a reserved subfield
2. a two-octet Address Family subfield 2. a two-octet Address Family subfield
3. an Address subfield, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Address ~ | Address Family (2 octets) | Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Variable) +
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Tunnel Egress 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 The Reserved subfield SHOULD be originated as zero. It MUST be
disregarded on receipt, and it MUST be propagated unchanged. 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. This document assumes that the Address Family Numbers" registry. This document assumes that the Address
Family is either IPv4 or IPv6; use of other address families is Family is either IPv4 or IPv6; use of other address families 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).
If the Address Family subfield contains the value for IPv6, the If the Address Family subfield contains the value for IPv6, the
address subfield MUST contain an IPv6 address (a /128 IPv6 prefix). Address subfield MUST contain an IPv6 address (a /128 IPv6 prefix).
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
Egress Endpoint sub-TLV is independent of the address family of the Egress Endpoint sub-TLV is independent of the address family of the
UPDATE itself. For example, an UPDATE whose NLRI is an IPv4 address UPDATE itself. For example, an UPDATE whose NLRI is an IPv4 address
may have a Tunnel Encapsulation attribute containing Tunnel Egress may have a Tunnel Encapsulation attribute containing Tunnel Egress
Endpoint sub-TLVs that contain IPv6 addresses. Also, different Endpoint sub-TLVs that contain IPv6 addresses. Also, different
tunnels represented in the Tunnel Encapsulation attribute may have tunnels represented in the Tunnel Encapsulation attribute may have
tunnel egress endpoints of different address families. tunnel egress endpoints of different address families.
There is one special case: the Tunnel Egress Endpoint sub-TLV MAY There is one special case: the Tunnel Egress Endpoint sub-TLV MAY
have a value field whose Address Family subfield contains 0. This have a Value field whose Address Family subfield contains 0. This
means that the tunnel's egress endpoint is the address of the next means that the tunnel's egress endpoint is the address of the next
hop. If the Address Family subfield contains 0, the Address subfield hop. If the Address Family subfield contains 0, the Address subfield
is omitted. In this case, the length field of Tunnel Egress Endpoint is omitted. In this case, the Length field of Tunnel Egress Endpoint
sub-TLV MUST contain the value 6 (0x06). sub-TLV MUST contain the value 6 (0x06).
When the Tunnel Encapsulation attribute is carried in an UPDATE When the Tunnel Encapsulation attribute is carried in an UPDATE
message of one of the AFI/SAFIs specified in this document (see the message of one of the AFI/SAFIs specified in this document (see the
second paragraph of Section 6), each TLV MUST have one, and one only, second paragraph of Section 6), each TLV MUST have one, and one only,
Tunnel Egress Endpoint sub-TLV. If a TLV does not have a Tunnel 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 Egress Endpoint sub-TLV, that TLV should be treated as if it had a
malformed Tunnel Egress Endpoint sub-TLV (see below). malformed Tunnel Egress Endpoint sub-TLV (see below).
If the Address Family subfield has any value other than IPv4 or IPv6, In the context of this specification, if the Address Family subfield
the Tunnel Egress Endpoint sub-TLV is considered "unrecognized" (see has any value other than IPv4, IPv6, or the special value 0, the
Tunnel Egress Endpoint sub-TLV is considered "unrecognized" (see
Section 13). If any of the following conditions hold, the Tunnel Section 13). If any of the following conditions hold, the Tunnel
Egress Endpoint sub-TLV is considered to be "malformed": Egress Endpoint sub-TLV is considered to be "malformed":
o The length of the sub-TLV's Value field is other than 6 added to o The length of the sub-TLV's Value field is other than 6 added to
the defined length for the address family given in its Address the defined length for the address family given in its Address
Family subfield. Therefore, for address family behaviors defined Family subfield. Therefore, for address family behaviors defined
in this document, the permitted values are: in this document, the permitted values are:
* 10, if the Address Family subfield contains the value for IPv4. * 10, if the Address Family subfield contains the value for IPv4.
* 22, if the Address Family subfield contains the value for IPv6. * 22, if the Address Family subfield contains the value for IPv6.
* 6, if the Address Family subfield contains the value zero. * 6, if the Address Family subfield contains the value zero.
o The IP address in the sub-TLV's address subfield lies within a o The IP address in the sub-TLV's Address subfield lies within a
block listed in the relevant Special-Purpose IP Address Registry block listed in the relevant Special-Purpose IP Address Registry
[RFC6890] with either a "destination" attribute value or a [RFC6890] with either a "destination" attribute value or a
"forwardable" attribute value of "false". (Such routes are "forwardable" attribute value of "false". (Such routes are
sometimes colloquially known as "Martians".) sometimes colloquially known as "Martians".) This restriction MAY
be relaxed by explicit configuration.
o It can be determined that the IP address in the sub-TLV's address o It can be determined that the IP address in the sub-TLV's Address
subfield does not belong to the Autonomous System (AS) that subfield does not belong to the Autonomous System (AS) that
originated the route that contains the attribute. Section 3.1.1 originated the route that contains the attribute. Section 3.1.1
describes an optional procedure to make this determination. describes an optional procedure to make this determination.
Error Handling is specified in Section 13. Error Handling is specified in Section 13.
If the Tunnel Egress Endpoint sub-TLV contains an IPv4 or IPv6 If the Tunnel Egress Endpoint sub-TLV contains an IPv4 or IPv6
address that is valid but not reachable, the sub-TLV is not address that is valid but not reachable, the sub-TLV is not
considered to be malformed. considered to be malformed.
3.1.1. Validating the Address Field 3.1.1. Validating the Address Subfield
This section provides a procedure that MAY be applied to validate This section provides a procedure that MAY be applied to validate
that the IP address in the sub-TLV's address subfield belongs to the that the IP address in the sub-TLV's Address subfield belongs to the
AS that originated the route that contains the attribute. (The AS that originated the route that contains the attribute. (The
notion of "belonging to" an AS is expanded on below.) Doing this is notion of "belonging to" an AS is expanded on below.) Doing this is
thought to increase confidence that when traffic is sent to the IP thought to increase confidence that when traffic is sent to the IP
address depicted in the Address Field, it will go to the same AS as address depicted in the Address subfield, it will go to the same AS
it would go to if the Tunnel Encapsulation Attribute were not as it would go to if the Tunnel Encapsulation Attribute were not
present, although of course it cannot guarantee it. See Section 15 present, although of course it cannot guarantee it. See Section 15
for discussion of the limitations of this procedure. The principal for discussion of the limitations of this procedure. The principal
applicability of this procedure is in deployments that are not applicability of this procedure is in deployments that are not
strictly scoped. In deployments with strict scope, and especially strictly scoped. In deployments with strict scope, and especially
those scoped to a single AS, these procedures may not add substantial those scoped to a single AS, these procedures may not add substantial
benefit beyond those discussed in Section 11. benefit beyond those discussed in Section 11.
The Route Origin ASN (Autonomous System Number) of a BGP route that The Route Origin ASN (Autonomous System Number) of a BGP route that
includes a Tunnel Encapsulation Attribute can be determined by includes a Tunnel Encapsulation Attribute can be determined by
inspection of the AS_PATH attribute, according to the procedure inspection of the AS_PATH attribute, according to the procedure
specified in [RFC6811] Section 2. Call this value Route_AS. specified in [RFC6811] Section 2. Call this value Route_AS.
In order to determine the Route Origin ASN of the address depicted in 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 the Address subfield of the Tunnel Egress Endpoint sub-TLV, it is
necessary to consider the forwarding route, that is, the route that necessary to consider the forwarding route, that is, the route that
will be used to forward traffic toward that address. This route is will be used to forward traffic toward that address. This route is
determined by a recursive route lookup operation for that address, as determined by a recursive route lookup operation for that address, as
discussed in [RFC4271] Section 5.1.3. The relevant AS Path to discussed in [RFC4271] Section 5.1.3. The relevant AS Path to
consider is the last one encountered while performing the recursive consider is the last one encountered while performing the recursive
lookup; the procedures of RFC6811 Section 2 are applied to that AS lookup; the procedures of RFC6811 Section 2 are applied to that AS
Path to determine the Route Origin ASN. If no AS Path is encountered Path to determine the Route Origin ASN. If no AS Path is encountered
at all, for example if that route's source is a protocol other than at all, for example if that route's source is a protocol other than
BGP, the Route Origin ASN is the BGP speaker's own AS number. Call BGP, the Route Origin ASN is the BGP speaker's own AS number. Call
this value Egress_AS. this value Egress_AS.
skipping to change at page 12, line 24 skipping to change at page 12, line 25
a Tunnel Egress Endpoint to reside in an AS other than Route_AS; 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 configuration MAY allow for such a case, in which case the check
becomes, if Egress_AS is not within the configured set of permitted becomes, if Egress_AS is not within the configured set of permitted
AS numbers, then the Tunnel Egress Endpoint sub-TLV is considered to AS numbers, then the Tunnel Egress Endpoint sub-TLV is considered to
be "malformed". be "malformed".
Note that if the forwarding route changes, this procedure MUST be Note that if the forwarding route changes, this procedure MUST be
reapplied. As a result, a sub-TLV that was formerly considered valid reapplied. As a result, a sub-TLV that was formerly considered valid
might become not valid, or vice-versa. 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 (type code 1)
This section defines Encapsulation sub-TLVs for the following tunnel This section defines Encapsulation sub-TLVs for the following tunnel
types: VXLAN ([RFC7348]), NVGRE ([RFC7637]), MPLS-in-GRE ([RFC4023]), types: VXLAN ([RFC7348]), NVGRE ([RFC7637]), MPLS-in-GRE ([RFC4023]),
L2TPv3 ([RFC3931]), and GRE ([RFC2784]). L2TPv3 ([RFC3931]), and GRE ([RFC2784]).
Rules for forming the encapsulation based on the information in a Rules for forming the encapsulation based on the information in a
given TLV are given in Section 6 and Section 9. given TLV are given in Section 6 and Section 9.
Recall that the Tunnel Type itself is identified by the Tunnel Type Recall that the tunnel type itself is identified by the Tunnel Type
field in the attribute header (Section 2); the Encapsulation sub- field in the attribute header (Section 2); the Encapsulation sub-
TLV's structure is inferred from this. Regardless of the Tunnel 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 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 also tunnel types for which it is not necessary to define an
Encapsulation sub-TLV, because there are no fields in the 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 (tunnel type 8)
This document defines an Encapsulation sub-TLV for VXLAN tunnels. This document defines an Encapsulation sub-TLV for VXLAN [RFC7348]
When the Tunnel Type is VXLAN (value 8), the length of the sub-TLV is tunnels. When the Tunnel Type is VXLAN, the length of the sub-TLV is
12 octets. The following is the structure of the value field in the 12 octets. The following is the structure of the Value field in the
Encapsulation sub-TLV: 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 (2 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: VXLAN Encapsulation Sub-TLV Value Field Figure 4: VXLAN Encapsulation Sub-TLV Value Field
V: This bit is set to 1 to indicate that a VN-ID (Virtual Network V: This bit is set to 1 to indicate that a VN-ID (Virtual Network
Identifier) is present in the Encapsulation sub-TLV. If set to 0, Identifier) is present in the Encapsulation sub-TLV. If set to 0,
the VN-ID field is disregarded. Please see Section 9. the VN-ID field is disregarded. Please see Section 9.
M: This bit is set to 1 to indicate that a MAC Address is present M: This bit is set to 1 to indicate that a MAC Address is present
in the Encapsulation sub-TLV. If set to 0, the MAC Address field in the Encapsulation sub-TLV. If set to 0, the MAC Address field
is disregarded. 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 on transmission and disregarded on receipt. 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 on transmission and disregarded on receipt. set to all zeroes on transmission and disregarded on receipt.
Reserved: MUST be set to zero on transmission and disregarded on Reserved: MUST be set to zero on transmission and disregarded on
skipping to change at page 14, line 12 skipping to change at page 14, line 12
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 If the V bit is not set, and the BGP UPDATE message has AFI/SAFI o If the V bit is not set, and the BGP UPDATE message has AFI/SAFI
other than Ethernet VPNs (EVPN) then the VXLAN tunnel cannot be other than Ethernet VPNs (SAFI 70, "BGP EVPNs") then the VXLAN
used. tunnel cannot be used.
o Section 9 describes how the VNI field of the VXLAN encapsulation o Section 9 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. (for example,the MAC address) that is used to form this Ethernet
header.
3.2.2. NVGRE 3.2.2. NVGRE (tunnel type 9)
This document defines an Encapsulation sub-TLV for NVGRE tunnels. This document defines an Encapsulation sub-TLV for NVGRE [RFC7637]
When the Tunnel Type is NVGRE (value 9), the length of the sub-TLV is tunnels. When the Tunnel Type is NVGRE, the length of the sub-TLV is
12 octets. The following is the structure of the value field in the 12 octets. The following is the structure of the Value field in the
Encapsulation sub-TLV: 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 (2 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: NVGRE Encapsulation Sub-TLV Value Field Figure 5: NVGRE Encapsulation Sub-TLV Value Field
V: This bit is set to 1 to indicate that a VN-ID is present in the 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 Encapsulation sub-TLV. If set to 0, the VN-ID field is
disregarded. Please see Section 9. disregarded. Please see Section 9.
M: This bit is set to 1 to indicate that a MAC Address is present M: This bit is set to 1 to indicate that a MAC Address is present
in the Encapsulation sub-TLV. If set to 0, the MAC Address field in the Encapsulation sub-TLV. If set to 0, the MAC Address field
skipping to change at page 15, line 24 skipping to change at page 15, line 24
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, used to set the NVGRE VSID (see Section 9). If the V ID value, used to set the NVGRE VSID (see Section 9). If the V
bit is not set, the VN-ID field MUST be set to zero on bit is not set, the VN-ID field MUST be set to zero on
transmission and disregarded on receipt. 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 on transmission and disregarded on receipt. set to all zeroes on transmission and disregarded on receipt.
Reserved (two fields): MUST be set to zero on transmission and Reserved: MUST be set to zero on transmission and disregarded on
disregarded on receipt. 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 NVGRE 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 If the V bit is not set, and the BGP UPDATE message has AFI/SAFI o If the V bit is not set, and the BGP UPDATE message has AFI/SAFI
other than Ethernet VPNs (EVPN) then the NVGRE tunnel cannot be other than Ethernet VPNs (EVPN) then the NVGRE tunnel cannot be
used. used.
o Section 9 describes how the VSID (Virtual Subnet Identifier) field o Section 9 describes how the VSID (Virtual Subnet Identifier) field
of the NVGRE encapsulation header is set. of the NVGRE encapsulation header is set.
3.2.3. L2TPv3 3.2.3. L2TPv3 (tunnel type 1)
When the Tunnel Type of the TLV is L2TPv3 over IP (value 1), the When the Tunnel Type of the TLV is L2TPv3 over IP [RFC3931], the
length of the sub-TLV is between 4 and 12 octets, depending on the length of the sub-TLV is between 4 and 12 octets, depending on the
length of the cookie. The following is the structure of the value length of the cookie. The following is the structure of the Value
field of the Encapsulation sub-TLV: 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) |
| | | |
skipping to change at page 16, line 37 skipping to change at page 16, line 37
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.4. GRE 3.2.4. GRE (tunnel type 2)
When the Tunnel Type of the TLV is GRE (value 2), the length of the When the Tunnel Type of the TLV is GRE [RFC2784], the length of the
sub-TLV is 4 octets. The following is the structure of the value sub-TLV is 4 octets. The following is the structure of the Value
field of the Encapsulation sub-TLV: 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 7: 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. Note that the key is optional. Unless a key advertising router. Note that the key is optional. Unless a key
value is being advertised, the GRE Encapsulation sub-TLV MUST NOT value is being advertised, the GRE Encapsulation sub-TLV MUST NOT
be present. be present.
3.2.5. MPLS-in-GRE 3.2.5. MPLS-in-GRE (tunnel type 11)
When the Tunnel Type is MPLS-in-GRE (value 11), the length of the When the Tunnel Type is MPLS-in-GRE [RFC4023], the length of the sub-
sub-TLV is 4 octets. The following is the structure of the value TLV is 4 octets. The following is the structure of the Value field
field of the Encapsulation sub-TLV: 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 Value Field Figure 8: MPLS-in-GRE Encapsulation Sub-TLV Value Field
GRE-Key: 4-octet field [RFC2890] that is generated by the GRE-Key: 4-octet field [RFC2890] that is generated by the
skipping to change at page 17, line 33 skipping to change at page 17, line 33
value is being advertised, the MPLS-in-GRE Encapsulation sub-TLV value is being advertised, the MPLS-in-GRE Encapsulation sub-TLV
MUST NOT be present. MUST NOT be present.
Note that the GRE Tunnel Type defined in Section 3.2.4 can be used Note that the GRE Tunnel Type defined in Section 3.2.4 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. as the protocol to be encapsulated.
While it is not really necessary to have both the GRE and MPLS-in-GRE Although the MPLS-in-GRE tunnel type is just a special case of the
tunnel types, both are included for reasons of backwards GRE tunnel type and thus is not strictly necessary, it is included
compatibility. for reasons of backwards compatibility with, for example,
implementations of [RFC8365].
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
MUST be treated as if it were an unknown type of sub-TLV. MUST be treated as if it were an unrecognized type of sub-TLV.
3.3.1. DS Field 3.3.1. DS Field (type code 7)
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 Encapsulation attribute require an outer IP encapsulation. The
Differentiated Services (DS) Field sub-TLV, whose type code is 7, can Differentiated Services (DS) Field sub-TLV can be carried in the TLV
be carried in the TLV of any such Tunnel Type. It specifies the of any such Tunnel Type. It specifies the setting of the one-octet
setting of the one-octet Differentiated Services field in the outer Differentiated Services field in the outer IPv4 or IPv6 encapsulation
IPv4 or IPv6 encapsulation (see [RFC2474]). Any one-octet value can (see [RFC2474]). Any one-octet value can be transported; the
be transported; the semantics of the DSCP field is beyond the scope semantics of the DSCP field is beyond the scope of this document.
of this document. The value field is always a single octet. The Value field is always a single octet.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| DS value | | DS value |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
DS Field Sub-TLV Value Field Figure 9: DS Field Sub-TLV Value Field
3.3.2. UDP Destination Port Because the interpretation of the DSCP field at the recipient may be
different from its interpretation at the originator, an
implementation MAY provide a facility to use policy to filter or
modify the DS Field.
3.3.2. UDP Destination Port (type code 8)
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, whose can be specified by including a UDP Destination Port sub-TLV. The
type code is 8. The value field of this sub-TLV is always a two- Value field of this sub-TLV is always a two-octet field, containing
octet field, containing the port value. Any two-octet value other the port value. Any two-octet value other than zero can be
than zero can be transported. If the reserved value zero is transported. If the reserved value zero is received, the sub-TLV
received, the sub-TLV MUST be treated as malformed according to the MUST be treated as malformed according to the rules of Section 13.
rules of Section 13.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Port | | UDP Port (2 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UDP Destination Port Sub-TLV Value Field Figure 10: UDP Destination Port Sub-TLV Value Field
3.4. Sub-TLVs for Aiding Tunnel Selection 3.4. Sub-TLVs for Aiding Tunnel Selection
3.4.1. Protocol Type Sub-TLV
The Protocol Type sub-TLV, whose type code is 2, MAY be included in a 3.4.1. Protocol Type Sub-TLV (type code 2)
given TLV to indicate the type of the payload packets that are
allowed to be encapsulated with the tunnel parameters that are being The Protocol Type sub-TLV MAY be included in a given TLV to indicate
signaled in the TLV. Packets with other payload types MUST NOT be the type of the payload packets that are allowed to be encapsulated
encapsulated in the relevant tunnel. The value field of the sub-TLV with the tunnel parameters that are being signaled in the TLV.
contains a 2-octet value from IANA's "ETHER TYPES" registry Packets with other payload types MUST NOT be encapsulated in the
[Ethertypes]. If the reserved value 0xFFFF is received, the sub-TLV relevant tunnel. The Value field of the sub-TLV contains a 2-octet
MUST be treated as malformed according to the rules of Section 13. value from IANA's "ETHER TYPES" registry [Ethertypes]. If the
reserved value 0xFFFF is received, the sub-TLV MUST be treated as
malformed according to the rules of Section 13.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype | | Ethertype (2 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol Type Sub-TLV Value Field Figure 11: Protocol Type Sub-TLV Value Field
For example, if there are three L2TPv3 sessions, one carrying IPv4 For example, if there are three L2TPv3 sessions, one carrying IPv4
packets, one carrying IPv6 packets, and one carrying MPLS packets, packets, one carrying IPv6 packets, and one carrying MPLS packets,
the egress router will include three TLVs of L2TPv3 encapsulation the egress router will include three TLVs of L2TPv3 encapsulation
type, each specifying a different Session ID and a different payload type, each specifying a different Session ID and a different payload
type. The Protocol Type sub-TLV for these will be IPv4 (protocol type. The Protocol Type sub-TLV for these will be IPv4 (protocol
type = 0x0800), IPv6 (protocol type = 0x86dd), and MPLS (protocol type = 0x0800), IPv6 (protocol type = 0x86dd), and MPLS (protocol
type = 0x8847), respectively. This informs the ingress routers of type = 0x8847), respectively. This informs the ingress routers of
the appropriate encapsulation information to use with each of the the appropriate encapsulation information to use with each of the
given protocol types. Insertion of the specified Session ID at the given protocol types. Insertion of the specified Session ID at the
ingress routers allows the egress to process the incoming packets ingress routers allows the egress to process the incoming packets
correctly, according to their protocol type. correctly, according to their protocol type.
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", for
e.g., "MPLS-in-GRE", only packets of the specified payload type "X" example, "MPLS-in-GRE", only packets of the specified payload type
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 TLV a equivalent of specifying a Tunnel Type "Y" and including in its TLV a
Protocol Type sub-TLV (see Section 3.4.1) specifying protocol "X". Protocol Type sub-TLV (see Section 3.4.1) specifying protocol "X".
If the Tunnel Type is "X-in-Y", it is unnecessary, though harmless, If the Tunnel Type is "X-in-Y", it is unnecessary, though harmless,
to explicitly include a Protocol Type sub-TLV specifying "X". Also, to explicitly include a Protocol Type sub-TLV specifying "X". Also,
for "X-in-Y" type tunnels, a Protocol Type sub-TLV specifying for "X-in-Y" type tunnels, a Protocol Type sub-TLV specifying
anything other than "X" MUST be ignored; this is discussed further in anything other than "X" MUST be ignored; this is discussed further in
Section 13. Section 13.
3.4.2. Color Sub-TLV 3.4.2. Color Sub-TLV (type code 4)
The Color sub-TLV, whose type code is 4, MAY be used as a way to The Color sub-TLV MAY be used as a way to "color" the corresponding
"color" the corresponding Tunnel TLV. The value field of the sub-TLV Tunnel TLV. The Value field of the sub-TLV is eight octets long, and
is eight octets long, and consists of a Color Extended Community, as consists of a Color Extended Community, as defined in Section 4.3.
defined in Section 4.3. For the use of this sub-TLV and Extended For the use of this sub-TLV and Extended Community, please see
Community, please see Section 8. Section 8.
The format of the value field is depicted in Figure 11. The format of the Value field is depicted in Figure 15.
If the Length field of a Color sub-TLV has a value other than 8, or If the Length field of a Color sub-TLV has a value other than 8, or
the first two octets of its value field are not 0x030b, the sub-TLV the first two octets of its Value field are not 0x030b, the sub-TLV
MUST be treated as if it were an unrecognized sub-TLV (see MUST be treated as if it were an unrecognized sub-TLV (see
Section 13). Section 13).
3.5. Embedded Label Handling Sub-TLV 3.5. Embedded Label Handling Sub-TLV (type code 9)
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, for example, 1/4, 2/4, 1/128, 2/128) have MPLS labels embedded
their NLRIs. The term "embedded label" is used to refer to the MPLS in their NLRIs. The term "embedded label" is used to refer to the
label that is embedded in an NLRI, and the term "labeled address MPLS label that is embedded in an NLRI, and the term "labeled address
family" to refer to any AFI/SAFI that has embedded labels. family" to refer to any AFI/SAFI that has embedded labels.
Some of the tunnel types (e.g., VXLAN and NVGRE) that can be Some of the tunnel types (for example, VXLAN and NVGRE) that can be
specified in the Tunnel Encapsulation attribute have an encapsulation specified in the Tunnel Encapsulation attribute have an encapsulation
header containing a "Virtual Network" identifier of some sort. The header containing a "Virtual Network" identifier of some sort. The
Encapsulation sub-TLVs for these tunnel types may optionally specify Encapsulation sub-TLVs for these tunnel types may optionally specify
a value for the virtual network identifier. 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
a labeled 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, whose type code is 9, may be The Embedded Label Handling sub-TLV may be included in any TLV of the
included in any TLV of the Tunnel Encapsulation attribute. If the Tunnel Encapsulation attribute. If the Tunnel Encapsulation
Tunnel Encapsulation attribute is attached to an UPDATE of a non- attribute is attached to an UPDATE of a non-labeled address family,
labeled address family, then the sub-TLV MUST be disregarded. If the then the sub-TLV MUST be disregarded. If the sub-TLV is contained in
sub-TLV is contained in a TLV whose Tunnel Type does not have a a TLV whose Tunnel Type does not have a virtual network identifier in
virtual network identifier in its encapsulation header, the sub-TLV its encapsulation header, the sub-TLV MUST be disregarded. In those
MUST be disregarded. In those cases where the sub-TLV is ignored, it cases where the sub-TLV is ignored, it MUST NOT be stripped from the
SHOULD NOT be stripped from the TLV before the route is propagated. 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 1: The payload will be an MPLS packet with the embedded label at
the top of its label stack. the 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.
If any value other than 1 or 2 is carried, the sub-TLV MUST be If any value other than 1 or 2 is carried, the sub-TLV MUST be
considered malformed, according to the procedures of Section 13. considered malformed, according to the procedures of Section 13.
Please see Section 9 for the details of how this sub-TLV is used when Please see Section 9 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.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| 0 or 1 | | 1 or 2 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Embedded Label Handling Sub-TLV Value Field Figure 12: Embedded Label Handling Sub-TLV Value Field
3.6. MPLS Label Stack Sub-TLV 3.6. MPLS Label Stack Sub-TLV (type code 10)
This sub-TLV, whose type code is 10, allows an MPLS label stack This sub-TLV allows an MPLS label stack ([RFC3032]) to be associated
([RFC3032]) to be associated with a particular tunnel. with a particular tunnel.
The length of the sub-TLV is a multiple of 4 octets and the value The length of the sub-TLV is a multiple of 4 octets and the Value
field of this sub-TLV is a sequence of MPLS label stack entries. The field of this sub-TLV is a sequence of MPLS label stack entries. The
first entry in the sequence is the "topmost" label, the final entry first entry in the sequence is the "topmost" label, the final entry
in the sequence is the "bottommost" label. When this label stack is in the sequence is the "bottommost" label. When this label stack is
pushed onto a packet, this ordering MUST be preserved. 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 Value Field Figure 13: MPLS Label Stack Sub-TLV Value Field
The fields are as defined in [RFC3032], [RFC5462]. 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 before any other labels are pushed onto the packet. (See packet before any other labels are pushed onto the packet. (See
Section 6 for further discussion.) Section 6 for further discussion.)
In particular, if the Tunnel Encapsulation attribute is attached to a In particular, if the Tunnel Encapsulation attribute is attached to a
skipping to change at page 23, line 5 skipping to change at page 23, line 14
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.
Although this specification does not supply detailed instructions for Although this specification does not supply detailed instructions for
validating the received label stack, implementations might impose validating the received label stack, implementations might impose
restrictions on the label stack they can support. If an invalid or restrictions on the label stack they can support. If an invalid or
unsupported label stack is received, the tunnel MAY be treated as not unsupported label stack is received, the tunnel MAY be treated as not
feasible according to the procedures of Section 6. feasible according to the procedures of Section 6.
3.7. Prefix-SID Sub-TLV 3.7. Prefix-SID Sub-TLV (type code 11)
[RFC8669] defines a BGP Path attribute known as the "Prefix-SID [RFC8669] defines a BGP Path attribute known as the "Prefix-SID
Attribute". This attribute is defined to contain a sequence of one Attribute". This attribute is defined to contain a sequence of one
or more TLVs, where each TLV is either a "Label-Index" TLV, or an or more TLVs, where each TLV is either a "Label-Index" TLV, or an
"Originator SRGB (Source Routing Global Block)" TLV. "Originator SRGB (Source Routing Global Block)" TLV.
This document defines a Prefix-SID sub-TLV, whose type code is 11. This document defines a Prefix-SID sub-TLV. The Value field of the
The value field of the Prefix-SID sub-TLV can be set to any permitted Prefix-SID sub-TLV can be set to any permitted value of the Value
value of the value field of a BGP Prefix-SID attribute [RFC8669]. field of a BGP Prefix-SID attribute [RFC8669].
[RFC8669] only defines behavior when the Prefix-SID Attribute is [RFC8669] only defines behavior when the Prefix-SID Attribute is
attached to routes of type IPv4/IPv6 Labeled Unicast ([RFC4760], attached to routes of type IPv4/IPv6 Labeled Unicast ([RFC4760],
[RFC8277]), and it only defines values of the Prefix-SID Attribute [RFC8277]), and it only defines values of the Prefix-SID Attribute
for those cases. Therefore, similar limitations exist for the for those cases. Therefore, similar limitations exist for the
Prefix-SID sub-TLV: it SHOULD only be included in a BGP UPDATE Prefix-SID sub-TLV: it SHOULD only be included in a BGP UPDATE
message for one of the address families defined in [RFC8669]. If message for one of the address families defined in [RFC8669]. If
included in a BGP UPDATE for any other address family then it MUST be included in a BGP UPDATE for any other address family then it MUST be
ignored. ignored.
skipping to change at page 23, line 42 skipping to change at page 23, line 51
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, if that packet is sent through the tunnel identified by the TLV, if that
tunnel is from a labeled address family, the corresponding MPLS label tunnel is from a labeled address family, the corresponding MPLS label
MUST be pushed on the packet's label stack. The corresponding MPLS MUST be pushed on the packet's label stack. The corresponding MPLS
label is computed from the Label-Index value and the SRGB of the label is computed from the Label-Index value and the SRGB of the
route's originator, as specified in section 4.1 of [RFC8669]. route's originator, as specified in section 4.1 of [RFC8669].
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 (for example, a label
UPDATE's NLRI, or a label determined by the procedures of Section 9, embedded in UPDATE's NLRI, or a label determined by the procedures of
are pushed on the stack. Section 9), 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 what 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 receiving BGP speaker need not even Prefix-SID sub-TLV is used, the receiving BGP speaker need not even
be in the same Segment Routing Domain as the tunnel's egress be in the same Segment Routing Domain as the tunnel's egress
skipping to change at page 24, line 23 skipping to change at page 24, line 33
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. Community.
The Encapsulation Extended Community encoding is as shown below The Encapsulation Extended Community encoding is as shown below
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 | 0x0c | Reserved | | 0x03 (1 Octet)| 0x0c (1 Octet)| Reserved (2 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Tunnel Type | | Reserved (2 Octets) | Tunnel Type (2 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Encapsulation Extended Community Figure 14: Encapsulation Extended Community
The value of the high-order octet of the extended type field is 0x03, 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 which indicates it's transitive. The value of the low-order octet of
the extended type field is 0x0c. the extended type field is 0x0c.
The last two octets of the value field encode a tunnel type. 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 This Extended Community may be attached to a route of any AFI/SAFI to
which the Tunnel Encapsulation attribute may be attached. Each such which the Tunnel Encapsulation attribute may be attached. Each such
Extended Community identifies a particular Tunnel Type, its semantics Extended Community identifies a particular Tunnel Type, its semantics
are the same as semantics of a Tunnel Encapsulation attribute Tunnel are the same as semantics of a Tunnel Encapsulation attribute Tunnel
TLV for which the following three conditions all hold: TLV for which the following three conditions all hold:
1. it identifies the same Tunnel Type, 1. it identifies the same Tunnel Type,
2. it has a Tunnel Egress Endpoint sub-TLV for which one of the 2. it has a Tunnel Egress Endpoint sub-TLV for which one of the
skipping to change at page 25, line 16 skipping to change at page 25, line 27
Such a Tunnel TLV is called 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. In applications, and is still needed for backwards compatibility. In
situations where a tunnel could be encoded using a barebones TLV, it situations where a tunnel could be encoded using a barebones TLV, it
MUST be encoded using the corresponding Encapsulation Extended MUST be encoded using the corresponding Encapsulation Extended
Community. Notwithstanding, an implementation MUST be prepared to Community. Notwithstanding, an implementation MUST be prepared to
process a tunnel received encoded as a barebones TLV process a tunnel received encoded as a barebones TLV.
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", for example, MPLS-
the Encapsulation Extended Community implies that only packets of the in-GRE, the Encapsulation Extended Community implies that only
specified payload type "X" are to be carried through the tunnel of packets of the specified payload type "X" are to be carried through
type "Y". Packets with other payload types MUST NOT be carried the tunnel of type "Y". Packets with other payload types MUST NOT be
through such tunnels. See also Section 2. carried through such tunnels. See also Section 2.
In the remainder of this specification, when a route is referred to In the remainder of this specification, when a route is referred to
as containing a Tunnel Encapsulation attribute with a TLV identifying as containing a Tunnel Encapsulation attribute with a TLV identifying
a particular Tunnel Type, it implicitly includes the case where the a particular Tunnel Type, it implicitly includes the case where the
route contains a Tunnel Encapsulation Extended Community identifying route contains a Tunnel Encapsulation Extended Community 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
skipping to change at page 26, line 8 skipping to change at page 26, line 13
in the Router's MAC Extended Community MUST be used. in the Router's MAC Extended Community MUST be used.
4.3. Color Extended Community 4.3. Color Extended Community
The Color Extended Community is a Transitive Opaque Extended The Color Extended Community is a Transitive Opaque Extended
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 | Flags | | 0x03 (1 Octet)| 0x0b (1 Octet)| Flags (2 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color Value | | Color Value (4 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Color Extended Community Figure 15: Color Extended Community
The value of the high-order octet of the extended type field is 0x03, 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 which indicates it is transitive. The value of the low-order octet
of the extended type field for this community is 0x0b. The color of the extended type field for this community is 0x0b. The color
value is user defined and configured locally. No flags are defined value is user defined and configured locally. No flags are defined
in this document; this field MUST be set to zero by the originator in this document; this field MUST be set to zero by the originator
and ignored by the receiver; the value MUST NOT be changed when and ignored by the receiver; the value MUST NOT be changed when
propagating this Extended Community. The Color Value field is propagating this Extended Community. The Color Value field is
encoded as 4 octet value by the administrator and is outside the encoded as 4 octet value by the administrator and is outside the
scope of this document. For the use of this Extended Community scope of this document. For the use of this Extended Community
skipping to change at page 26, line 39 skipping to change at page 26, line 44
tunnel overlay with the tunnel type IP-in-IP. The egress BGP speaker 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 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- 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 IP, it will not have a Virtual Network Identifier. However, the
tunnel egress endpoint address can be used in identifying the tunnel egress endpoint address can be used in identifying the
forwarding table to use for making the forwarding decisions to forwarding table to use for making the forwarding decisions to
forward the payload. forward the payload.
6. Semantics and Usage of the Tunnel Encapsulation attribute 6. Semantics and Usage of the Tunnel Encapsulation attribute
[RFC5512] specifies the use of the Tunnel Encapsulation attribute in
BGP UPDATE messages of AFI/SAFI 1/7 and 2/7. That document restricts
the use of this attribute to UPDATE messages of those SAFIs. This
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.
There is no significance to the order in which the TLVs occur within There is no significance to the order in which the TLVs occur within
the Tunnel Encapsulation attribute. Multiple TLVs may occur for a the Tunnel Encapsulation attribute. Multiple TLVs may occur for a
skipping to change at page 27, line 27 skipping to change at page 27, line 27
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 four tunnel is considered feasible if it has the following four
properties: properties:
* The Tunnel Type is supported (i.e., router R knows how to set * The Tunnel Type is supported (that is, router R knows how to
up tunnels of that type, how to create the encapsulation header set up tunnels of that type, how to create the encapsulation
for tunnels of that type, etc.) header 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 (for
(e.g., an MPLS-in-UDP tunnel would not be a feasible tunnel for example, an MPLS-in-UDP tunnel would not be a feasible tunnel
carrying an IP packet, unless the IP packet can first be for carrying an IP packet, unless the IP packet can first be
encapsulated in a MPLS packet). encapsulated in a MPLS packet).
* The tunnel is specified in a TLV whose Tunnel Egress Endpoint * The tunnel is specified in a TLV whose Tunnel Egress Endpoint
sub-TLV identifies an IP address that is reachable. The sub-TLV identifies an IP address that is reachable. The
reachability condition is evaluated as per [RFC4271]. If the reachability condition is evaluated as per [RFC4271]. If the
IP address is reachable via more than one forwarding table, IP address is reachable via more than one forwarding table,
local policy is used to determine which table to use. local policy is used to determine which table to use.
* There is no local policy that prevents the use of the tunnel. * There is no local policy that prevents the use of the tunnel.
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 (that is,
it specifies several feasible tunnels), router R may choose any one if it specifies several feasible tunnels), router R may choose any
of those tunnels, based upon local policy. If any Tunnel TLV one of those tunnels, based upon local policy. If any Tunnel TLV
contains one or more Color sub-TLVs (Section 3.4.2) and/or the contains one or more Color sub-TLVs (Section 3.4.2) and/or the
Protocol Type sub-TLV (Section 3.4.1), the choice of tunnel may be Protocol Type sub-TLV (Section 3.4.1), the choice of tunnel may be
influenced by these sub-TLVs. influenced by these sub-TLVs. Many other factors, for example
minimization of encapsulation header overhead, could also be used to
influence selection.
The reachability to the address of the egress endpoint of the tunnel The reachability to the address of the egress endpoint of the tunnel
may change over time, directly impacting the feasibility of the may change over time, directly impacting the feasibility of the
tunnel. A tunnel that is not feasible at some moment, may become tunnel. A tunnel that is not feasible at some moment, may become
feasible at a later time when its egress endpoint address is feasible at a later time when its egress endpoint address is
reachable. The router may start using the newly feasible tunnel reachable. The router may start using the newly feasible tunnel
instead of an existing one. How this decision is made is outside the instead of an existing one. How this decision is made is outside the
scope of this document. scope of this document.
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 Tunnel TLV of a particular Tunnel Encapsulation in a particular Tunnel TLV of a particular Tunnel Encapsulation
attribute, then the tunnel's egress endpoint address is the IP attribute, then the tunnel's egress endpoint address is the IP
address contained in the sub-TLV. If the Tunnel TLV contains a address contained in the Tunnel Egress Endpoint sub-TLV. If the
Tunnel Egress Endpoint sub-TLV whose value field is all zeroes, then Tunnel TLV contains a Tunnel Egress Endpoint sub-TLV whose Value
the tunnel's egress endpoint is the address of the Next Hop of the field is all zeroes, then the tunnel's egress endpoint is the address
BGP Update containing the Tunnel Encapsulation attribute. The of the Next Hop of the BGP Update containing the Tunnel Encapsulation
address of the tunnel egress endpoint generally appears in a attribute. The address of the tunnel egress endpoint generally
"destination address" field of the encapsulation. appears in a "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 (for example, 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.
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 Egress Endpoint sub-TLVs, different Encapsulation different Tunnel Egress Endpoint sub-TLVs, different Encapsulation
sub-TLVs, etc. Choosing between two such tunnels is a matter of sub-TLVs, etc. Choosing between two such tunnels is a matter of
local policy. local policy.
skipping to change at page 30, line 37 skipping to change at page 30, line 41
o the best route to router R2 is a BGP route that was advertised in o the best route 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 6 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 one or more Color Sub-TLVs. In that case, packet
NOT be sent through the tunnel contained in that TLV, unless U1 is P MUST NOT be sent through the tunnel contained in that TLV, unless
carrying the Color Extended Community that is identified in U2's U1 is carrying a Color Extended Community that is identified in one
Color Sub-TLV. of U2's Color Sub-TLVs.
The procedures in this section presuppose that U1's address of the The procedures in this section presuppose that U1's address of the
next hop resolves to a BGP route, and that U2's next hop resolves next hop resolves to a BGP route, and that U2's next hop resolves
(perhaps after further recursion) to a non-BGP route. (perhaps after further recursion) to a non-BGP route.
9. 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
skipping to change at page 31, line 23 skipping to change at page 31, line 30
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. When a packet is sent through a tunnel specified the UPDATE's NLRI. When a packet is sent through a tunnel specified
in one of the attribute's TLVs, and that tunnel type does not contain in one of the attribute's TLVs, and that tunnel type does not contain
a virtual network identifier field, the label or labels from the NLRI a virtual network identifier field, the label or labels from the NLRI
are pushed on the packet's label stack. The resulting MPLS packet is are pushed on the packet's label stack. The resulting MPLS packet is
then further encapsulated, as specified by the TLV. then further encapsulated, as specified by the TLV.
9.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 Two 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 encapsulation, this field is encapsulation headers. In the VXLAN encapsulation, this field is
called the VNI (Virtual Network Identifier) field; in the NVGRE called the VNI (VXLAN Network Identifier) field; in the NVGRE
encapsulation, this field is called the VSID (Virtual Subnet encapsulation, this field is called the VSID (Virtual Subnet
Identifier) field. 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 in 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).
skipping to change at page 34, line 4 skipping to change at page 34, line 14
contains an IP address that is not in same AS as the router receiving contains an IP address that is not in same AS as the router receiving
the route, it is very likely that the embedded label has been the route, it is very likely that the embedded label has been
changed. Therefore use of the Tunnel Encapsulation attribute in an changed. Therefore use of the Tunnel Encapsulation attribute in an
"Inter-AS option b" scenario is not recommended. "Inter-AS option b" scenario is not recommended.
Other documents may define other ways to signal tunnel information in Other documents may define other ways to signal tunnel information in
BGP. For example, [RFC6514] defines the "P-Multicast Service BGP. For example, [RFC6514] defines the "P-Multicast Service
Interface Tunnel" (PMSI Tunnel) attribute. In this specification, we Interface Tunnel" (PMSI Tunnel) attribute. In this specification, we
do not consider the effects of advertising the Tunnel Encapsulation do not consider the effects of advertising the Tunnel Encapsulation
Attribute in conjunction with other forms of signaling tunnels. Any Attribute in conjunction with other forms of signaling tunnels. Any
document specifying such joint use should provide details as to how document specifying such joint use MUST provide details as to how
interactions should be handled. interactions should be handled.
11. 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 the Tunnel Encapsulation attribute MUST be
attribute be used only within a well-defined scope, e.g., within a used only within a well-defined scope, for example, within a set of
set of Autonomous Systems that belong to a single administrative Autonomous Systems that belong to a single administrative entity. If
entity. If the attribute is distributed beyond its intended scope, the attribute is distributed beyond its intended scope, packets may
packets may be sent through tunnels in a manner that is not intended. 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 distributed. This UPDATE, the attribute is neither processed nor distributed. This
filtering SHOULD be possible on a per-BGP-session basis; finer filtering SHOULD be possible on a per-BGP-session basis; finer
granularities (for example, per route and/or per attribute TLV) MAY granularities (for example, per route and/or per attribute TLV) MAY
be supported. For each external BGP (EBGP) session, filtering of the be supported. For each external BGP (EBGP) session, filtering of the
attribute on incoming UPDATEs MUST be enabled by default. attribute on incoming UPDATEs MUST be enabled by default.
skipping to change at page 34, line 51 skipping to change at page 35, line 15
12. Operational Considerations 12. Operational Considerations
A potential operational difficulty arises when tunnels are used, if A potential operational difficulty arises when tunnels are used, if
the size of packets entering the tunnel exceeds the maximum the size of packets entering the tunnel exceeds the maximum
transmission unit (MTU) the tunnel is capable of supporting. This transmission unit (MTU) the tunnel is capable of supporting. This
difficulty can be exacerbated by stacking multiple tunnels, since difficulty can be exacerbated by stacking multiple tunnels, since
each stacked tunnel header further reduces the supportable MTU. This each stacked tunnel header further reduces the supportable MTU. This
issue is long-standing and well-known. The tunnel signaling provided issue is long-standing and well-known. The tunnel signaling provided
in this specification does nothing to address this issue, nor to in this specification does nothing to address this issue, nor to
aggravate it (except insofar as it may further increase the aggravate it (except insofar as it may further increase the
popularity of tunnelling). popularity of tunneling).
13. Validation and Error Handling 13. 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, and the "Treat-as- case, the TLV MUST be considered to be malformed, and the "Treat-as-
withdraw" procedure of [RFC7606] is applied. withdraw" procedure of [RFC7606] is applied.
skipping to change at page 35, line 51 skipping to change at page 36, line 15
tunnel. tunnel.
If a TLV of a Tunnel Encapsulation attribute contains a sub-TLV that If a TLV of a Tunnel Encapsulation attribute contains a sub-TLV that
is not recognized by a particular BGP speaker, the BGP speaker MUST 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. process that TLV as if the unrecognized sub-TLV had not been present.
If the route carrying the Tunnel Encapsulation attribute is If the route carrying the Tunnel Encapsulation attribute is
propagated with the attribute, the unrecognized sub-TLV MUST remain propagated with the attribute, the unrecognized sub-TLV MUST remain
in the attribute. in the attribute.
In general, if a TLV contains a sub-TLV that is malformed, the sub- In general, if a TLV contains a sub-TLV that is malformed, the sub-
TLV MUST be treated as if it were an unrecognized sub-TLV. This TLV MUST be treated as if it were an unrecognized sub-TLV. There is
document specifies one exception to this rule -- if a TLV contains a one exception to this rule -- if a TLV contains a malformed Tunnel
malformed Tunnel Egress Endpoint sub-TLV (as defined in Section 3.1), Egress Endpoint sub-TLV (as defined in Section 3.1), the entire TLV
the entire TLV MUST be ignored, and MUST be removed from the Tunnel MUST be ignored, and MUST be removed from the Tunnel Encapsulation
Encapsulation attribute before the route carrying that attribute is attribute before the route carrying that attribute is distributed.
distributed.
Within a Tunnel Encapsulation attribute that is carried by a BGP Within a Tunnel Encapsulation attribute that is carried by a BGP
UPDATE whose AFI/SAFI is one of those explicitly listed in the second UPDATE whose AFI/SAFI is one of those explicitly listed in the second
paragraph of Section 6, a TLV that does not contain exactly one 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 Tunnel Egress Endpoint sub-TLV MUST be treated as if it contained a
malformed Tunnel Egress Endpoint sub-TLV. malformed Tunnel Egress Endpoint sub-TLV.
A TLV identifying a particular Tunnel Type may contain a sub-TLV that A TLV identifying a particular Tunnel Type may contain a sub-TLV that
is meaningless for that Tunnel Type. For example, perhaps the TLV is meaningless for that Tunnel Type. For example, perhaps the TLV
contains a UDP Destination Port sub-TLV, but the identified tunnel contains a UDP Destination Port sub-TLV, but the identified tunnel
skipping to change at page 36, line 39 skipping to change at page 37, line 5
This document makes the following requests of IANA. (All This document makes the following requests of IANA. (All
registration procedures listed below are per their definitions in registration procedures listed below are per their definitions in
[RFC8126].) [RFC8126].)
14.1. Obsoleting RFC 5512 14.1. Obsoleting RFC 5512
Because this document obsoletes RFC 5512, change all registration Because this document obsoletes RFC 5512, change all registration
information that references [RFC5512] to instead reference this information that references [RFC5512] to instead reference this
document. document.
14.2. Obsoleting Code Points Assigned by RFCs 5566 and 5640 14.2. Obsoleting Code Points Assigned by RFCs 5566
Since this document obsoletes RFCs 5566 and 5640, the code points Since this document obsoletes RFC 5566, the code points assigned by
assigned by those RFCs are similarly obsoleted. Specifically, the that RFC are similarly obsoleted. Specifically, the following code
following code points should be marked as deprecated. points should be marked as deprecated.
In the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry: In the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry:
+-------+---------------------------------------------+ +-------+---------------------------------------------+
| Value | Name | | Value | Name |
+-------+---------------------------------------------+ +-------+---------------------------------------------+
| 3 | Transmit tunnel endpoint | | 3 | Transmit tunnel endpoint |
| 4 | IPsec in Tunnel-mode | | 4 | IPsec in Tunnel-mode |
| 5 | IP in IP tunnel with IPsec Transport Mode | | 5 | IP in IP tunnel with IPsec Transport Mode |
| 6 | MPLS-in-IP tunnel with IPsec Transport Mode | | 6 | MPLS-in-IP tunnel with IPsec Transport Mode |
+-------+---------------------------------------------+ +-------+---------------------------------------------+
And in the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry: And in the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry:
+-------+----------------------------+ +-------+----------------------------+
| Value | Name | | Value | Name |
+-------+----------------------------+ +-------+----------------------------+
| 3 | IPsec Tunnel Authenticator | | 3 | IPsec Tunnel Authenticator |
| 5 | Load-Balancing Block |
+-------+----------------------------+ +-------+----------------------------+
14.3. BGP Tunnel Encapsulation Parameters Grouping 14.3. BGP Tunnel Encapsulation Parameters Grouping
Create a new registry grouping, to be named "BGP Tunnel Encapsulation Create a new registry grouping, to be named "BGP Tunnel Encapsulation
Parameters". Parameters".
14.4. Subsequent Address Family Identifiers 14.4. BGP Tunnel Encapsulation Attribute Tunnel Types
Relocate the "BGP Tunnel Encapsulation Attribute Tunnel Types"
registry to be under the "BGP Tunnel Encapsulation Parameters"
grouping.
14.5. Subsequent Address Family Identifiers
Modify the "Subsequent Address Family Identifiers" registry to Modify the "Subsequent Address Family Identifiers" registry to
indicate that the Encapsulation SAFI (value 7) is obsoleted. This indicate that the Encapsulation SAFI (value 7) is obsoleted. This
document should be the reference. document should be the reference.
14.5. BGP Tunnel Encapsulation Attribute Sub-TLVs 14.6. BGP Tunnel Encapsulation Attribute Sub-TLVs
Relocate the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry Relocate the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry
to be under the "BGP Tunnel Encapsulation Parameters" grouping. to be under the "BGP Tunnel Encapsulation Parameters" grouping.
Add the following note to the registry: Add the following note to the 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.
skipping to change at page 38, line 27 skipping to change at page 38, line 34
Rename the following entries within the registry: Rename the following entries within the registry:
+-------+-----------------+------------------------+ +-------+-----------------+------------------------+
| Value | Old Name | New Name | | Value | Old Name | New Name |
+-------+-----------------+------------------------+ +-------+-----------------+------------------------+
| 6 | Remote Endpoint | Tunnel Egress Endpoint | | 6 | Remote Endpoint | Tunnel Egress Endpoint |
| 7 | IPv4 DS Field | DS Field | | 7 | IPv4 DS Field | DS Field |
+-------+-----------------+------------------------+ +-------+-----------------+------------------------+
14.6. Flags Field of VXLAN Encapsulation sub-TLV 14.7. Flags Field of VXLAN Encapsulation sub-TLV
Create a registry named "Flags Field of VXLAN Encapsulation sub-TLV" Create a registry named "Flags Field of VXLAN Encapsulation sub-TLV"
under the "BGP Tunnel Encapsulation Parameters" grouping. The under the "BGP Tunnel Encapsulation Parameters" grouping. The
registration policy for this registry is "Standards Action". registration policy for this registry is "Standards Action". The
minimum possible value is 0, the maximum is 7.
The initial values for this new registry are indicated below. The initial values for this new registry are indicated below.
+--------------+--------------------------------+-----------------+ +--------------+-----------------+-----------------+
| Bit Position | Description | Reference | | Bit Position | Description | Reference |
+--------------+--------------------------------+-----------------+ +--------------+-----------------+-----------------+
| 0 | V (Virtual Network Identifier) | (this document) | | 0 | V (VN-ID) | (this document) |
| 1 | M (MAC Address) | (this document) | | 1 | M (MAC Address) | (this document) |
+--------------+--------------------------------+-----------------+ +--------------+-----------------+-----------------+
14.7. Flags Field of NVGRE Encapsulation sub-TLV 14.8. Flags Field of NVGRE Encapsulation sub-TLV
Create a registry named "Flags Field of NVGRE Encapsulation sub-TLV" Create a registry named "Flags Field of NVGRE Encapsulation sub-TLV"
under the "BGP Tunnel Encapsulation Parameters" grouping. The under the "BGP Tunnel Encapsulation Parameters" grouping. The
registration policy for this registry is "Standards Action". registration policy for this registry is "Standards Action". The
minimum possible value is 0, the maximum is 7.
The initial values for this new registry are indicated below. The initial values for this new registry are indicated below.
+--------------+-----------------+-----------------+ +--------------+-----------------+-----------------+
| Bit Position | Description | Reference | | Bit Position | Description | Reference |
+--------------+-----------------+-----------------+ +--------------+-----------------+-----------------+
| 0 | V (VN-ID) | (this document) | | 0 | V (VN-ID) | (this document) |
| 1 | M (MAC Address) | (this document) | | 1 | M (MAC Address) | (this document) |
+--------------+-----------------+-----------------+ +--------------+-----------------+-----------------+
14.8. Embedded Label Handling sub-TLV 14.9. Embedded Label Handling sub-TLV
Create a registry named "Embedded Label Handling sub-TLV" under the Create a registry named "Embedded Label Handling sub-TLV" under the
"BGP Tunnel Encapsulation Parameters" grouping. The registration "BGP Tunnel Encapsulation Parameters" grouping. The registration
policy for this registry is "Standards Action". policy for this registry is "Standards Action". The minimum possible
value is 0, the maximum is 255.
The initial values for this new registry are indicated below. The initial values for this new registry are indicated below.
+-------+-------------------------------------+-----------------+ +-------+-------------------------------------+-----------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-------------------------------------+-----------------+ +-------+-------------------------------------+-----------------+
| 0 | Reserved | (this document) |
| 1 | Payload of MPLS with embedded label | (this document) | | 1 | Payload of MPLS with embedded label | (this document) |
| 2 | no embedded label in payload | (this document) | | 2 | no embedded label in payload | (this document) |
+-------+-------------------------------------+-----------------+ +-------+-------------------------------------+-----------------+
14.9. Color Extended Community Flags 14.10. Color Extended Community Flags
Create a registry named "Color Extended Community Flags" under the Create a registry named "Color Extended Community Flags" under the
"BGP Tunnel Encapsulation Parameters" grouping. The registration "BGP Tunnel Encapsulation Parameters" grouping. The registration
policy for this registry is "Standards Action". policy for this registry is "Standards Action". The minimum possible
value is 0, the maximum is 15.
No initial values are to be registered. The format of the registry No initial values are to be registered. The format of the registry
is shown below. is shown below.
+--------------+-------------+-----------+ +--------------+-------------+-----------+
| Bit Position | Description | Reference | | Bit Position | Description | Reference |
+--------------+-------------+-----------+ +--------------+-------------+-----------+
+--------------+-------------+-----------+ +--------------+-------------+-----------+
15. Security Considerations 15. Security Considerations
As Section 11 discusses, it is intended that the Tunnel Encapsulation As Section 11 discusses, 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, for example,
set of Autonomous Systems that belong to a single administrative within a set of Autonomous Systems that belong to a single
entity. As long as the filtering mechanisms discussed in that administrative entity. As long as the filtering mechanisms discussed
section are applied diligently, an attacker outside the scope would in that section are applied diligently, an attacker outside the scope
not be able to use the Tunnel Encapsulation attribute in an attack. would not be able to use the Tunnel Encapsulation attribute in an
This leaves open the questions of attackers within the scope (for attack. This leaves open the questions of attackers within the scope
example, a compromised router) and failures in filtering that allow (for example, a compromised router) and failures in filtering that
an external attack to succeed. allow an external attack to succeed.
As [RFC4272] discusses, BGP is vulnerable to traffic diversion As [RFC4272] discusses, BGP is vulnerable to traffic diversion
attacks. The Tunnel Encapsulation attribute adds a new means by attacks. The Tunnel Encapsulation attribute adds a new means by
which an attacker could cause traffic to be diverted from its normal which an attacker could cause traffic to be diverted from its normal
path, especially when the Tunnel Egress Endpoint sub-TLV is used. path, especially when the Tunnel Egress Endpoint sub-TLV is used.
Such an attack would differ from pre-existing vulnerabilities in that Such an attack would differ from pre-existing vulnerabilities in that
traffic could be tunneled to a distant target across intervening traffic could be tunneled to a distant target across intervening
network infrastructure, allowing an attack to potentially succeed network infrastructure, allowing an attack to potentially succeed
more easily, since less infrastructure would have to be subverted. more easily, since less infrastructure would have to be subverted.
Potential consequences include "hijacking" of traffic (insertion of Potential consequences include "hijacking" of traffic (insertion of
an undesired node in the path) or denial of service (directing an undesired node in the path allowing for inspection or modification
traffic to a node that doesn't desire to receive it). of traffic, or avoidance of security controls) 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 In order to further mitigate the risk of diversion of traffic from
its intended destination, Section 3.1.1 provides an optional its intended destination, Section 3.1.1 provides an optional
procedure to check that the destination given in a Tunnel Egress 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. 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. As RFC 4272 Tunnel Encapsulation attribute not been present. As RFC 4272
discusses, it's possible for an attacker to announce an inaccurate discusses, it's possible for an attacker to announce an inaccurate
AS_PATH, therefore an attacker with the ability to inject a Tunnel AS_PATH, therefore an attacker with the ability to inject a Tunnel
Egress Endpoint sub-TLV could equally craft an AS_PATH that would Egress Endpoint sub-TLV could equally craft an AS_PATH that would
pass the validation procedures of Section 3.1.1. BGP Origin pass the validation procedures of Section 3.1.1. BGP Origin
Validation [RFC6811] and BGPsec [RFC8205] provide means to increase Validation [RFC6811] and BGPsec [RFC8205] provide means to increase
assurance that the origins being validated have not been falsified. assurance that the origins being validated have not been falsified.
Many tunnels carry traffic that embeds a destination address that
comes from a non-global namespace. One example is MPLS VPNs. If a
tunnel crosses from one namespace to another, without the necessary
translation being performed for the embedded address(es), there
exists a risk of misdelivery of traffic. If the traffic contains
confidential data that's not otherwise protected (for example, by
end-to-end encryption) then confidential information could be
revealed. The restriction of applicability of the Tunnel
Encapsulation attribute to a well-defined scope limits the likelihood
of this occurring. See the discussion of "option b" in Section 10
for further discussion of one such scenario.
16. Acknowledgments 16. Acknowledgments
This document contains text from RFC 5512, authored by Pradosh This document contains text from RFC 5512, authored by Pradosh
Mohapatra and Eric Rosen. The authors of the current document wish Mohapatra and Eric Rosen. The authors of the current document wish
to thank them for their contribution. RFC 5512 itself built upon to thank them for their contribution. RFC 5512 itself built upon
prior work by Gargi Nalawade, Ruchi Kapoor, Dan Tappan, David Ward, prior work by Gargi Nalawade, Ruchi Kapoor, Dan Tappan, David Ward,
Scott Wainner, Simon Barber, Lili Wang, and Chris Metz, whom the Scott Wainner, Simon Barber, Lili Wang, and Chris Metz, whom the
authors also thank for their contributions. Eric Rosen was the authors also thank for their contributions. Eric Rosen was the
principal author of earlier versions of this document. principal author of earlier versions of this document.
skipping to change at page 42, line 35 skipping to change at page 43, line 14
[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>.
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January
2008, <https://www.rfc-editor.org/info/rfc5129>. 2008, <https://www.rfc-editor.org/info/rfc5129>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
2009, <https://www.rfc-editor.org/info/rfc5462>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811,
DOI 10.17487/RFC6811, January 2013,
<https://www.rfc-editor.org/info/rfc6811>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153, "Special-Purpose IP Address Registries", BCP 153,
RFC 6890, DOI 10.17487/RFC6890, April 2013, RFC 6890, DOI 10.17487/RFC6890, April 2013,
<https://www.rfc-editor.org/info/rfc6890>. <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,
skipping to change at page 43, line 46 skipping to change at page 44, line 36
progress), October 2020. progress), October 2020.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006, RFC 4272, DOI 10.17487/RFC4272, January 2006,
<https://www.rfc-editor.org/info/rfc4272>. <https://www.rfc-editor.org/info/rfc4272>.
[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
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
2009, <https://www.rfc-editor.org/info/rfc5462>.
[RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP Subsequent Address Family Identifier (SAFI) and the BGP
Tunnel Encapsulation Attribute", RFC 5512, Tunnel Encapsulation Attribute", RFC 5512,
DOI 10.17487/RFC5512, April 2009, DOI 10.17487/RFC5512, April 2009,
<https://www.rfc-editor.org/info/rfc5512>. <https://www.rfc-editor.org/info/rfc5512>.
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009,
<https://www.rfc-editor.org/info/rfc5565>. <https://www.rfc-editor.org/info/rfc5565>.
skipping to change at page 44, line 29 skipping to change at page 45, line 15
[RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load- [RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load-
Balancing for Mesh Softwires", RFC 5640, Balancing for Mesh Softwires", RFC 5640,
DOI 10.17487/RFC5640, August 2009, DOI 10.17487/RFC5640, August 2009,
<https://www.rfc-editor.org/info/rfc5640>. <https://www.rfc-editor.org/info/rfc5640>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>. <https://www.rfc-editor.org/info/rfc6514>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811,
DOI 10.17487/RFC6811, January 2013,
<https://www.rfc-editor.org/info/rfc6811>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510, "Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015, DOI 10.17487/RFC7510, April 2015,
<https://www.rfc-editor.org/info/rfc7510>. <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 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address
 End of changes. 144 change blocks. 
307 lines changed or deleted 336 lines changed or added

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