draft-ietf-idr-tunnel-encaps-16.txt   draft-ietf-idr-tunnel-encaps-17.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: January 14, 2021 J. Scudder Expires: January 18, 2021 J. Scudder
Juniper Networks Juniper Networks
July 13, 2020 July 17, 2020
The BGP Tunnel Encapsulation Attribute The BGP Tunnel Encapsulation Attribute
draft-ietf-idr-tunnel-encaps-16 draft-ietf-idr-tunnel-encaps-17
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 January 14, 2021. This Internet-Draft will expire on January 18, 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 3, line 8 skipping to change at page 3, line 8
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 . . . . . . . . . . . . . . . . . . . 22
4. Extended Communities Related to the Tunnel Encapsulation 4. Extended Communities Related to the Tunnel Encapsulation
Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1. Encapsulation Extended Community . . . . . . . . . . . . 23 4.1. Encapsulation Extended Community . . . . . . . . . . . . 23
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 . . . . . . . . 25 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, Infinite Stacking, 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. Validation and Error Handling . . . . . . . . . . . . . . . . 34
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
13.1. Subsequent Address Family Identifiers . . . . . . . . . 36 13.1. BGP Tunnel Encapsulation Parameters Grouping . . . . . . 36
13.2. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . 36 13.2. Subsequent Address Family Identifiers . . . . . . . . . 36
13.3. Flags Field of VXLAN Encapsulation sub-TLV . . . . . . . 36 13.3. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . 36
13.4. Flags Field of VXLAN GPE Encapsulation sub-TLV . . . . . 37 13.4. Flags Field of VXLAN Encapsulation sub-TLV . . . . . . . 37
13.5. Flags Field of NVGRE Encapsulation sub-TLV . . . . . . . 37 13.5. Flags Field of VXLAN GPE Encapsulation sub-TLV . . . . . 37
13.6. Embedded Label Handling sub-TLV . . . . . . . . . . . . 37 13.6. Flags Field of NVGRE Encapsulation sub-TLV . . . . . . . 37
13.7. Extended Color Community . . . . . . . . . . . . . . . . 37 13.7. Embedded Label Handling sub-TLV . . . . . . . . . . . . 38
14. Security Considerations . . . . . . . . . . . . . . . . . . . 37 13.8. Color Extended Community . . . . . . . . . . . . . . . . 38
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 13.9. Color Extended Community Flags . . . . . . . . . . . . . 38
16. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 38 14. Security Considerations . . . . . . . . . . . . . . . . . . . 38
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39
17.1. Normative References . . . . . . . . . . . . . . . . . . 39 16. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 40
17.2. Informative References . . . . . . . . . . . . . . . . . 41 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 17.1. Normative References . . . . . . . . . . . . . . . . . . 40
17.2. Informative References . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
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 29 skipping to change at page 5, line 32
o In [RFC5512]'s specification of the sub-TLVs, each sub-TLV has o In [RFC5512]'s specification of the sub-TLVs, each sub-TLV has
one-octet length field. In some cases, a two-octet length field one-octet length field. In some cases, a two-octet length field
may be needed. may be needed.
1.3. Brief Summary of Changes from RFC 5512 1.3. Brief Summary of Changes from RFC 5512
This document addresses these deficiencies by: This document addresses these deficiencies by:
o Deprecating the Encapsulation SAFI. o Deprecating the Encapsulation SAFI.
o Defining a new "Tunnel Egress Endpoint sub-TLV" that can be o Defining a new "Tunnel Egress Endpoint sub-TLV" (Section 3.1) that
included in any of the TLVs contained in the Tunnel Encapsulation can be included in any of the TLVs contained in the Tunnel
attribute. This sub-TLV can be used to specify the remote Encapsulation attribute. This sub-TLV can be used to specify the
endpoint address of a particular tunnel. remote endpoint address of a particular tunnel.
o Allowing the Tunnel Encapsulation attribute to be carried by BGP o Allowing the Tunnel Encapsulation attribute to be carried by BGP
UPDATEs of additional AFI/SAFIs. Appropriate semantics are UPDATEs of additional AFI/SAFIs. Appropriate semantics are
provided for this way of using the attribute. provided for this way of using the attribute.
o Defining a number of new sub-TLVs that provide additional o Defining a number of new sub-TLVs that provide additional
information that is useful when forming the encapsulation header information that is useful when forming the encapsulation header
used to send a packet through a particular tunnel. used to send a packet through a particular tunnel.
o Defining the sub-TLV type field so that a sub-TLV whose type is in o Defining the sub-TLV type field so that a sub-TLV whose type is in
skipping to change at page 6, line 31 skipping to change at page 6, line 35
where), or whether it is to appear in the payload, or whether it can where), or whether it is to appear in the payload, or whether it can
be omitted altogether. This is especially true if the tunnel be omitted altogether. This is especially true if the tunnel
encapsulation header itself contains a "virtual network identifier". encapsulation header itself contains a "virtual network identifier".
This document provides a mechanism that allows one to signal (by This document provides a mechanism that allows one to signal (by
using sub-TLVs of the Tunnel Encapsulation attribute) how one wants using sub-TLVs of the Tunnel Encapsulation attribute) how one wants
to use the embedded label when the tunnel encapsulation has its own to use the embedded label when the tunnel encapsulation has its own
virtual network identifier field. virtual network identifier field.
[RFC5512] defines a Tunnel Encapsulation Extended Community that can [RFC5512] defines a Tunnel Encapsulation Extended Community that can
be used instead of the Tunnel Encapsulation attribute under certain be used instead of the Tunnel Encapsulation attribute under certain
circumstances. This document addresses the issue of how to handle a circumstances. This document describes (Section 4.1) how the Tunnel
BGP UPDATE that carries both a Tunnel Encapsulation attribute and one Encapsulation Extended Community can be used in a backwards-
or more Tunnel Encapsulation Extended Communities. compatible fashion. It is possible to combine Tunnel Encapsulation
Extended Communities and Tunnel Encapsulation attributes in the same
BGP UPDATE in this manner.
1.4. Use Case for The Tunnel Encapsulation Attribute 1.4. 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 8, line 19 skipping to change at page 8, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Value | | Value |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Tunnel Encapsulation TLV Value Field Figure 1: Tunnel Encapsulation TLV Value Field
o Tunnel Type (2 octets): identifies a type of tunnel. The field o Tunnel Type (2 octets): identifies a type of tunnel. The field
contains values from the IANA Registry "BGP Tunnel Encapsulation contains values from the IANA Registry "BGP Tunnel Encapsulation
Attribute Tunnel Types". Attribute Tunnel Types". See Section 3.4.1 for discussion of
special treatment of tunnel types with names 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" are to be carried through the tunnel of type "Y". This is the
equivalent of specifying a Tunnel Type "Y" and including in its
TLV a Protocol Type sub-TLV (see Section 3.4.1) specifying
protocol "X". If the Tunnel Type is "X-in-Y", it is unnecessary,
though harmless, to explicitly include a Protocol Type sub-TLV
specifying "X". Also, for "X-in-Y" type tunnels, a Protocol Type
sub-TLV specifying anything other than "X" MUST be ignored; this
is discussed further in Section 12.
o Length (2 octets): the total number of octets of the value field. o Length (2 octets): the total number of octets of the value field.
o Value (variable): comprised of multiple sub-TLVs. o Value (variable): comprised of multiple sub-TLVs.
Each sub-TLV consists of three fields: a 1-octet type, a 1-octet or Each sub-TLV consists of three fields: a 1-octet type, a 1-octet or
2-octet length field (depending on the type), and zero or more octets 2-octet length field (depending on the type), and zero or more octets
of value. A sub-TLV is structured as shown in Figure 2: of value. A sub-TLV is structured as shown in Figure 2:
+--------------------------------+ +--------------------------------+
skipping to change at page 9, line 26 skipping to change at page 9, line 18
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 specifies the address of the The Tunnel Egress Endpoint sub-TLV specifies the address of the
egress endpoint of the tunnel, that is, the address of the router egress endpoint of the tunnel, that is, the address of the router
that will decapsulate the payload. It is a sub-TLV whose value field that will decapsulate the payload. Its value field contains three
contains three subfields: subfields:
1. a reserved subfield 1. a reserved subfield
2. a two-octet Address Family subfield 2. a two-octet Address Family subfield
3. an Address subfield, whose length depends upon the Address 3. an Address subfield, whose length depends upon the Address
Family. Family.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 10, line 37 skipping to change at page 10, line 29
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 above, each TLV MUST have
one, and one only, Tunnel Egress Endpoint sub-TLV. If a TLV does not one, and one only, Tunnel Egress Endpoint sub-TLV. If a TLV does not
have a Tunnel Egress Endpoint sub-TLV, that TLV should be treated as have a Tunnel Egress Endpoint sub-TLV, that TLV should be treated as
if it had a malformed Tunnel Egress Endpoint sub-TLV (see below). if it had a malformed Tunnel Egress Endpoint sub-TLV (see below).
If any of the following conditions hold, the Tunnel Egress Endpoint If the Address Family subfield has any value other than IPv4 or IPv6,
sub-TLV is considered to be "malformed": the Tunnel Egress Endpoint sub-TLV is considered "unrecognized" (see
Section 12). If any of the following conditions hold, the Tunnel
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 plus the
defined length for the address family given in its Address Family defined length for the address family given in its Address Family
subfield. Therefore, for address family behaviors defined in this subfield. Therefore, for address family behaviors defined in this
document, the permitted values are: 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.
skipping to change at page 11, line 20 skipping to change at page 11, line 11
(Section 3.1.1) that the IP address in the sub-TLV's address (Section 3.1.1) 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. originated the route that contains the attribute.
If the Tunnel Egress Endpoint sub-TLV is malformed, the TLV If the Tunnel Egress Endpoint sub-TLV is malformed, the TLV
containing it is also considered to be malformed. However, the containing it is also considered to be malformed. However, the
Tunnel Encapsulation attribute MUST NOT be considered to be malformed Tunnel Encapsulation attribute MUST NOT be considered to be malformed
in this case; other TLVs in the attribute MUST be processed (if they in this case; other TLVs in the attribute MUST be processed (if they
can be parsed correctly). can be parsed correctly).
Error Handling is detailed in Section 11. Error Handling is detailed in Section 12.
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 details a procedure that MAY be applied to validate that
when traffic is sent to the IP address depicted in the Address Field, when traffic is sent to the IP address depicted in the Address Field,
it will go to the same AS as it would go to if the Tunnel it will go to the same AS as it would go to if the Tunnel
skipping to change at page 12, line 22 skipping to change at page 12, line 13
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]), VXLAN GPE ([I-D.ietf-nvo3-vxlan-gpe]),
NVGRE ([RFC7637]), MPLS-in-GRE ([RFC4023]), L2TPv3 ([RFC3931]), and NVGRE ([RFC7637]), MPLS-in-GRE ([RFC4023]), 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 Sections 5 and 8. 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 13, line 50 skipping to change at page 13, line 39
If the M bit is not set, and the payload being sent through the If the M bit is not set, and the payload being sent through the
VXLAN tunnel is an Ethernet frame, the Destination MAC Address VXLAN tunnel is an Ethernet frame, the Destination MAC Address
field of the Inner Ethernet Header is just the Destination MAC field of the Inner Ethernet Header is just the Destination MAC
Address field of the payload's Ethernet header. Address field of the payload's Ethernet header.
If the M bit is not set, and the payload being sent through the If the M bit is not set, and the payload being sent through the
VXLAN tunnel is an IP or MPLS packet, the Inner Destination MAC VXLAN tunnel is an IP or MPLS packet, the Inner Destination MAC
address field is set to a configured value; if there is no address field is set to a configured value; if there is no
configured value, the VXLAN tunnel cannot be used. configured value, the VXLAN tunnel cannot be used.
o If the V bit is not set, and the BGP UPDATE message has AFI/SAFI
other than Ethernet VPNs (EVPN) then the VXLAN tunnel cannot be
used.
o Section 8 describes how the VNI field of the VXLAN encapsulation o Section 8 describes how the VNI field of the VXLAN encapsulation
header is set. header is set.
Note that in order to send an IP packet or an MPLS packet through a Note that in order to send an IP packet or an MPLS packet through a
VXLAN tunnel, the packet must first be encapsulated in an Ethernet VXLAN tunnel, the packet must first be encapsulated in an Ethernet
header, which becomes the "inner Ethernet header" described in header, which becomes the "inner Ethernet header" described in
[RFC7348]. The VXLAN Encapsulation sub-TLV may contain information [RFC7348]. The VXLAN Encapsulation sub-TLV may contain information
(e.g.,the MAC address) that is used to form this Ethernet header. (e.g.,the MAC address) that is used to form this Ethernet header.
3.2.2. VXLAN GPE 3.2.2. VXLAN GPE
skipping to change at page 16, line 28 skipping to change at page 16, line 23
If the M bit is not set, and the payload being sent through the If the M bit is not set, and the payload being sent through the
NVGRE tunnel is an Ethernet frame, the Destination MAC Address NVGRE tunnel is an Ethernet frame, the Destination MAC Address
field of the Inner Ethernet Header is just the Destination MAC field of the Inner Ethernet Header is just the Destination MAC
Address field of the payload's Ethernet header. Address field of the payload's Ethernet header.
If the M bit is not set, and the payload being sent through the If the M bit is not set, and the payload being sent through the
NVGRE tunnel is an IP or MPLS packet, the Inner Destination MAC NVGRE tunnel is an IP or MPLS packet, the Inner Destination MAC
address field is set to a configured value; if there is no address field is set to a configured value; if there is no
configured value, the NVGRE tunnel cannot be used. configured value, the NVGRE tunnel cannot be used.
o If the V bit is not set, and the BGP UPDATE message has AFI/SAFI
other than Ethernet VPNs (EVPN) then the NVGRE tunnel cannot be
used.
o Section 8 describes how the VSID (Virtual Subnet Identifier) field o Section 8 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.4. 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 8 octets. The following is the structure of length of the sub-TLV is between 4 and 12 octets, depending on the
the value field of the Encapsulation sub-TLV: length of the cookie. The following is the structure of the value
field of the Encapsulation sub-TLV:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID (4 octets) | | Session ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Cookie (Variable) | | Cookie (Variable) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 19, line 31 skipping to change at page 19, line 31
the egress router will include three TLVs of L2TPv3 encapsulation the egress router will include three TLVs of L2TPv3 encapsulation
type, each specifying a different Session ID and a different payload type, each specifying a different Session ID and a different payload
type. The Protocol Type sub-TLV for these will be IPv4 (protocol type. The Protocol Type sub-TLV for these will be IPv4 (protocol
type = 0x0800), IPv6 (protocol type = 0x86dd), and MPLS (protocol type = 0x0800), IPv6 (protocol type = 0x86dd), and MPLS (protocol
type = 0x8847), respectively. This informs the ingress routers of type = 0x8847), respectively. This informs the ingress routers of
the appropriate encapsulation information to use with each of the the appropriate encapsulation information to use with each of the
given protocol types. Insertion of the specified Session ID at the given protocol types. Insertion of the specified Session ID at the
ingress routers allows the egress to process the incoming packets ingress routers allows the egress to process the incoming packets
correctly, according to their protocol type. correctly, according to their protocol type.
Note that it is unnecessary to explicitly include this sub-TLV in Note that for tunnel types whose names are of the form "X-in-Y",
tunnels whose names are of the form "X-in-Y", as discussed in e.g., "MPLS-in-GRE", only packets of the specified payload type "X"
Section 2. are to be carried through the tunnel of type "Y". This is the
equivalent of specifying a Tunnel Type "Y" and including in its TLV a
Protocol Type sub-TLV (see Section 3.4.1) specifying protocol "X".
If the Tunnel Type is "X-in-Y", it is unnecessary, though harmless,
to explicitly include a Protocol Type sub-TLV specifying "X". Also,
for "X-in-Y" type tunnels, a Protocol Type sub-TLV specifying
anything other than "X" MUST be ignored; this is discussed further in
Section 12.
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 7. Community, please see Section 7.
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
should be treated as if it were an unrecognized sub-TLV (see should be treated as if it were an unrecognized sub-TLV (see
Section 11). Section 12).
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, VXLAN GPE, and NVGRE) that can
skipping to change at page 25, line 16 skipping to change at page 25, line 16
In the remainder of this specification, when a route is referred to In the remainder of this specification, when a route is referred to
as containing a Tunnel Encapsulation attribute with a TLV identifying as containing a Tunnel Encapsulation attribute with a TLV identifying
a particular Tunnel Type, it implicitly includes the case where the a particular Tunnel Type, it implicitly includes the case where the
route contains a Tunnel Encapsulation Extended Community identifying route contains a Tunnel Encapsulation Extended Community identifying
that Tunnel Type. that Tunnel Type.
4.2. Router's MAC Extended Community 4.2. Router's MAC Extended Community
[I-D.ietf-bess-evpn-inter-subnet-forwarding] defines a Router's MAC [I-D.ietf-bess-evpn-inter-subnet-forwarding] defines a Router's MAC
Extended Community. This Extended Community provides information Extended Community. This Extended Community, as its name implies,
that may conflict with information in one or more of the carries the MAC address of the advertising router. Since the VXLAN
Encapsulation Sub-TLVs of a Tunnel Encapsulation attribute. In case and NVGRE Encapsulation Sub-TLVs can also optionally carry a router's
of such a conflict, the information in the Encapsulation Sub-TLV MAC, a conflict can arise if both the Router's MAC Extended Community
takes precedence. and such an Encapsulation Sub-TLV are present at the same time but
have different values. In case of such a conflict, the information
in the Encapsulation Sub-TLV MUST be used.
4.3. Color Extended Community 4.3. Color Extended Community
The Color Extended Community is a Transitive Opaque Extended The Color Extended Community is a Transitive Opaque Extended
Community with the following encoding: Community with the following encoding:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x03 | 0x0b | Reserved | | 0x03 | 0x0b | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color Value | | Color Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Color Extended Community Figure 12: 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. The two octet Reserved value is user defined and configured locally. No flags are defined
field MUST be set to zero by the sender and ignored by the receiver. in this document; this field MUST be set to zero by the originator
The Color Value field is encoded as 4 octet value by the and ignored by the receiver; the value MUST NOT be changed when
administrator and is outside the scope of this document. For the use propagating this Extended Community. The Color Value field is
of this Extended Community please see Section 7. encoded as 4 octet value by the administrator and is outside the
scope of this document. For the use of this Extended Community
please see Section 7.
5. Special Considerations for IP-in-IP Tunnels 5. Special Considerations for IP-in-IP Tunnels
In certain situations with an IP fabric underlay, one could have a In certain situations with an IP fabric underlay, one could have a
tunnel overlay with the tunnel type IP-in-IP. The egress BGP speaker tunnel overlay with the tunnel type IP-in-IP. The egress BGP speaker
can advertise the IP-in-IP tunnel endpoint address in the Tunnel can advertise the IP-in-IP tunnel endpoint address in the Tunnel
Egress Endpoint sub-TLV. When the Tunnel type of the TLV is IP-in- Egress Endpoint sub-TLV. When the Tunnel type of the TLV is IP-in-
IP, it will not have a Virtual Network Identifier. However, the IP, it will not have a Virtual Network Identifier. However, the
tunnel egress endpoint address can be used in identifying the tunnel egress endpoint address can be used in identifying the
forwarding table to use for making the forwarding decisions to forwarding table to use for making the forwarding decisions to
skipping to change at page 27, line 51 skipping to change at page 28, line 9
The full set of procedures for sending a packet through a particular The full set of procedures for sending a packet through a particular
Tunnel Type to a particular tunnel egress endpoint depends upon the Tunnel Type to a particular tunnel egress endpoint depends upon the
tunnel type, and is outside the scope of this document. Note that tunnel type, and is outside the scope of this document. Note that
some tunnel types may require the execution of an explicit tunnel some tunnel types may require the execution of an explicit tunnel
setup protocol before they can be used for carrying data. Other setup protocol before they can be used for carrying data. Other
tunnel types may not require any tunnel setup protocol. tunnel types may not require any tunnel setup protocol.
Sending a packet through a tunnel always requires that the packet be Sending a packet through a tunnel always requires that the packet be
encapsulated, with an encapsulation header that is appropriate for encapsulated, with an encapsulation header that is appropriate for
the Tunnel Type. The contents of the tunnel encapsulation header MAY the Tunnel Type. The contents of the tunnel encapsulation header may
be influenced by the Encapsulation sub-TLV. If there is no be influenced by the Encapsulation sub-TLV. If there is no
Encapsulation sub-TLV present, the router transmitting the packet Encapsulation sub-TLV present, the router transmitting the packet
through the tunnel must have a priori knowledge (e.g., by through the tunnel must have a priori knowledge (e.g., by
provisioning) of how to fill in the various fields in the provisioning) of how to fill in the various fields in the
encapsulation header. encapsulation header.
Whenever a new Tunnel Type is defined, the specification of that TLV
should describe (or reference) the procedures for creating the
encapsulation header used to forward packets through that tunnel
type. The Tunnel Type codepoint will be assigned in the IANA "BGP
Tunnel Encapsulation Tunnel Types" registry.
If a Tunnel Encapsulation attribute specifies several tunnels, the If a Tunnel Encapsulation attribute specifies several tunnels, the
way in which a router chooses which one to use is a matter of policy, way in which a router chooses which one to use is a matter of policy,
In addition to the reachability to the address of the egress endpoint In addition to the reachability to the address of the egress endpoint
of the tunnel, other policy factors MAY be used to determine the of the tunnel, other policy factors MAY be used to determine the
feasibility of the tunnel. The policy factors are beyond the scope feasibility of the tunnel. The policy factors are beyond the scope
of this document. of this document.
A Tunnel Encapsulation attribute may contain several TLVs that all A Tunnel Encapsulation attribute may contain several TLVs that all
specify the same Tunnel Type. Each TLV should be considered as specify the same Tunnel Type. Each TLV should be considered as
specifying a different tunnel. Two tunnels of the same type may have specifying a different tunnel. Two tunnels of the same type may have
skipping to change at page 28, line 45 skipping to change at page 28, line 45
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
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] section
9.1.2.1. 9.1.2.1.
7.2. Looping, Infinite Stacking, 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 will cause an infinite number of encapsulation headers to be put this can have no good outcome. [RFC4271] describes an analogous case
on the given packet. [RFC4271] describes an analogous case as as mutually recursive routes.
mutually recursive routes.
This could happen as a result of misconfiguration, either accidental This could happen as a result of misconfiguration, either accidental
or intentional. It could also happen if the Tunnel Encapsulation or intentional. It could also happen if the Tunnel Encapsulation
attribute were altered by a malicious agent. Implementations should attribute were altered by a malicious agent. Implementations should
be aware that such an attack will result in unresolvable BGP routes be aware that such an attack will result in unresolvable BGP routes
due to the mutually recursive relationship. This document does not due to the mutually recursive relationship. This document does not
specify a maximum number of recursions; that is an implementation- specify a maximum number of recursions; that is an implementation-
specific matter. specific matter.
Improper setting (or malicious altering) of the Tunnel Encapsulation Improper setting (or malicious altering) of the Tunnel Encapsulation
skipping to change at page 33, line 40 skipping to change at page 33, line 52
This may cause misdelivery of the packet. Avoidance of this This may cause misdelivery of the packet. Avoidance of this
unfortunate outcome is a matter of network planning and design, and unfortunate outcome is a matter of network planning and design, and
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 supported. "Inter-AS option b" scenario is not recommended.
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 28 skipping to change at page 34, line 38
EBGP session, filtering of the attribute on outgoing UPDATEs MUST be EBGP session, filtering of the attribute on outgoing UPDATEs MUST be
enabled by default. enabled by default.
12. Validation and Error Handling 12. Validation and Error Handling
The Tunnel Encapsulation attribute is a sequence of TLVs, each of The Tunnel Encapsulation attribute is a sequence of TLVs, each of
which is a sequence of sub-TLVs. The final octet of a TLV is which is a sequence of sub-TLVs. The final octet of a TLV is
determined by its length field. Similarly, the final octet of a sub- determined by its length field. Similarly, the final octet of a sub-
TLV is determined by its length field. The final octet of a TLV MUST TLV is determined by its length field. The final octet of a TLV MUST
also be the final octet of its final sub-TLV. If this is not the also be the final octet of its final sub-TLV. If this is not the
case, the TLV MUST be considered to be malformed. A TLV that is case, the TLV MUST be considered to be malformed, and the "Treat-as-
found to be malformed for this reason MUST NOT be processed, and MUST withdraw" procedure of [RFC7606] is applied.
be stripped from the Tunnel Encapsulation attribute. In this case,
the "Treat-as-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
it does not have the transitive bit set, the "Treat-as-withdraw" it does not have the transitive bit set, the "Treat-as-withdraw"
procedure of [RFC7606] is applied. procedure of [RFC7606] is applied.
If a Tunnel Encapsulation attribute can be parsed correctly, but If a Tunnel Encapsulation attribute can be parsed correctly, but
contains a TLV whose Tunnel Type is not recognized by a particular contains a TLV whose Tunnel Type is not recognized by a particular
BGP speaker, that BGP speaker MUST NOT consider the attribute to be BGP speaker, that BGP speaker MUST NOT consider the attribute to be
malformed. Rather, it MUST interpret the attribute as if that TLV malformed. Rather, it MUST interpret the attribute as if that TLV
had not been present. If the route carrying the Tunnel Encapsulation had not been present. If the route carrying the Tunnel Encapsulation
skipping to change at page 35, line 20 skipping to change at page 35, line 28
sub-TLV may appear multiple times to assign multiple colors to a sub-TLV may appear multiple times to assign multiple colors to a
tunnel. tunnel.
If a TLV of a Tunnel Encapsulation attribute contains a sub-TLV that If a TLV of a Tunnel Encapsulation attribute contains a sub-TLV that
is not recognized by a particular BGP speaker, the BGP speaker MUST is not recognized by a particular BGP speaker, the BGP speaker MUST
process that TLV as if the unrecognized sub-TLV had not been present. process that TLV as if the unrecognized sub-TLV had not been present.
If the route carrying the Tunnel Encapsulation attribute is If the route carrying the Tunnel Encapsulation attribute is
propagated with the attribute, the unrecognized sub-TLV MUST remain propagated with the attribute, the unrecognized sub-TLV MUST remain
in the attribute. in the attribute.
In general, if a TLV contains a sub-TLV that is malformed (e.g., In general, if a TLV contains a sub-TLV that is malformed, the sub-
contains a length field whose value is not legal for that sub-TLV), TLV MUST be treated as if it were an unrecognized sub-TLV. This
the sub-TLV should be treated as if it were an unrecognized sub-TLV. document specifies one exception to this rule -- if a TLV contains a
This document specifies one exception to this rule -- if a TLV malformed Tunnel Egress Endpoint sub-TLV (as defined in Section 3.1),
contains a malformed Tunnel Egress Endpoint sub-TLV (as defined in the entire TLV MUST be ignored, and MUST be removed from the Tunnel
Section 3.1), the entire TLV MUST be ignored, and MUST be removed Encapsulation attribute before the route carrying that attribute is
from the Tunnel Encapsulation attribute before the route carrying distributed.
that attribute is distributed.
Within a Tunnel Encapsulation attribute that is carried by a BGP Within a Tunnel Encapsulation attribute that is carried by a BGP
UPDATE whose AFI/SAFI is one of those explicitly listed in the second UPDATE whose AFI/SAFI is one of those explicitly listed in the second
paragraph of Section 6, a TLV that does not contain exactly one paragraph of Section 6, a TLV that does not contain exactly one
Tunnel Egress Endpoint sub-TLV MUST be treated as if it contained a Tunnel Egress Endpoint sub-TLV MUST be treated as if it contained a
malformed Tunnel Egress Endpoint sub-TLV. malformed Tunnel Egress Endpoint sub-TLV.
A TLV identifying a particular Tunnel Type may contain a sub-TLV that A TLV identifying a particular Tunnel Type may contain a sub-TLV that
is meaningless for that Tunnel Type. For example, perhaps the TLV is meaningless for that Tunnel Type. For example, perhaps the TLV
contains a UDP Destination Port sub-TLV, but the identified tunnel contains a UDP Destination Port sub-TLV, but the identified tunnel
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 13. IANA Considerations
13.1. Subsequent Address Family Identifiers
IANA is requested to modify the "Subsequent Address Family This document makes the following requests of IANA. (All
Identifiers" registry to indicate that the Encapsulation SAFI (value registration procedures listed below are per their definitions in
7) is obsoleted. This document should be the reference. [RFC8126].)
Because this document obsoletes RFC 5512, IANA is asked to change all 13.1. BGP Tunnel Encapsulation Parameters Grouping
registration information that references [RFC5512] to instead
reference this document.
13.2. BGP Tunnel Encapsulation Attribute Sub-TLVs Create a new registry grouping, to be named "BGP Tunnel Encapsulation
Parameters".
IANA is requested to add the following note to the "BGP Tunnel 13.2. Subsequent Address Family Identifiers
Encapsulation Attribute Sub-TLVs" registry:
Modify the "Subsequent Address Family Identifiers" registry to
indicate that the Encapsulation SAFI (value 7) is obsoleted. This
document should be the reference.
Because this document obsoletes RFC 5512, change all registration
information that references [RFC5512] to instead reference this
document.
13.3. BGP Tunnel Encapsulation Attribute Sub-TLVs
Relocate the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry
to be under the "BGP Tunnel Encapsulation Parameters" grouping.
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.
IANA is requested to change the registration policy of the "BGP Change the registration policy of the registry to the following:
Tunnel Encapsulation Attribute Sub-TLVs" registry to the following:
o The values 0 and 255 are reserved. +----------+-------------------------+
| Value(s) | Registration Procedure |
+----------+-------------------------+
| 0 | Reserved |
| 1-63 | Standards Action |
| 64-125 | First Come First Served |
| 126-127 | Experimental Use |
| 128-191 | Standards Action |
| 192-252 | First Come First Served |
| 253-254 | Experimental Use |
| 255 | Reserved |
+----------+-------------------------+
o The values in the range 1-63 and 128-191 are to be allocated using Rename the following entries within the registry:
the "Standards Action" registration procedure.
o The values in the range 64-125 and 192-252 are to be allocated +-------+-----------------+------------------------+
using the "First Come First Served" registration procedure. | Value | Old Name | New Name |
+-------+-----------------+------------------------+
| 6 | Remote Endpoint | Tunnel Egress Endpoint |
| 7 | IPv4 DS Field | DS Field |
+-------+-----------------+------------------------+
o The values in the range 126-127 and 253-254 are reserved for 13.4. Flags Field of VXLAN Encapsulation sub-TLV
experimental use; IANA shall not allocate values from this range.
IANA has assigned the following codepoints in the "BGP Tunnel Create a registry named "Flags Field of VXLAN Encapsulation sub-TLV"
Encapsulation Attribute Sub-TLVs registry": under the "BGP Tunnel Encapsulation Parameters" grouping. The
registration policy for this registry is "Standards Action".
Value 6: Remote Endpoint (note: IANA please rename to "Tunnel The initial values for this new registry are indicated below.
Egress Endpoint")
Value 7: IPv4 DS Field (note: IANA please rename to "DS Field") +--------------+--------------------------------+-----------------+
| Bit Position | Description | Reference |
+--------------+--------------------------------+-----------------+
| 0 | V (Virtual Network Identifier) | (this document) |
| 1 | M (MAC Address) | (this document) |
+--------------+--------------------------------+-----------------+
13.3. Flags Field of VXLAN Encapsulation sub-TLV 13.5. Flags Field of VXLAN GPE Encapsulation sub-TLV
IANA is requested to add this document as a reference for creating Create a registry named "Flags Field of VXLAN GPE Encapsulation sub-
the flags field of the VXLAN Encapsulation sub-TLV registry. TLV" under the "BGP Tunnel Encapsulation Parameters" grouping. The
registration policy for this registry is "Standards Action".
IANA is requested to add this document as a reference for flag bits V The initial value for this new registry is indicated below.
and M in the "Flags field of VXLAN Encapsulation sub-TLV" registry.
13.4. Flags Field of VXLAN GPE Encapsulation sub-TLV +--------------+-------------+-----------------+
| Bit Position | Description | Reference |
+--------------+-------------+-----------------+
| 0 | V (VN-ID) | (this document) |
+--------------+-------------+-----------------+
IANA is requested to add this document as a reference for creating 13.6. Flags Field of NVGRE Encapsulation sub-TLV
the flags field of the VXLAN GPE Encapsulation sub-TLV registry.
IANA is requested to add this document as a reference for flag bit V Create a registry named "Flags Field of NVGRE Encapsulation sub-TLV"
in the "Flags field of VXLAN GPE Encapsulation sub-TLV" registry. under the "BGP Tunnel Encapsulation Parameters" grouping. The
registration policy for this registry is "Standards Action".
13.5. Flags Field of NVGRE Encapsulation sub-TLV The initial values for this new registry are indicated below.
IANA is requested to add this document as a reference for creating +--------------+-----------------+-----------------+
the flags field of the NVGRE Encapsulation sub-TLV registry. | Bit Position | Description | Reference |
+--------------+-----------------+-----------------+
| 0 | V (VN-ID) | (this document) |
| 1 | M (MAC Address) | (this document) |
+--------------+-----------------+-----------------+
IANA is requested to add this document as a reference for flag bits V 13.7. Embedded Label Handling sub-TLV
and M in the "Flags field of NVGRE Encapsulation sub-TLV" registry.
13.6. Embedded Label Handling sub-TLV Create a registry named "Embedded Label Handling sub-TLV" under the
"BGP Tunnel Encapsulation Parameters" grouping. The registration
policy for this registry is "Standards Action".
IANA is requested to add this document as a reference for creating The initial values for this new registry are indicated below.
the sub-TLV's value field of the Embedded Label Handling sub-TLV
registry.
IANA is requested to add this document as a reference for value of 1 +-------+-------------------------------------+-----------------+
(Payload of MPLS with embedded label) and 2 (no embedded label in | Value | Description | Reference |
payload) in the "sub-TLV's value field of the Embedded Label Handling +-------+-------------------------------------+-----------------+
sub-TLV" registry. | 1 | Payload of MPLS with embedded label | (this document) |
| 2 | no embedded label in payload | (this document) |
+-------+-------------------------------------+-----------------+
13.7. Extended Color Community 13.8. Color Extended Community
IANA is requested to add this document as a reference for the "Color Add this document as a reference for the "Color Extended Community"
Extended Community" entry in the Transitive Opaque Extended Community entry in the Transitive Opaque Extended Community Sub-Types registry.
Sub-Types registry.
13.9. Color Extended Community Flags
Create a registry named "Color Extended Community Flags" under the
"BGP Tunnel Encapsulation Parameters" grouping. The registration
policy for this registry is "Standards Action".
No initial values are to be registered. The format of the registry
is shown below.
+--------------+-------------+-----------+
| Bit Position | Description | Reference |
+--------------+-------------+-----------+
+--------------+-------------+-----------+
14. Security Considerations 14. 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
skipping to change at page 41, line 22 skipping to change at page 42, line 22
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages", Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015, RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>. <https://www.rfc-editor.org/info/rfc7606>.
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
Virtualization Using Generic Routing Encapsulation", Virtualization Using Generic Routing Encapsulation",
RFC 7637, DOI 10.17487/RFC7637, September 2015, RFC 7637, DOI 10.17487/RFC7637, September 2015,
<https://www.rfc-editor.org/info/rfc7637>. <https://www.rfc-editor.org/info/rfc7637>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
 End of changes. 60 change blocks. 
143 lines changed or deleted 208 lines changed or added

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