draft-ietf-idr-tunnel-encaps-19.txt   draft-ietf-idr-tunnel-encaps-20.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, 5640 (if G. Van de Velde
approved) Nokia approved) Nokia
Intended status: Standards Track S. Sangli Intended status: Standards Track S. Sangli
Expires: March 22, 2021 J. Scudder Expires: May 14, 2021 J. Scudder
Juniper Networks Juniper Networks
September 18, 2020 November 10, 2020
The BGP Tunnel Encapsulation Attribute The BGP Tunnel Encapsulation Attribute
draft-ietf-idr-tunnel-encaps-19 draft-ietf-idr-tunnel-encaps-20
Abstract Abstract
RFC 5512 defines a BGP Path Attribute known as the "Tunnel RFC 5512 defines a BGP Path Attribute known as the "Tunnel
Encapsulation Attribute". This attribute allows one to specify a set Encapsulation Attribute". This attribute allows one to specify a set
of tunnels. For each such tunnel, the attribute can provide the of tunnels. For each such tunnel, the attribute can provide the
information needed to create the tunnel and the corresponding information needed to create the tunnel and the corresponding
encapsulation header. The attribute can also provide information encapsulation header. The attribute can also provide information
that aids in choosing whether a particular packet is to be sent that aids in choosing whether a particular packet is to be sent
through a particular tunnel. RFC 5512 states that the attribute is through a particular tunnel. RFC 5512 states that the attribute is
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 March 22, 2021. This Internet-Draft will expire on May 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 31 skipping to change at page 2, line 31
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
2. The Tunnel Encapsulation Attribute . . . . . . . . . . . . . 7 1.5. Effects of Obsoleting RFCs 5566 and 5640 . . . . . . . . 7
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 . . . . . . . . . . . 9
3.1.1. Validating the Address Field . . . . . . . . . . . . 11 3.1.1. Validating the Address Field . . . . . . . . . . . . 11
3.2. Encapsulation Sub-TLVs for Particular Tunnel Types . . . 12 3.2. Encapsulation Sub-TLVs for Particular Tunnel Types . . . 12
3.2.1. VXLAN . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.1. VXLAN . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.2. VXLAN GPE . . . . . . . . . . . . . . . . . . . . . . 14 3.2.2. NVGRE . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.3. NVGRE . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.3. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.4. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.4. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.5. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2.5. MPLS-in-GRE . . . . . . . . . . . . . . . . . . . . . 17
3.2.6. MPLS-in-GRE . . . . . . . . . . . . . . . . . . . . . 17 3.3. Outer Encapsulation Sub-TLVs . . . . . . . . . . . . . . 17
3.3. Outer Encapsulation Sub-TLVs . . . . . . . . . . . . . . 18
3.3.1. DS Field . . . . . . . . . . . . . . . . . . . . . . 18 3.3.1. DS Field . . . . . . . . . . . . . . . . . . . . . . 18
3.3.2. UDP Destination Port . . . . . . . . . . . . . . . . 18 3.3.2. UDP Destination Port . . . . . . . . . . . . . . . . 18
3.4. Sub-TLVs for Aiding Tunnel Selection . . . . . . . . . . 19 3.4. Sub-TLVs for Aiding Tunnel Selection . . . . . . . . . . 18
3.4.1. Protocol Type Sub-TLV . . . . . . . . . . . . . . . . 19 3.4.1. Protocol Type Sub-TLV . . . . . . . . . . . . . . . . 19
3.4.2. Color Sub-TLV . . . . . . . . . . . . . . . . . . . . 19 3.4.2. Color Sub-TLV . . . . . . . . . . . . . . . . . . . . 19
3.5. Embedded Label Handling Sub-TLV . . . . . . . . . . . . . 20 3.5. Embedded Label Handling Sub-TLV . . . . . . . . . . . . . 20
3.6. MPLS Label Stack Sub-TLV . . . . . . . . . . . . . . . . 21 3.6. MPLS Label Stack Sub-TLV . . . . . . . . . . . . . . . . 21
3.7. Prefix-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 22 3.7. Prefix-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 23
4. Extended Communities Related to the Tunnel Encapsulation 4. Extended Communities Related to the Tunnel Encapsulation
Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1. Encapsulation Extended Community . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . 25
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 . . . . . . . . . . . . . . . . . . . 28 7. Routing Considerations . . . . . . . . . . . . . . . . . . . 29
7.1. Impact on the BGP Decision Process . . . . . . . . . . . 28 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 . . . . . . . . . . . . . . . . 29 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 . . . . . . . . . . . . . . . 30
9.1. Tunnel Types without a Virtual Network Identifier Field . 30 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 . . . . . . . . . . . . . 31
9.2.2. Labeled Address Families . . . . . . . . . . . . . . 32 9.2.2. Labeled Address Families . . . . . . . . . . . . . . 32
10. Applicability Restrictions . . . . . . . . . . . . . . . . . 33 10. Applicability Restrictions . . . . . . . . . . . . . . . . . 33
11. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 11. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
12. Validation and Error Handling . . . . . . . . . . . . . . . . 34 12. Operational Considerations . . . . . . . . . . . . . . . . . 34
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 13. Validation and Error Handling . . . . . . . . . . . . . . . . 35
13.1. Obsoleting Code Points Assigned by RFCs 5566 and 5640 . 36 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
13.2. BGP Tunnel Encapsulation Parameters Grouping . . . . . . 36 14.1. Obsoleting RFC 5512 . . . . . . . . . . . . . . . . . . 36
13.3. Subsequent Address Family Identifiers . . . . . . . . . 36 14.2. Obsoleting Code Points Assigned by RFCs 5566 and 5640 . 36
13.4. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . 36 14.3. BGP Tunnel Encapsulation Parameters Grouping . . . . . . 37
13.5. Flags Field of VXLAN Encapsulation sub-TLV . . . . . . . 37 14.4. Subsequent Address Family Identifiers . . . . . . . . . 37
13.6. Flags Field of VXLAN GPE Encapsulation sub-TLV . . . . . 38 14.5. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . 37
13.7. Flags Field of NVGRE Encapsulation sub-TLV . . . . . . . 38 14.6. Flags Field of VXLAN Encapsulation sub-TLV . . . . . . . 38
13.8. Embedded Label Handling sub-TLV . . . . . . . . . . . . 38 14.7. Flags Field of NVGRE Encapsulation sub-TLV . . . . . . . 38
13.9. Color Extended Community Flags . . . . . . . . . . . . . 39 14.8. Embedded Label Handling sub-TLV . . . . . . . . . . . . 39
14. Security Considerations . . . . . . . . . . . . . . . . . . . 39 14.9. Color Extended Community Flags . . . . . . . . . . . . . 39
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 15. Security Considerations . . . . . . . . . . . . . . . . . . . 39
16. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 40 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 17. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 40
17.1. Normative References . . . . . . . . . . . . . . . . . . 41 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
17.2. Informative References . . . . . . . . . . . . . . . . . 43 18.1. Normative References . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 18.2. Informative References . . . . . . . . . . . . . . . . . 43
Appendix A. Impact on RFC 8365 . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
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] and [RFC5640] rely on RFC 5512,
they are likewise obsoleted. they are likewise obsoleted.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 5, line 23 skipping to change at page 5, line 27
o If the respective best routes to two different address prefixes o If the respective best routes to two different address prefixes
have the same next hop, [RFC5512] does not provide a have the same next hop, [RFC5512] does not provide a
straightforward method to associate each prefix with a different straightforward method to associate each prefix with a different
tunnel. tunnel.
o If a particular Tunnel Type requires an outer IP or UDP o If a particular Tunnel Type requires an outer IP or UDP
encapsulation, there is no way to signal the values of any of the encapsulation, there is no way to signal the values of any of the
fields of the outer encapsulation. fields of the outer encapsulation.
o In [RFC5512]'s specification of the sub-TLVs, each sub-TLV has o In [RFC5512]'s specification of the sub-TLVs, each sub-TLV has
one-octet length field. In some cases, a two-octet length field one-octet length field. In some cases, where a sub-TLV may
may be needed. require more than 255 octets for its encoding, a two-octet length
field may be needed.
1.3. Use Case for The Tunnel Encapsulation Attribute 1.3. Use Case for The Tunnel Encapsulation Attribute
Consider the case of a router R1 forwarding an IP packet P. Let D be Consider the case of a router R1 forwarding an IP packet P. Let D be
P's IP destination address. R1 must look up D in its forwarding P's IP destination address. R1 must look up D in its forwarding
table. Suppose that the "best match" route for D is route Q, where Q table. Suppose that the "best match" route for D is route Q, where Q
is a BGP-distributed route whose "BGP next hop" is router R2. And is a BGP-distributed route whose "BGP next hop" is router R2. And
suppose further that the routers along the path from R1 to R2 have suppose further that the routers along the path from R1 to R2 have
entries for R2 in their forwarding tables, but do NOT have entries entries for R2 in their forwarding tables, but do NOT have entries
for D in their forwarding tables. For example, the path from R1 to for D in their forwarding tables. For example, the path from R1 to
skipping to change at page 6, line 48 skipping to change at page 7, line 4
o Defining the sub-TLV type field so that a sub-TLV whose type is in o Defining the sub-TLV type field so that a sub-TLV whose type is in
the range from 0 to 127 inclusive has a one-octet length field, the range from 0 to 127 inclusive has a one-octet length field,
but a sub-TLV whose type is in the range from 128 to 255 inclusive but a sub-TLV whose type is in the range from 128 to 255 inclusive
has a two-octet length field. has a two-octet length field.
One of the sub-TLVs defined in [RFC5512] is the "Encapsulation sub- One of the sub-TLVs defined in [RFC5512] is the "Encapsulation sub-
TLV". For a given tunnel, the Encapsulation sub-TLV specifies some TLV". For a given tunnel, the Encapsulation sub-TLV specifies some
of the information needed to construct the encapsulation header used of the information needed to construct the encapsulation header used
when sending packets through that tunnel. This document defines when sending packets through that tunnel. This document defines
Encapsulation sub-TLVs for a number of tunnel types not discussed in Encapsulation sub-TLVs for a number of tunnel types not discussed in
[RFC5512]: VXLAN (Virtual Extensible Local Area Network, [RFC7348]), [RFC5512]: VXLAN (Virtual Extensible Local Area Network, [RFC7348]),
VXLAN GPE (Generic Protocol Extension for VXLAN, NVGRE (Network Virtualization Using Generic Routing Encapsulation
[I-D.ietf-nvo3-vxlan-gpe]), NVGRE (Network Virtualization Using [RFC7637]), and MPLS-in-GRE (MPLS in Generic Routing Encapsulation
Generic Routing Encapsulation [RFC7637]), and MPLS-in-GRE (MPLS in [RFC4023]). MPLS-in-UDP [RFC7510] is also supported, but an
Generic Routing Encapsulation [RFC4023]). MPLS-in-UDP [RFC7510] is Encapsulation sub-TLV for it is not needed since there are no
also supported, but an Encapsulation sub-TLV for it is not needed. additional parameters to be signaled.
Some of the encapsulations mentioned in the previous paragraph need Some of the encapsulations mentioned in the previous paragraph need
to be further encapsulated inside UDP and/or IP. [RFC5512] provides to be further encapsulated inside UDP and/or IP. [RFC5512] provides
no way to specify that certain information is to appear in these no way to specify that certain information is to appear in these
outer IP and/or UDP encapsulations. This document provides a outer IP and/or UDP encapsulations. This document provides a
framework for including such information in the TLVs of the Tunnel framework for including such information in the TLVs of the Tunnel
Encapsulation attribute. Encapsulation attribute.
When the Tunnel Encapsulation attribute is attached to a BGP UPDATE When the Tunnel Encapsulation attribute is attached to a BGP UPDATE
whose AFI/SAFI identifies one of the labeled address families, it is whose AFI/SAFI identifies one of the labeled address families, it is
skipping to change at page 7, line 34 skipping to change at page 7, line 39
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
This specification obsoletes RFCs 5566 and 5640. This has the effect
of, in turn, obsoleting a number of code points defined in those
documents. 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) and "Load-Balancing Block" (type code 5)
are obsoleted. See Section 14.2.
Because RFC 8365 depends on RFC 5640, it is similarly obsoleted.
This is further discussed in Appendix A.
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
skipping to change at page 9, line 16 skipping to change at page 9, line 27
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
The Tunnel Egress Endpoint sub-TLV, whose value is 6, specifies the The Tunnel Egress Endpoint sub-TLV, whose type code is 6, specifies
address of the egress endpoint of the tunnel, that is, the address of the address of the egress endpoint of the tunnel, that is, the
the router that will decapsulate the payload. Its value field address of the router that will decapsulate the payload. Its value
contains three subfields: field contains three 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
skipping to change at page 10, line 24 skipping to change at page 10, line 35
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 above, each TLV MUST have message of one of the AFI/SAFIs specified in this document (see the
one, and one only, Tunnel Egress Endpoint sub-TLV. If a TLV does not second paragraph of Section 6), each TLV MUST have one, and one only,
have a Tunnel Egress Endpoint sub-TLV, that TLV should be treated as Tunnel Egress Endpoint sub-TLV. If a TLV does not have a Tunnel
if it had a malformed Tunnel Egress Endpoint sub-TLV (see below). Egress Endpoint sub-TLV, that TLV should be treated as if it had a
malformed Tunnel Egress Endpoint sub-TLV (see below).
If the Address Family subfield has any value other than IPv4 or IPv6, If the Address Family subfield has any value other than IPv4 or IPv6,
the Tunnel Egress Endpoint sub-TLV is considered "unrecognized" (see the Tunnel Egress Endpoint sub-TLV is considered "unrecognized" (see
Section 12). 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 plus the o The length of the sub-TLV's Value field is other than 6 added to
defined length for the address family given in its Address Family the defined length for the address family given in its Address
subfield. Therefore, for address family behaviors defined in this Family subfield. Therefore, for address family behaviors defined
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".)
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 detailed in Section 12. 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 Field
This section details a procedure that MAY be applied to validate that This section provides a procedure that MAY be applied to validate
the IP address in the sub-TLV's address subfield belongs to the AS that the IP address in the sub-TLV's address subfield belongs to the
that originated the route that contains the attribute. (The notion AS that originated the route that contains the attribute. (The
of "belonging to" an AS is expanded on below.) Doing this is thought notion of "belonging to" an AS is expanded on below.) Doing this is
to increase confidence that when traffic is sent to the IP address thought to increase confidence that when traffic is sent to the IP
depicted in the Address Field, it will go to the same AS as it would address depicted in the Address Field, it will go to the same AS as
go to if the Tunnel Encapsulation Attribute were not present, it would go to if the Tunnel Encapsulation Attribute were not
although of course it cannot guarantee it. See Section 14 for present, although of course it cannot guarantee it. See Section 15
discussion of the limitations of this procedure. for discussion of the limitations of this procedure. The principal
applicability of this procedure is in deployments that are not
strictly scoped. In deployments with strict scope, and especially
those scoped to a single AS, these procedures may not add substantial
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 Field 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
skipping to change at page 12, line 12 skipping to change at page 12, line 27
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
This section defines Encapsulation sub-TLVs for the following tunnel This section defines Encapsulation sub-TLVs for the following tunnel
types: VXLAN ([RFC7348]), VXLAN GPE ([I-D.ietf-nvo3-vxlan-gpe]), types: VXLAN ([RFC7348]), NVGRE ([RFC7637]), MPLS-in-GRE ([RFC4023]),
NVGRE ([RFC7637]), MPLS-in-GRE ([RFC4023]), L2TPv3 ([RFC3931]), and L2TPv3 ([RFC3931]), and GRE ([RFC2784]).
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.
skipping to change at page 12, line 45 skipping to change at page 13, line 15
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V|M|R|R|R|R|R|R| VN-ID (3 Octets) | |V|M|R|R|R|R|R|R| VN-ID (3 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (4 Octets) | | MAC Address (4 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (2 Octets) | Reserved | | MAC Address (2 Octets) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: VXLAN Encapsulation Sub-TLV 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
skipping to change at page 14, line 11 skipping to change at page 14, line 28
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. (e.g.,the MAC address) that is used to form this Ethernet header.
3.2.2. VXLAN GPE 3.2.2. NVGRE
This document defines an Encapsulation sub-TLV for VXLAN GPE tunnels.
When the Tunnel Type is VXLAN GPE (value 12), the length of the sub-
TLV is 8 octets and following is the structure of the value field in
the Encapsulation sub-TLV:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|V|R|R|R|R|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VN-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: VXLAN GPE Encapsulation Sub-TLV
Version (Ver): Indicates VXLAN GPE protocol version. (See the
"Version Bits" section of [I-D.ietf-nvo3-vxlan-gpe].) If the
indicated version is not supported, the TLV that contains this
Encapsulation sub-TLV MUST be treated as specifying an unsupported
Tunnel Type. The value of this field will be copied into the
corresponding field of the VXLAN encapsulation header.
V: This bit is set to 1 to indicate that a VN-ID is present in the
Encapsulation sub-TLV. If set to 0, the VN-ID field is
disregarded. Please see Section 9.
R: The bits designated "R" above are reserved for future use.
They MUST always be set to 0 by the originator of the sub-TLV.
Intermediate routers MUST propagate them without modification.
Any receiving routers MUST ignore these bits upon a receipt.
VN-ID: If the V bit is set, this field contains a 3 octet VN-ID
value. If the V bit is not set, this field MUST be set to zero on
transmission and disregarded on receipt.
Reserved (two fields): MUST be set to zero on transmission and
disregarded on receipt.
When forming the VXLAN GPE encapsulation header:
o The values of the V and R bits are NOT copied into the flags field
of the VXLAN GPE header. However, the values of the Ver bits are
copied into the VXLAN GPE header. Other bits in the flags field
of the VXLAN GPE header are set as per [I-D.ietf-nvo3-vxlan-gpe].
o Section 9 describes how the VNI field of the VXLAN GPE
encapsulation header is set.
3.2.3. NVGRE
This document defines an Encapsulation sub-TLV for NVGRE tunnels. This document defines an Encapsulation sub-TLV for NVGRE tunnels.
When the Tunnel Type is NVGRE (value 9), the length of the sub-TLV is When the Tunnel Type is NVGRE (value 9), 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: NVGRE Encapsulation Sub-TLV 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
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 modification. Any receiving routers MUST ignore these bits upon
receipt. 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, used to set the NVGRE VSID (see Section 9). If the V
zero on transmission and disregarded on receipt. bit is not set, the VN-ID field MUST be set to 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 (two fields): MUST be set to zero on transmission and Reserved (two fields): MUST be set to zero on transmission and
disregarded on receipt. disregarded on receipt.
When forming the NVGRE encapsulation header: When forming the NVGRE encapsulation header:
skipping to change at page 16, line 35 skipping to change at page 16, line 5
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.4. L2TPv3 3.2.3. L2TPv3
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 (value 1), 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) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: L2TPv3 Encapsulation Sub-TLV Figure 6: L2TPv3 Encapsulation Sub-TLV Value Field
Session ID: a non-zero 4-octet value locally assigned by the Session ID: a non-zero 4-octet value locally assigned by the
advertising router that serves as a lookup key for the incoming advertising router that serves as a lookup key for the incoming
packet's context. packet's context.
Cookie: an optional, variable length (encoded in octets -- 0 to 8 Cookie: an optional, variable length (encoded in octets -- 0 to 8
octets) value used by L2TPv3 to check the association of a octets) value used by L2TPv3 to check the association of a
received data message with the session identified by the Session received data message with the session identified by the Session
ID. Generation and usage of the cookie value is as specified in ID. Generation and usage of the cookie value is as specified in
[RFC3931]. [RFC3931].
The length of the cookie is not encoded explicitly, but can be The length of the cookie is not encoded explicitly, but can be
calculated as (sub-TLV length - 4). calculated as (sub-TLV length - 4).
3.2.5. GRE 3.2.4. GRE
When the Tunnel Type of the TLV is GRE (value 2), the length of the When the Tunnel Type of the TLV is GRE (value 2), 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 8: 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.6. MPLS-in-GRE 3.2.5. MPLS-in-GRE
When the Tunnel Type is MPLS-in-GRE (value 11), the length of the When the Tunnel Type is MPLS-in-GRE (value 11), 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 9: MPLS-in-GRE Encapsulation Sub-TLV 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
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 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.5 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 While it is not really necessary to have both the GRE and MPLS-in-GRE
tunnel types, both are included for reasons of backwards tunnel types, both are included for reasons of backwards
compatibility. compatibility.
skipping to change at page 18, line 41 skipping to change at page 18, line 12
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 unknown type of sub-TLV.
3.3.1. DS Field 3.3.1. DS Field
Most of the tunnel types that can be specified in the Tunnel Most of the tunnel types that can be specified in the Tunnel
Encapsulation attribute require an outer IP encapsulation. The 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, whose type code is 7, can
be carried in the TLV of any such Tunnel Type. It specifies the be carried in the TLV of any such Tunnel Type. It specifies the
setting of the one-octet Differentiated Services field in the outer setting of the one-octet Differentiated Services field in the outer
IPv4 or IPv6 encapsulation (see [RFC2474]). The value field is IPv4 or IPv6 encapsulation (see [RFC2474]). Any one-octet value can
always a single octet. be transported; the semantics of the DSCP field is beyond the scope
of this document. The value field is always a single octet.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| DS value |
+-+-+-+-+-+-+-+-+
DS Field Sub-TLV Value Field
3.3.2. UDP Destination Port 3.3.2. UDP Destination Port
Some of the tunnel types that can be specified in the Tunnel Some of the tunnel types that can be specified in the Tunnel
Encapsulation attribute require an outer UDP encapsulation. Encapsulation attribute require an outer UDP encapsulation.
Generally there is a standard UDP Destination Port value for a Generally there is a standard UDP Destination Port value for a
particular Tunnel Type. However, sometimes it is useful to be able particular Tunnel Type. However, sometimes it is useful to be able
to use a non-standard UDP destination port. If a particular tunnel to use a non-standard UDP destination port. If a particular tunnel
type requires an outer UDP encapsulation, and it is desired to use a type requires an outer UDP encapsulation, and it is desired to use a
UDP destination port other than the standard one, the port to be used UDP destination port other than the standard one, the port to be used
can be specified by including a UDP Destination Port sub-TLV, whose can be specified by including a UDP Destination Port sub-TLV, whose
type code is 8. The value field of this sub-TLV is always a two- type code is 8. The value field of this sub-TLV is always a two-
octet field, containing the port value. octet field, containing the port value. Any two-octet value other
than zero can be transported. If the reserved value zero is
received, the sub-TLV MUST be treated as malformed according to the
rules of Section 13.
3.4. Sub-TLVs for Aiding Tunnel Selection 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UDP Destination Port Sub-TLV Value Field
3.4. Sub-TLVs for Aiding Tunnel Selection
3.4.1. Protocol Type Sub-TLV 3.4.1. Protocol Type Sub-TLV
The Protocol Type sub-TLV, whose type code is 2, MAY be included in a The Protocol Type sub-TLV, whose type code is 2, MAY be included in a
given TLV to indicate the type of the payload packets that are given TLV to indicate the type of the payload packets that are
allowed to be encapsulated with the tunnel parameters that are being allowed to be encapsulated with the tunnel parameters that are being
signaled in the TLV. Packets with other payload types MUST NOT be signaled in the TLV. Packets with other payload types MUST NOT be
encapsulated in the relevant tunnel. The value field of the sub-TLV encapsulated in the relevant tunnel. The value field of the sub-TLV
contains a 2-octet value from IANA's "ETHER TYPES" registry contains a 2-octet value from IANA's "ETHER TYPES" registry
[Ethertypes]. [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 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
skipping to change at page 19, line 42 skipping to change at page 19, line 44
Note that for tunnel types whose names are of the form "X-in-Y", Note that for tunnel types whose names are of the form "X-in-Y",
e.g., "MPLS-in-GRE", only packets of the specified payload type "X" e.g., "MPLS-in-GRE", only packets of the specified payload type "X"
are to be carried through the tunnel of type "Y". This is the 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 12. Section 13.
3.4.2. Color Sub-TLV 3.4.2. Color Sub-TLV
The Color sub-TLV, whose type code is 4, MAY be used as a way to The Color sub-TLV, whose type code is 4, MAY be used as a way to
"color" the corresponding Tunnel TLV. The value field of the sub-TLV "color" the corresponding Tunnel TLV. The value field of the sub-TLV
is eight octets long, and consists of a Color Extended Community, as is eight octets long, and consists of a Color Extended Community, as
defined in Section 4.3. For the use of this sub-TLV and Extended defined in Section 4.3. For the use of this sub-TLV and Extended
Community, please see Section 8. Community, please see Section 8.
The format of the value field is depicted in Figure 11.
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 12). Section 13).
3.5. Embedded Label Handling Sub-TLV 3.5. Embedded Label Handling Sub-TLV
Certain BGP address families (corresponding to particular AFI/SAFI Certain BGP address families (corresponding to particular AFI/SAFI
pairs, e.g., 1/4, 2/4, 1/128, 2/128) have MPLS labels embedded in pairs, e.g., 1/4, 2/4, 1/128, 2/128) have MPLS labels embedded in
their NLRIs. The term "embedded label" is used to refer to the MPLS their NLRIs. The term "embedded label" is used to refer to the MPLS
label that is embedded in an NLRI, and the term "labeled address label that is embedded in an NLRI, and the term "labeled address
family" to refer to any AFI/SAFI that has embedded labels. family" to refer to any AFI/SAFI that has embedded labels.
Some of the tunnel types (e.g., VXLAN, VXLAN GPE, and NVGRE) that can Some of the tunnel types (e.g., VXLAN and NVGRE) that can be
be specified in the Tunnel Encapsulation attribute have an specified in the Tunnel Encapsulation attribute have an encapsulation
encapsulation header containing a "Virtual Network" identifier of header containing a "Virtual Network" identifier of some sort. The
some sort. The Encapsulation sub-TLVs for these tunnel types may Encapsulation sub-TLVs for these tunnel types may optionally specify
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.
skipping to change at page 21, line 5 skipping to change at page 21, line 9
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
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 or 1 |
+-+-+-+-+-+-+-+-+
Embedded Label Handling Sub-TLV Value Field
3.6. MPLS Label Stack Sub-TLV 3.6. MPLS Label Stack Sub-TLV
This sub-TLV, whose type code is 10, allows an MPLS label stack This sub-TLV, whose type code is 10, allows an MPLS label stack
([RFC3032]) to be associated with a particular tunnel. ([RFC3032]) to be associated 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 10: MPLS Label Stack Sub-TLV Figure 9: 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. packet before any other labels are pushed onto the packet. (See
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
BGP UPDATE of a labeled address family, the contents of the MPLS BGP UPDATE of a labeled address family, the contents of the MPLS
Label Stack sub-TLV MUST be pushed onto the packet before the label Label Stack sub-TLV MUST be pushed onto the packet before the label
embedded in the NLRI is pushed onto the packet. embedded in the NLRI is pushed onto the packet.
If the MPLS Label Stack sub-TLV is included in a TLV identifying a If the MPLS Label Stack sub-TLV is included in a TLV identifying a
Tunnel Type that uses virtual network identifiers (see Section 9), Tunnel Type that uses virtual network identifiers (see Section 9),
the contents of the MPLS Label Stack sub-TLV MUST be pushed onto the the contents of the MPLS Label Stack sub-TLV MUST be pushed onto the
packet before the procedures of Section 9 are applied. packet before the procedures of Section 9 are applied.
skipping to change at page 22, line 31 skipping to change at page 22, line 46
a non-zero value, either 255 or some other value as determined by a non-zero value, either 255 or some other value as determined by
policy as discussed above. policy as discussed above.
Note that this sub-TLV can appear within a TLV identifying any type Note that this sub-TLV can appear within a TLV identifying any type
of tunnel, not just within a TLV identifying an MPLS tunnel. of tunnel, not just within a TLV identifying an MPLS tunnel.
However, if this sub-TLV appears within a TLV identifying an MPLS However, if this sub-TLV appears within a TLV identifying an MPLS
tunnel (or an MPLS-in-X tunnel), this sub-TLV plays the same role tunnel (or an MPLS-in-X tunnel), this sub-TLV plays the same role
that would be played by an MPLS Encapsulation sub-TLV. Therefore, an that would be played by an MPLS Encapsulation sub-TLV. Therefore, an
MPLS Encapsulation sub-TLV is not defined. MPLS Encapsulation sub-TLV is not defined.
Although this specification does not supply detailed instructions for
validating the received label stack, implementations might impose
restrictions on the label stack they can support. If an invalid or
unsupported label stack is received, the tunnel MAY be treated as not
feasible according to the procedures of Section 6.
3.7. Prefix-SID Sub-TLV 3.7. Prefix-SID Sub-TLV
[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, whose type code is 11.
The value field of the Prefix-SID sub-TLV can be set to any permitted The value field of the Prefix-SID sub-TLV can be set to any permitted
value of the value field of a BGP Prefix-SID attribute [RFC8669]. value of the value field of a BGP Prefix-SID attribute [RFC8669].
skipping to change at page 23, line 14 skipping to change at page 23, line 34
The Prefix-SID sub-TLV can occur in a TLV identifying any type of The Prefix-SID sub-TLV can occur in a TLV identifying any type of
tunnel. If an Originator SRGB is specified in the sub-TLV, that SRGB tunnel. If an Originator SRGB is specified in the sub-TLV, that SRGB
MUST be interpreted to be the SRGB used by the tunnel's egress MUST be interpreted to be the SRGB used by the tunnel's egress
endpoint. The Label-Index, if present, is the Segment Routing SID endpoint. The Label-Index, if present, is the Segment Routing SID
that the tunnel's egress endpoint uses to represent the prefix that the tunnel's egress endpoint uses to represent the prefix
appearing in the NLRI field of the BGP UPDATE to which the Tunnel appearing in the NLRI field of the BGP UPDATE to which the Tunnel
Encapsulation attribute is attached. Encapsulation attribute is attached.
If a Label-Index is present in the Prefix-SID sub-TLV, then when a If a Label-Index is present in the Prefix-SID sub-TLV, then when a
packet is sent through the tunnel identified by the TLV, the packet is sent through the tunnel identified by the TLV, if that
corresponding MPLS label MUST be pushed on the packet's label stack. tunnel is from a labeled address family, the corresponding MPLS label
The corresponding MPLS label is computed from the Label-Index value MUST be pushed on the packet's label stack. The corresponding MPLS
and the SRGB of the route's originator, as specified in section 4.1 label is computed from the Label-Index value and the SRGB of the
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 (e.g., a label embedded in
UPDATE's NLRI, or a label determined by the procedures of Section 9, UPDATE's NLRI, or a label determined by the procedures of Section 9,
are pushed on the stack. are pushed on the stack.
The Prefix-SID sub-TLV has slightly different semantics than the The Prefix-SID sub-TLV has slightly different semantics than the
Prefix-SID attribute. When the Prefix-SID attribute is attached to a Prefix-SID attribute. When the Prefix-SID attribute is attached to a
given route, the BGP speaker that originally attached the attribute given route, the BGP speaker that originally attached the attribute
skipping to change at page 24, line 4 skipping to change at page 24, line 19
received it. received it.
4. Extended Communities Related to the Tunnel Encapsulation Attribute 4. Extended Communities Related to the Tunnel Encapsulation Attribute
4.1. Encapsulation Extended Community 4.1. Encapsulation Extended Community
The Encapsulation Extended Community is a Transitive Opaque Extended The Encapsulation Extended Community is a Transitive Opaque Extended
Community. 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 | 0x0c | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Tunnel Type | | Reserved | Tunnel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Encapsulation Extended Community Figure 10: 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
skipping to change at page 24, line 47 skipping to change at page 25, line 15
3. it has no other sub-TLVs. 3. it has no other sub-TLVs.
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. Community. Notwithstanding, an implementation MUST be prepared to
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", e.g., MPLS-in-GRE,
the Encapsulation Extended Community implies that only packets of the the Encapsulation Extended Community implies that only packets of the
specified payload type "X" are to be carried through the tunnel of specified payload type "X" are to be carried through the tunnel of
type "Y". Packets with other payload types MUST NOT be carried type "Y". Packets with other payload types MUST NOT be carried
through such tunnels. See also Section 2. 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
skipping to change at page 25, line 37 skipping to change at page 26, line 13
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 | 0x0b | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color Value | | Color Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Color Extended Community Figure 11: 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 28, line 39 skipping to change at page 29, line 12
and is encapsulated according to the Tunnel Encapsulation attribute and is encapsulated according to the Tunnel Encapsulation attribute
of that route. That is, tunnels may be "stacked". of that route. That is, tunnels may be "stacked".
Notwithstanding anything said in this document, a BGP speaker MAY Notwithstanding anything said in this document, a BGP speaker MAY
have local policy that influences the choice of tunnel, and the way have local policy that influences the choice of tunnel, and the way
the encapsulation is formed. A BGP speaker MAY also have a local the encapsulation is formed. A BGP speaker MAY also have a local
policy that tells it to ignore the Tunnel Encapsulation attribute policy that tells it to ignore the Tunnel Encapsulation attribute
entirely or in part. Of course, interoperability issues must be entirely or in part. Of course, interoperability issues must be
considered when such policies are put into place. considered when such policies are put into place.
See also Section 12, which provides further specification regarding See also Section 13, which provides further specification regarding
validation and exception cases. validation and exception cases.
7. Routing Considerations 7. Routing Considerations
7.1. Impact on the BGP Decision Process 7.1. Impact on the BGP Decision Process
The presence of the Tunnel Encapsulation attribute affects the BGP The presence of the Tunnel Encapsulation attribute affects the BGP
best route selection algorithm. If a route includes the Tunnel best route selection algorithm. If a route includes the Tunnel
Encapsulation attribute, and if that attribute includes no tunnel Encapsulation attribute, and if that attribute includes no tunnel
which is feasible, then that route MUST NOT be considered resolvable which is feasible, then that route MUST NOT be considered resolvable
for the purposes of Route Resolvability Condition [RFC4271] section for the purposes of Route Resolvability Condition [RFC4271]
9.1.2.1. Section 9.1.2.1.
7.2. Looping, Mutual Recursion, Etc. 7.2. Looping, Mutual Recursion, Etc.
Consider a packet destined for address X. Suppose a BGP UPDATE for Consider a packet destined for address X. Suppose a BGP UPDATE for
address prefix X carries a Tunnel Encapsulation attribute that address prefix X carries a Tunnel Encapsulation attribute that
specifies a tunnel egress endpoint of Y, and suppose that a BGP specifies a tunnel egress endpoint of Y, and suppose that a BGP
UPDATE for address prefix Y carries a Tunnel Encapsulation attribute UPDATE for address prefix Y carries a Tunnel Encapsulation attribute
that specifies a tunnel egress endpoint of X. It is easy to see that that specifies a tunnel egress endpoint of X. It is easy to see that
this can have no good outcome. [RFC4271] describes an analogous case this can have no good outcome. [RFC4271] describes an analogous case
as mutually recursive routes. as mutually recursive routes.
skipping to change at page 31, line 9 skipping to change at page 31, line 25
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 Three of the tunnel types that can be specified in a Tunnel
Encapsulation TLV have virtual network identifier fields in their Encapsulation TLV have virtual network identifier fields in their
encapsulation headers. In the VXLAN and VXLAN GPE encapsulations, encapsulation headers. In the VXLAN encapsulation, this field is
this field is called the VNI (Virtual Network Identifier) field; in called the VNI (Virtual Network Identifier) field; in the NVGRE
the NVGRE encapsulation, this field is called the VSID (Virtual encapsulation, this field is called the VSID (Virtual Subnet
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).
This section specifies the procedures for choosing the value to set This section specifies the procedures for choosing the value to set
in the virtual network identifier field of the encapsulation header. in the virtual network identifier field of the encapsulation header.
These procedures apply only when the Tunnel Type is VXLAN, VXLAN GPE, These procedures apply only when the Tunnel Type is VXLAN or NVGRE.
or NVGRE.
9.2.1. Unlabeled Address Families 9.2.1. Unlabeled Address Families
This sub-section applies when: This sub-section applies when:
o the Tunnel Encapsulation attribute is carried in a BGP UPDATE of o the Tunnel Encapsulation attribute is carried in a BGP UPDATE of
an unlabeled address family, and an unlabeled address family, and
o at least one of the attribute's TLVs identifies a Tunnel Type that o at least one of the attribute's TLVs identifies a Tunnel Type that
uses a virtual network identifier, and uses a virtual network identifier, and
skipping to change at page 33, line 38 skipping to change at page 33, line 48
is outside the scope of this document. is outside the scope of this document.
Note that if the Tunnel Encapsulation attribute is attached to a VPN- Note that if the Tunnel Encapsulation attribute is attached to a VPN-
IP route [RFC4364], and if Inter-AS "option b" (see section 10 of IP route [RFC4364], and if Inter-AS "option b" (see section 10 of
[RFC4364]) is being used, and if the Tunnel Egress Endpoint sub-TLV [RFC4364]) is being used, and if the Tunnel Egress Endpoint sub-TLV
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
BGP. For example, [RFC6514] defines the "P-Multicast Service
Interface Tunnel" (PMSI Tunnel) attribute. In this specification, we
do not consider the effects of advertising the Tunnel Encapsulation
Attribute in conjunction with other forms of signaling tunnels. Any
document specifying such joint use should provide details as to how
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, it is intended that the Tunnel Encapsulation
attribute be used only within a well-defined scope, e.g., within a attribute be used only within a well-defined scope, e.g., within a
set of Autonomous Systems that belong to a single administrative set of Autonomous Systems that belong to a single administrative
entity. If the attribute is distributed beyond its intended scope, entity. If the attribute is distributed beyond its intended scope,
packets may be sent through tunnels in a manner that is not intended. packets may be sent through tunnels in a manner that is not intended.
skipping to change at page 34, line 23 skipping to change at page 34, line 41
enabled by default. enabled by default.
Since the Tunnel Encapsulation Extended Community provides a subset Since the Tunnel Encapsulation Extended Community provides a subset
of the functionality of the Tunnel Encapsulation attribute, these of the functionality of the Tunnel Encapsulation attribute, these
considerations apply equally in its case: any BGP speaker that considerations apply equally in its case: any BGP speaker that
understands it MUST be able to filter it from incoming BGP UPDATE understands it MUST be able to filter it from incoming BGP UPDATE
messages, it MUST be possible to filter the Tunnel Encapsulation messages, it MUST be possible to filter the Tunnel Encapsulation
Extended Community from outgoing messages, and in both cases this Extended Community from outgoing messages, and in both cases this
filtering MUST be enabled by default for EBGP sessions. filtering MUST be enabled by default for EBGP sessions.
12. Validation and Error Handling 12. Operational Considerations
A potential operational difficulty arises when tunnels are used, if
the size of packets entering the tunnel exceeds the maximum
transmission unit (MTU) the tunnel is capable of supporting. This
difficulty can be exacerbated by stacking multiple tunnels, since
each stacked tunnel header further reduces the supportable MTU. This
issue is long-standing and well-known. The tunnel signaling provided
in this specification does nothing to address this issue, nor to
aggravate it (except insofar as it may further increase the
popularity of tunnelling).
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.
If a Tunnel Encapsulation attribute does not have any valid TLVs, or If a Tunnel Encapsulation attribute does not have any valid TLVs, or
skipping to change at page 35, line 46 skipping to change at page 36, line 27
contains a UDP Destination Port sub-TLV, but the identified tunnel contains a UDP Destination Port sub-TLV, but the identified tunnel
type does not use UDP encapsulation at all, or a tunnel of the form type does not use UDP encapsulation at all, or a tunnel of the form
"X-in-Y" contains a Protocol Type sub-TLV that specifies something "X-in-Y" contains a Protocol Type sub-TLV that specifies something
other than "X". Sub-TLVs of this sort MUST be disregarded. That is, other than "X". Sub-TLVs of this sort MUST be disregarded. That is,
they MUST NOT affect the creation of the encapsulation header. they MUST NOT affect the creation of the encapsulation header.
However, the sub-TLV MUST NOT be considered to be malformed, and MUST However, the sub-TLV MUST NOT be considered to be malformed, and MUST
NOT be removed from the TLV before the route carrying the Tunnel NOT be removed from the TLV before the route carrying the Tunnel
Encapsulation attribute is distributed. An implementation MAY log a Encapsulation attribute is distributed. An implementation MAY log a
message when it encounters such a sub-TLV. message when it encounters such a sub-TLV.
13. IANA Considerations 14. IANA Considerations
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
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.
13.1. Obsoleting Code Points Assigned by RFCs 5566 and 5640 14.2. Obsoleting Code Points Assigned by RFCs 5566 and 5640
Since this document obsoletes RFCs 5566 and 5640, the code points Since this document obsoletes RFCs 5566 and 5640, the code points
assigned by those RFCs are similarly obsoleted. Specifically, the assigned by those RFCs are similarly obsoleted. Specifically, the
following code points should be marked as deprecated. following code 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 |
+-------+---------------------------------------------+ +-------+---------------------------------------------+
skipping to change at page 36, line 34 skipping to change at page 37, line 23
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 | | 5 | Load-Balancing Block |
+-------+----------------------------+ +-------+----------------------------+
13.2. 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".
13.3. Subsequent Address Family Identifiers 14.4. 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.
13.4. BGP Tunnel Encapsulation Attribute Sub-TLVs 14.5. 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 37, line 34 skipping to change at page 38, line 27
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 |
+-------+-----------------+------------------------+ +-------+-----------------+------------------------+
13.5. Flags Field of VXLAN Encapsulation sub-TLV 14.6. 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 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 (Virtual Network Identifier) | (this document) |
| 1 | M (MAC Address) | (this document) | | 1 | M (MAC Address) | (this document) |
+--------------+--------------------------------+-----------------+ +--------------+--------------------------------+-----------------+
13.6. Flags Field of VXLAN GPE Encapsulation sub-TLV 14.7. Flags Field of NVGRE Encapsulation sub-TLV
Create a registry named "Flags Field of VXLAN GPE Encapsulation sub-
TLV" under the "BGP Tunnel Encapsulation Parameters" grouping. The
registration policy for this registry is "Standards Action".
The initial value for this new registry is indicated below.
+--------------+-------------+-----------------+
| Bit Position | Description | Reference |
+--------------+-------------+-----------------+
| 0 | V (VN-ID) | (this document) |
+--------------+-------------+-----------------+
13.7. 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 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) |
+--------------+-----------------+-----------------+ +--------------+-----------------+-----------------+
13.8. Embedded Label Handling sub-TLV 14.8. 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 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 |
+-------+-------------------------------------+-----------------+ +-------+-------------------------------------+-----------------+
| 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) |
+-------+-------------------------------------+-----------------+ +-------+-------------------------------------+-----------------+
13.9. Color Extended Community Flags 14.9. 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".
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 |
+--------------+-------------+-----------+ +--------------+-------------+-----------+
+--------------+-------------+-----------+ +--------------+-------------+-----------+
14. 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, e.g., within a
set of Autonomous Systems that belong to a single administrative set of Autonomous Systems that belong to a single administrative
entity. As long as the filtering mechanisms discussed in that entity. As long as the filtering mechanisms discussed in that
section are applied diligently, an attacker outside the scope would section are applied diligently, an attacker outside the scope would
not be able to use the Tunnel Encapsulation attribute in an attack. not be able to use the Tunnel Encapsulation attribute in an attack.
This leaves open the questions of attackers within the scope (for This leaves open the questions of attackers within the scope (for
example, a compromised router) and failures in filtering that allow example, a compromised router) and failures in filtering that allow
an external attack to succeed. an external attack to succeed.
skipping to change at page 40, line 8 skipping to change at page 40, line 31
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.
15. 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.
The authors wish to thank Lou Berger, Ron Bonica, Martin Djernaes, The authors wish to thank Lou Berger, Ron Bonica, Martin Djernaes,
John Drake, Satoru Matsushima, Dhananjaya Rao, Ravi Singh, Thomas John Drake, Susan Hares, Satoru Matsushima, Thomas Morin, Dhananjaya
Morin, Xiaohu Xu, and Zhaohui Zhang for their review, comments, and/ Rao, Ravi Singh, Harish Sitaraman, Brian Trammell, Xiaohu Xu, and
or helpful discussions. Alvaro Retana provided an especially Zhaohui Zhang for their review, comments, and/or helpful discussions.
comprehensive review. Alvaro Retana provided an especially comprehensive review.
16. Contributor Addresses 17. Contributor Addresses
Below is a list of other contributing authors in alphabetical order: Below is a list of other contributing authors in alphabetical order:
Randy Bush Randy Bush
Internet Initiative Japan Internet Initiative Japan
5147 Crystal Springs 5147 Crystal Springs
Bainbridge Island, Washington 98110 Bainbridge Island, Washington 98110
United States United States
Email: randy@psg.com Email: randy@psg.com
skipping to change at page 40, line 46 skipping to change at page 41, line 23
Robert Raszuk Robert Raszuk
Bloomberg LP Bloomberg LP
731 Lexington Ave 731 Lexington Ave
New York City, NY 10022 New York City, NY 10022
United States United States
Email: robert@raszuk.net Email: robert@raszuk.net
Eric C. Rosen Eric C. Rosen
17. References 18. References
17.1. Normative References
[I-D.ietf-nvo3-vxlan-gpe] 18.1. Normative References
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
Extension for VXLAN (VXLAN-GPE)", draft-ietf-nvo3-vxlan-
gpe-10 (work in progress), July 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
skipping to change at page 43, line 11 skipping to change at page 43, line 25
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, [RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah,
A., and H. Gredler, "Segment Routing Prefix Segment A., and H. Gredler, "Segment Routing Prefix Segment
Identifier Extensions for BGP", RFC 8669, Identifier Extensions for BGP", RFC 8669,
DOI 10.17487/RFC8669, December 2019, DOI 10.17487/RFC8669, December 2019,
<https://www.rfc-editor.org/info/rfc8669>. <https://www.rfc-editor.org/info/rfc8669>.
17.2. Informative References 18.2. Informative References
[Ethertypes] [Ethertypes]
"IANA Ethertype Registry", "IANA Ethertype Registry",
<http://www.iana.org/assignments/ieee-802-numbers/ieee- <http://www.iana.org/assignments/ieee-802-numbers/ieee-
802-numbers.xhtml>. 802-numbers.xhtml>.
[I-D.ietf-bess-evpn-inter-subnet-forwarding] [I-D.ietf-bess-evpn-inter-subnet-forwarding]
Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. Sajassi, A., Salam, S., Thoria, S., Drake, J., and J.
Rabadan, "Integrated Routing and Bridging in EVPN", draft- Rabadan, "Integrated Routing and Bridging in EVPN", draft-
ietf-bess-evpn-inter-subnet-forwarding-10 (work in ietf-bess-evpn-inter-subnet-forwarding-11 (work in
progress), September 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 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
skipping to change at page 44, line 10 skipping to change at page 44, line 24
[RFC5566] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel [RFC5566] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel
Encapsulation Attribute", RFC 5566, DOI 10.17487/RFC5566, Encapsulation Attribute", RFC 5566, DOI 10.17487/RFC5566,
June 2009, <https://www.rfc-editor.org/info/rfc5566>. June 2009, <https://www.rfc-editor.org/info/rfc5566>.
[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
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811, Austein, "BGP Prefix Origin Validation", RFC 6811,
DOI 10.17487/RFC6811, January 2013, DOI 10.17487/RFC6811, January 2013,
<https://www.rfc-editor.org/info/rfc6811>. <https://www.rfc-editor.org/info/rfc6811>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, [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
Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
<https://www.rfc-editor.org/info/rfc8277>. <https://www.rfc-editor.org/info/rfc8277>.
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
Uttaro, J., and W. Henderickx, "A Network Virtualization
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
DOI 10.17487/RFC8365, March 2018,
<https://www.rfc-editor.org/info/rfc8365>.
Appendix A. Impact on RFC 8365
[RFC8365] references RFC 5512 for its definition of the BGP
Encapsulation Extended Community. That extended community is now
defined in this document, in a way consistent with its previous
definition.
RFC 8365 talks in Section 6 about the use of the Encapsulation
Extended Community to allow Network Virtualization Edge devices
(NVEs) to signal their supported encapsulations. We note that with
the introduction of this specification, the Tunnel Encapsulation
Attribute can also be used for this purpose. For purposes where RFC
8365 talks about "advertising supported encapsulations" (for example,
in the second paragraph of Section 6), encapsulations advertised
using the Tunnel Encapsulation Attribute should be considered equally
with those advertised using the Encapsulation Extended Community.
In particular, a review of Section 8.3.1 of RFC 8365 is called for,
to consider whether the introduction of the Tunnel Encapsulation
Attribute creates a need for any revisions to the split horizon
procedures.
RFC 8365 also refers to a draft version of this specification in the
final paragraph of section 5.1.3. That paragraph references
Section 8.2.2.2 of the draft. In this version of the document the
correct reference would be Section 9.2.2.2. There are no substantive
differences between the section in the referenced draft, and that in
this document.
Authors' Addresses Authors' Addresses
Keyur Patel Keyur Patel
Arrcus, Inc Arrcus, Inc
2077 Gateway Pl 2077 Gateway Pl
San Jose, CA 95110 San Jose, CA 95110
United States United States
Email: keyur@arrcus.com Email: keyur@arrcus.com
 End of changes. 81 change blocks. 
205 lines changed or deleted 272 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/