draft-ietf-idr-tunnel-encaps-12.txt   draft-ietf-idr-tunnel-encaps-13.txt 
IDR Working Group K. Patel IDR Working Group K. Patel
Internet-Draft Arrcus, Inc Internet-Draft Arrcus, Inc
Obsoletes: 5512 (if approved) G. Van de Velde Obsoletes: 5512 (if approved) G. Van de Velde
Intended status: Standards Track Nokia Intended status: Standards Track Nokia
Expires: November 21, 2019 S. Sangli Expires: January 23, 2020 S. Sangli
Juniper Networks, Inc Juniper Networks, Inc
E. Rosen E. Rosen
May 20, 2019 July 22, 2019
The BGP Tunnel Encapsulation Attribute The BGP Tunnel Encapsulation Attribute
draft-ietf-idr-tunnel-encaps-12.txt draft-ietf-idr-tunnel-encaps-13.txt
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 4 skipping to change at page 2, line 4
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 November 21, 2019. This Internet-Draft will expire on January 23, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Brief Summary of RFC 5512 . . . . . . . . . . . . . . . . 4 1.1. Brief Summary of RFC 5512 . . . . . . . . . . . . . . . . 4
1.2. Deficiencies in RFC 5512 . . . . . . . . . . . . . . . . 4 1.2. Deficiencies in RFC 5512 . . . . . . . . . . . . . . . . 4
1.3. Brief Summary of Changes from RFC 5512 . . . . . . . . . 5 1.3. Brief Summary of Changes from RFC 5512 . . . . . . . . . 5
1.4. Impact on RFC 5566 . . . . . . . . . . . . . . . . . . . 6 1.4. Impact on RFC 5566 . . . . . . . . . . . . . . . . . . . 6
2. The Tunnel Encapsulation Attribute . . . . . . . . . . . . . 6 2. The Tunnel Encapsulation Attribute . . . . . . . . . . . . . 6
3. Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . . . . . 8 3. Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . . . . . 8
3.1. The Remote Endpoint Sub-TLV . . . . . . . . . . . . . . . 8 3.1. The Tunnel Endpoint Sub-TLV . . . . . . . . . . . . . . . 8
3.2. Encapsulation Sub-TLVs for Particular Tunnel Types . . . 10 3.2. Encapsulation Sub-TLVs for Particular Tunnel Types . . . 10
3.2.1. VXLAN . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. VXLAN . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2. VXLAN-GPE . . . . . . . . . . . . . . . . . . . . . . 12 3.2.2. VXLAN-GPE . . . . . . . . . . . . . . . . . . . . . . 12
3.2.3. NVGRE . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.3. NVGRE . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.4. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.4. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.5. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.5. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.6. MPLS-in-GRE . . . . . . . . . . . . . . . . . . . . . 15 3.2.6. MPLS-in-GRE . . . . . . . . . . . . . . . . . . . . . 15
3.2.7. IP-in-IP . . . . . . . . . . . . . . . . . . . . . . 16 3.2.7. IP-in-IP . . . . . . . . . . . . . . . . . . . . . . 16
3.3. Outer Encapsulation Sub-TLVs . . . . . . . . . . . . . . 16 3.3. Outer Encapsulation Sub-TLVs . . . . . . . . . . . . . . 16
3.3.1. IPv4 DS Field . . . . . . . . . . . . . . . . . . . . 16 3.3.1. IPv4 DS Field . . . . . . . . . . . . . . . . . . . . 16
skipping to change at page 4, line 38 skipping to change at page 4, line 38
o UPDATE U has the address R2 as its NLRI; o UPDATE U has the address R2 as its NLRI;
o UPDATE U has a Tunnel Encapsulation attribute. o UPDATE U has a Tunnel Encapsulation attribute.
o R1 has a packet, P, to transmit to destination D; o R1 has a packet, P, to transmit to destination D;
o R1's best path to D is a BGP route that has R2 as its next hop; o R1's best path to D is a BGP route that has R2 as its next hop;
In this scenario, when R1 transmits packet P, it should transmit it In this scenario, when R1 transmits packet P, it should transmit it
to R2 through one of the tunnels specified in U's Tunnel to R2 through one of the tunnels specified in U's Tunnel
Encapsulation attribute. The IP address of the remote endpoint of Encapsulation attribute. The IP address of the tunnel egress
each such tunnel is R2. Packet P is known as the tunnel's "payload". endpoint of each such tunnel is R2. Packet P is known as the
tunnel's "payload".
1.2. Deficiencies in RFC 5512 1.2. Deficiencies in RFC 5512
While the ability to specify tunnel information in a BGP UPDATE is While the ability to specify tunnel information in a BGP UPDATE is
useful, the procedures of [RFC5512] have certain limitations: useful, the procedures of [RFC5512] have certain limitations:
o The requirement to use the "Encapsulation SAFI" presents an o The requirement to use the "Encapsulation SAFI" presents an
unfortunate operational cost, as each BGP session that may need to unfortunate operational cost, as each BGP session that may need to
carry tunnel encapsulation information needs to be reconfigured to carry tunnel encapsulation information needs to be reconfigured to
support the Encapsulation SAFI. The Encapsulation SAFI has never support the Encapsulation SAFI. The Encapsulation SAFI has never
been used, and this requirement has served only to discourage the been used, and this requirement has served only to discourage the
use of the Tunnel Encapsulation attribute. use of the Tunnel Encapsulation attribute.
o There is no way to use the Tunnel Encapsulation attribute to o There is no way to use the Tunnel Encapsulation attribute to
specify the remote endpoint address of a given tunnel; [RFC5512] specify the tunnel egress endpoint address of a given tunnel;
assumes that the remote endpoint of each tunnel is specified as [RFC5512] assumes that the tunnel egress endpoint of each tunnel
the NLRI of an UPDATE of the Encapsulation-SAFI. is specified as the NLRI of an UPDATE of the Encapsulation-SAFI.
o If the respective best paths to two different address prefixes o If the respective best paths to two different address prefixes
have the same next hop, [RFC5512] does not provide a have the same next hop, [RFC5512] does not provide a
straightforward method to associate each prefix with a different straightforward method to associate each prefix with a different
tunnel. tunnel.
o If a particular tunnel type requires an outer IP or UDP o If a particular tunnel type requires an outer IP or UDP
encapsulation, there is no way to signal the values of any of the encapsulation, there is no way to signal the values of any of the
fields of the outer encapsulation. fields of the outer encapsulation.
o In [RFC5512]'s specification of the sub-TLVs, each sub-TLV has o In [RFC5512]'s specification of the sub-TLVs, each sub-TLV has
one-octet length field. In some cases, a two-octet length field one-octet length field. In some cases, a two-octet length field
may be needed. may be needed.
1.3. Brief Summary of Changes from RFC 5512 1.3. Brief Summary of Changes from RFC 5512
In this document we address these deficiencies by: In this document we address these deficiencies by:
o Deprecating the Encapsulation SAFI. o Deprecating the Encapsulation SAFI.
o Defining a new "Remote Endpoint Address sub-TLV" that can be o Defining a new "Tunnel Endpoint sub-TLV" that can be included in
included in any of the TLVs contained in the Tunnel Encapsulation any of the TLVs contained in the Tunnel Encapsulation attribute.
attribute. This sub-TLV can be used to specify the remote This sub-TLV can be used to specify the remote endpoint address of
endpoint address of a particular tunnel. 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 8, line 17 skipping to change at page 8, line 17
o Sub-TLV Value (variable): encodings of the value field depend on o Sub-TLV Value (variable): encodings of the value field depend on
the sub-TLV type as enumerated above. The following sub-sections the sub-TLV type as enumerated above. The following sub-sections
define the encoding in detail. define the encoding in detail.
3. Tunnel Encapsulation Attribute Sub-TLVs 3. Tunnel Encapsulation Attribute Sub-TLVs
In this section, we specify a number of sub-TLVs. These sub-TLVs can In this section, we specify a number of sub-TLVs. These sub-TLVs can
be included in a TLV of the Tunnel Encapsulation attribute. be included in a TLV of the Tunnel Encapsulation attribute.
3.1. The Remote Endpoint Sub-TLV 3.1. The Tunnel Endpoint Sub-TLV
The Remote Endpoint sub-TLV is a sub-TLV whose value field contains The Tunnel Endpoint sub-TLV specifies the address of the endpoint of
three sub-fields: the tunnel, that is, the address of the router that will decapsulate
the payload. It is a sub-TLV whose value field contains three sub-
fields:
1. a four-octet Autonomous System (AS) number sub-field 1. a four-octet Autonomous System (AS) number sub-field
2. a two-octet Address Family sub-field 2. a two-octet Address Family sub-field
3. an address sub-field, whose length depends upon the Address 3. an address sub-field, whose length depends upon the Address
Family. Family.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Autonomous System Number | | Autonomous System Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Address ~ | Address Family | Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Remote Endpoint Sub-TLV Value Field Figure 2: Tunnel Endpoint Sub-TLV Value Field
The Address Family subfield contains a value from IANA's "Address The Address Family subfield contains a value from IANA's "Address
Family Numbers" registry. In this document, we assume that the Family Numbers" registry. In this document, we assume that the
Address Family is either IPv4 or IPv6; use of other address families Address Family is either IPv4 or IPv6; use of other address families
is outside the scope of this document. is outside the scope of this document.
If the Address Family subfield contains the value for IPv4, the If the Address Family subfield contains the value for IPv4, the
address subfield must contain an IPv4 address (a /32 IPv4 prefix). address subfield must contain an IPv4 address (a /32 IPv4 prefix).
In this case, the length field of Remote Endpoint sub-TLV must In this case, the length field of Tunnel Endpoint sub-TLV must
contain the value 10 (0xa). contain the value 10 (0xa).
If the Address Family subfield contains the value for IPv6, the If the Address Family subfield contains the value for IPv6, the
address sub-field must contain an IPv6 address (a /128 IPv6 prefix). address sub-field must contain an IPv6 address (a /128 IPv6 prefix).
In this case, the length field of Remote Endpoint sub-TLV must In this case, the length field of Tunnel Endpoint sub-TLV must
contain the value 22 (0x16). IPv6 link local addresses are not valid contain the value 22 (0x16). IPv6 link local addresses are not valid
values of the IP address field. values of the IP address field.
In a given BGP UPDATE, the address family (IPv4 or IPv6) of a Remote In a given BGP UPDATE, the address family (IPv4 or IPv6) of a Tunnel
Endpoint sub-TLV is independent of the address family of the UPDATE Endpoint sub-TLV is independent of the address family of the UPDATE
itself. For example, an UPDATE whose NLRI is an IPv4 address may itself. For example, an UPDATE whose NLRI is an IPv4 address may
have a Tunnel Encapsulation attribute containing Remote Endpoint sub- have a Tunnel Encapsulation attribute containing Tunnel Endpoint sub-
TLVs that contain IPv6 addresses. Also, different tunnels TLVs that contain IPv6 addresses. Also, different tunnels
represented in the Tunnel Encapsulation attribute may have Remote represented in the Tunnel Encapsulation attribute may have Tunnel
Endpoints of different address families. Endpoints of different address families.
A two-octet AS number can be carried in the AS number field by A two-octet AS number can be carried in the AS number field by
setting the two high order octets to zero, and carrying the number in setting the two high order octets to zero, and carrying the number in
the two low order octets of the field. the two low order octets of the field.
The AS number in the sub-TLV MUST be the number of the AS to which The AS number in the sub-TLV MUST be the number of the AS to which
the IP address in the sub-TLV belongs. the IP address in the sub-TLV belongs.
There is one special case: the Remote Endpoint sub-TLV MAY have a There is one special case: the Tunnel Endpoint sub-TLV MAY have a
value field whose Address Family subfield contains 0. This means value field whose Address Family subfield contains 0. This means
that the tunnel's remote endpoint is the UPDATE's BGP next hop. If that the tunnel's egress endpoint is the UPDATE's BGP next hop. If
the Address Family subfield contains 0, the Address subfield is the Address Family subfield contains 0, the Address subfield is
omitted, and the Autonomous System number field is set to 0. omitted, and the Autonomous System number field is set to 0.
If any of the following conditions hold, the Remote Endpoint sub-TLV If any of the following conditions hold, the Tunnel Endpoint sub-TLV
is considered to be "malformed": is considered to be "malformed":
o The sub-TLV contains the value for IPv4 in its Address Family o The sub-TLV contains the value for IPv4 in its Address Family
subfield, but the length of the sub-TLV's value field is other subfield, but the length of the sub-TLV's value field is other
than 10 (0xa). than 10 (0xa).
o The sub-TLV contains the value for IPv6 in its Address Family o The sub-TLV contains the value for IPv6 in its Address Family
subfield, but the length of the sub-TLV's value field is other subfield, but the length of the sub-TLV's value field is other
than 22 (0x16). than 22 (0x16).
skipping to change at page 10, line 7 skipping to change at page 10, line 10
the Autonomous System subfield is not set to zero. the Autonomous System subfield is not set to zero.
o The IP address in the sub-TLV's address subfield is not a valid IP o The IP address in the sub-TLV's address subfield is not a valid IP
address (e.g., it's an IPv4 broadcast address). address (e.g., it's an IPv4 broadcast address).
o It can be determined that the IP address in the sub-TLV's address o It can be determined that the IP address in the sub-TLV's address
subfield does not belong to the non-zero AS whose number is in the subfield does not belong to the non-zero AS whose number is in the
its Autonomous System subfield. (See section Section 13 for its Autonomous System subfield. (See section Section 13 for
discussion of one way to determine this.) discussion of one way to determine this.)
If the Remote Endpoint sub-TLV is malformed, the TLV containing it is If the Tunnel Endpoint sub-TLV is malformed, the TLV containing it is
also considered to be malformed, and the entire TLV MUST be ignored. also considered to be malformed, and the entire TLV MUST be ignored.
However, the Tunnel Encapsulation attribute MUST NOT be considered to However, the Tunnel Encapsulation attribute MUST NOT be considered to
be malformed in this case; other TLVs in the attribute MUST be be malformed in this case; other TLVs in the attribute MUST be
processed (if they can be parsed correctly). processed (if they can be parsed correctly).
When redistributing a route that is carrying a Tunnel Encapsulation When redistributing a route that is carrying a Tunnel Encapsulation
attribute containing a TLV that itself contains a malformed Remote attribute containing a TLV that itself contains a malformed Tunnel
Endpoint sub-TLV, the TLV MUST be removed from the attribute before Endpoint sub-TLV, the TLV MUST be removed from the attribute before
redistribution. redistribution.
See Section 11 for further discussion of how to handle errors that See Section 11 for further discussion of how to handle errors that
are encountered when parsing the Tunnel Encapsulation attribute. are encountered when parsing the Tunnel Encapsulation attribute.
If the Remote Endpoint sub-TLV contains an IPv4 or IPv6 address that If the Tunnel Endpoint sub-TLV contains an IPv4 or IPv6 address that
is valid but not reachable, the sub-TLV is NOT considered to be is valid but not reachable, the sub-TLV is NOT considered to be
malformed. malformed.
3.2. Encapsulation Sub-TLVs for Particular Tunnel Types 3.2. Encapsulation Sub-TLVs for Particular Tunnel Types
This section defines Tunnel Encapsulation sub-TLVs for the following This section defines Tunnel Encapsulation sub-TLVs for the following
tunnel types: VXLAN ([RFC7348]), VXLAN-GPE tunnel types: VXLAN ([RFC7348]), VXLAN-GPE
([I-D.ietf-nvo3-vxlan-gpe]), NVGRE ([RFC7637]), MPLS-in-GRE ([I-D.ietf-nvo3-vxlan-gpe]), NVGRE ([RFC7637]), MPLS-in-GRE
([RFC2784], [RFC2890], [RFC4023]), L2TPv3 ([RFC3931]), and GRE ([RFC2784], [RFC2890], [RFC4023]), L2TPv3 ([RFC3931]), and GRE
([RFC2784], [RFC2890], [RFC4023]). ([RFC2784], [RFC2890], [RFC4023]).
Rules for forming the encapsulation based on the information in a Rules for forming the encapsulation based on the information in a
given TLV are given in Sections 5 and 8. given TLV are given in Sections 5 and 8.
There are also tunnel types for which it is not necessary to define There are also tunnel types for which it is not necessary to define
an Encapsulation sub-TLV, because there are no fields in the an Encapsulation sub-TLV, because there are no fields in the
encapsulation header whose values need to be signaled from the remote encapsulation header whose values need to be signaled from the tunnel
endpoint. egress endpoint.
3.2.1. VXLAN 3.2.1. VXLAN
This document defines an encapsulation sub-TLV for VXLAN tunnels. This document defines an encapsulation sub-TLV for VXLAN tunnels.
When the tunnel type is VXLAN, the following is the structure of the When the tunnel type is VXLAN, the following is the structure of the
value field in the encapsulation sub-TLV: value field in the encapsulation sub-TLV:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 20, line 48 skipping to change at page 20, line 48
Index" TLV, an "IPv6 SID (Segment Identifier)" TLV, or an "Originator Index" TLV, an "IPv6 SID (Segment Identifier)" TLV, or an "Originator
SRGB (Source Routing Global Block)" TLV. SRGB (Source Routing Global Block)" TLV.
In this document, we define a Prefix-SID sub-TLV. The value field of In this document, we define a Prefix-SID sub-TLV. The value field of
the Prefix-SID sub-TLV can be set to any valid value of the value the Prefix-SID sub-TLV can be set to any valid value of the value
field of a BGP Prefix-SID attribute, as defined in field of a BGP Prefix-SID attribute, as defined in
[I-D.ietf-idr-bgp-prefix-sid]. [I-D.ietf-idr-bgp-prefix-sid].
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 Remote 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 Remote Endpoint uses to represent the prefix that the tunnel's egress endpoint uses to represent the prefix
appearing in the NLRI field of the BGP UPDATE to which the Tunnel appearing in the NLRI field of the BGP UPDATE to which the Tunnel
Encapsulation attribute is attached. Encapsulation attribute is attached.
If a Label-Index is present in the prefix-SID sub-TLV, then when a If a Label-Index is present in the prefix-SID sub-TLV, then when a
packet is sent through the tunnel identified by the TLV, the packet is sent through the tunnel identified by the TLV, the
corresponding MPLS label MUST be pushed on the packet's label stack. corresponding MPLS label MUST be pushed on the packet's label stack.
The corresponding MPLS label is computed from the Label-Index value The corresponding MPLS label is computed from the Label-Index value
and the SRGB of the route's originator. and the SRGB of the route's originator.
If the Originator SRGB is not present, it is assumed that the If the Originator SRGB is not present, it is assumed that the
skipping to change at page 21, line 32 skipping to change at page 21, line 32
The Prefix-SID sub-TLV has slightly different semantics than the The Prefix-SID sub-TLV has slightly different semantics than the
Prefix-SID attribute. When the Prefix-SID attribute is attached to a Prefix-SID attribute. When the Prefix-SID attribute is attached to a
given route, the BGP speaker that originally attached the attribute given route, the BGP speaker that originally attached the attribute
is expected to be in the same Segment Routing domain as the BGP is expected to be in the same Segment Routing domain as the BGP
speakers who receive the route with the attached attribute. The speakers who receive the route with the attached attribute. The
Label-Index tells the receiving BGP speakers that the prefix-SID is Label-Index tells the receiving BGP speakers that the prefix-SID is
for the advertised prefix in that Segment Routing domain. When the for the advertised prefix in that Segment Routing domain. When the
Prefix-SID sub-TLV is used, the BGP speaker at the head end of the Prefix-SID sub-TLV is used, the BGP speaker at the head end of the
tunnel need even not be in the same Segment Routing Domain as the tunnel need even not be in the same Segment Routing Domain as the
tunnel's Remote Endpoint, and there is no implication that the tunnel's egress endpoint, and there is no implication that the
prefix-SID for the advertised prefix is the same in the Segment prefix-SID for the advertised prefix is the same in the Segment
Routing domains of the BGP speaker that originated the sub-TLV and Routing domains of the BGP speaker that originated the sub-TLV and
the BGP speaker that received it. the BGP speaker that received it.
4. Extended Communities Related to the Tunnel Encapsulation Attribute 4. Extended Communities Related to the Tunnel Encapsulation Attribute
4.1. Encapsulation Extended Community 4.1. Encapsulation Extended Community
The Encapsulation Extended Community is a Transitive Opaque Extended The Encapsulation Extended Community is a Transitive Opaque Extended
Community. This Extended Community may be attached to a route of any Community. This Extended Community may be attached to a route of any
AFI/SAFI to which the Tunnel Encapsulation attribute may be attached. AFI/SAFI to which the Tunnel Encapsulation attribute may be attached.
Each such Extended Community identifies a particular tunnel type. If Each such Extended Community identifies a particular tunnel type. If
the Encapsulation Extended Community identifies a particular tunnel the Encapsulation Extended Community identifies a particular tunnel
type, its semantics are exactly equivalent to the semantics of a type, its semantics are exactly equivalent to the semantics of a
Tunnel Encapsulation attribute Tunnel TLV for which the following Tunnel Encapsulation attribute Tunnel TLV for which the following
three conditions all hold: three conditions all hold:
1. it identifies the same tunnel type, 1. it identifies the same tunnel type,
2. it has a Remote Endpoint sub-TLV for which one of the following 2. it has a Tunnel Endpoint sub-TLV for which one of the following
two conditions holds: two conditions holds:
A. its "Address Family" subfield contains zero, or A. its "Address Family" subfield contains zero, or
B. its "Address" subfield contains the same IP address that B. its "Address" subfield contains the same IP address that
appears in the next hop field of the route to which the appears in the next hop field of the route to which the
Tunnel Encapsulation attribute is attached Tunnel Encapsulation attribute is attached
3. it has no other sub-TLVs. 3. it has no other sub-TLVs.
skipping to change at page 24, line 20 skipping to change at page 24, line 20
additional information about the IP tunnel. The usage of the Tunnel additional information about the IP tunnel. The usage of the Tunnel
Encapsulation attribute in combination with the PMSI Tunnel attribute Encapsulation attribute in combination with the PMSI Tunnel attribute
is outside the scope of this document. is outside the scope of this document.
The decision to attach a Tunnel Encapsulation attribute to a given The decision to attach a Tunnel Encapsulation attribute to a given
BGP UPDATE is determined by policy. The set of TLVs and sub-TLVs BGP UPDATE is determined by policy. The set of TLVs and sub-TLVs
contained in the attribute is also determined by policy. contained in the attribute is also determined by policy.
When the Tunnel Encapsulation attribute is carried in an UPDATE of When the Tunnel Encapsulation attribute is carried in an UPDATE of
one of the AFI/SAFIs specified in the previous paragraph, each TLV one of the AFI/SAFIs specified in the previous paragraph, each TLV
MUST have a Remote Endpoint sub-TLV. If a TLV that does not have a MUST have a Tunnel Endpoint sub-TLV. If a TLV that does not have a
Remote Endpoint sub-TLV, that TLV should be treated as if it had a Tunnel Endpoint sub-TLV, that TLV should be treated as if it had a
malformed Remote Endpoint sub-TLV (see Section 3.1). malformed Tunnel Endpoint sub-TLV (see Section 3.1).
Suppose that: Suppose that:
o a given packet P must be forwarded by router R; o a given packet P must be forwarded by router R;
o the path along which P is to be forwarded is determined by BGP o the path along which P is to be forwarded is determined by BGP
UPDATE U; UPDATE U;
o UPDATE U has a Tunnel Encapsulation attribute, containing at least o UPDATE U has a Tunnel Encapsulation attribute, containing at least
one TLV that identifies a "feasible tunnel" for packet P. A one TLV that identifies a "feasible tunnel" for packet P. A
skipping to change at page 24, line 45 skipping to change at page 24, line 45
* The tunnel type is supported (i.e., router R knows how to set * The tunnel type is supported (i.e., router R knows how to set
up tunnels of that type, how to create the encapsulation header up tunnels of that type, how to create the encapsulation header
for tunnels of that type, etc.) for tunnels of that type, etc.)
* The tunnel is of a type that can be used to carry packet P * The tunnel is of a type that can be used to carry packet P
(e.g., an MPLS-in-UDP tunnel would not be a feasible tunnel for (e.g., an MPLS-in-UDP tunnel would not be a feasible tunnel for
carrying an IP packet, UNLESS the IP packet can first be carrying an IP packet, UNLESS the IP packet can first be
converted to an MPLS packet). converted to an MPLS packet).
* The tunnel is specified in a TLV whose Remote Endpoint sub-TLV * The tunnel is specified in a TLV whose Tunnel Endpoint sub-TLV
identifies an IP address that is reachable. identifies an IP address that is reachable.
Then router R MUST send packet P through one of the feasible tunnels Then router R MUST send packet P through one of the feasible tunnels
identified in the Tunnel Encapsulation attribute of UPDATE U. identified in the Tunnel Encapsulation attribute of UPDATE U.
If the Tunnel Encapsulation attribute contains several TLVs (i.e., if If the Tunnel Encapsulation attribute contains several TLVs (i.e., if
it specifies several tunnels), router R may choose any one of those it specifies several tunnels), router R may choose any one of those
tunnels, based upon local policy. If any tunnel TLV contains one or tunnels, based upon local policy. If any tunnel TLV contains one or
more Color sub-TLVs (Section 3.4.2) and/or the Protocol Type sub-TLV more Color sub-TLVs (Section 3.4.2) and/or the Protocol Type sub-TLV
(Section 3.4.1), the choice of tunnel may be influenced by these sub- (Section 3.4.1), the choice of tunnel may be influenced by these sub-
TLVs. TLVs.
If a particular tunnel is not feasible at some moment because its If a particular tunnel is not feasible at some moment because its
Remote Endpoint cannot be reached at that moment, the tunnel may Tunnel Endpoint cannot be reached at that moment, the tunnel may
become feasible at a later time (when its endpoint becomes become feasible at a later time (when its endpoint becomes
reachable). Router R should take note of this. If router R is reachable). Router R should take note of this. If router R is
already using a different tunnel, it MAY switch to the tunnel that already using a different tunnel, it MAY switch to the tunnel that
just became feasible, or it MAY decide to continue using the tunnel just became feasible, or it MAY decide to continue using the tunnel
that it is already using. How this decision is made is outside the that it is already using. How this decision is made is outside the
scope of this document. scope of this document.
In addition to the sub-TLVs already defined, additional sub-TLVs may In addition to the sub-TLVs already defined, additional sub-TLVs may
be defined that affect the choice of tunnel to be used, or that be defined that affect the choice of tunnel to be used, or that
affect the contents of the tunnel encapsulation header. The affect the contents of the tunnel encapsulation header. The
documents that define any such additional sub-TLVs must specify the documents that define any such additional sub-TLVs must specify the
effect that including the sub-TLV is to have. effect that including the sub-TLV is to have.
Once it is determined to send a packet through the tunnel specified Once it is determined to send a packet through the tunnel specified
in a particular TLV of a particular Tunnel Encapsulation attribute, in a particular TLV of a particular Tunnel Encapsulation attribute,
then the tunnel's remote endpoint address is the IP address contained then the tunnel's egress endpoint address is the IP address contained
in the sub-TLV. If the TLV contains a Remote Endpoint sub-TLV whose in the sub-TLV. If the TLV contains a Tunnel Endpoint sub-TLV whose
value field is all zeroes, then the tunnel's remote endpoint is the value field is all zeroes, then the tunnel's egress endpoint is the
IP address specified as the Next Hop of the BGP Update containing the IP address specified as the Next Hop of the BGP Update containing the
Tunnel Encapsulation attribute. The address of the remote endpoint Tunnel Encapsulation attribute. The address of the tunnel egress
generally appears in a "destination address" field of the endpoint generally appears in a "destination address" field of the
encapsulation. encapsulation.
The full set of procedures for sending a packet through a particular The full set of procedures for sending a packet through a particular
tunnel type to a particular remote endpoint depends upon the tunnel tunnel type to a particular tunnel egress endpoint depends upon the
type, and is outside the scope of this document. Note that some tunnel type, and is outside the scope of this document. Note that
tunnel types may require the execution of an explicit tunnel setup some tunnel types may require the execution of an explicit tunnel
protocol before they can be used for carrying data. Other tunnel setup protocol before they can be used for carrying data. Other
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.
skipping to change at page 26, line 15 skipping to change at page 26, line 15
type. If a tunnel type codepoint is assigned in the IANA "BGP Tunnel type. If a tunnel type codepoint is assigned in the IANA "BGP Tunnel
Encapsulation Tunnel Types" registry, but there is no corresponding Encapsulation Tunnel Types" registry, but there is no corresponding
specification that defines an Encapsulation sub-TLV for that tunnel specification that defines an Encapsulation sub-TLV for that tunnel
type, the transmitting endpoint of such a tunnel is presumed to know type, the transmitting endpoint of such a tunnel is presumed to know
a priori how to form the encapsulation header for that tunnel type. a priori how to form the encapsulation header for that tunnel type.
If a Tunnel Encapsulation attribute specifies several tunnels, the If a Tunnel Encapsulation attribute specifies several tunnels, the
way in which a router chooses which one to use is a matter of policy, way in which a router chooses which one to use is a matter of policy,
subject to the following constraint: if a router can determine that a subject to the following constraint: if a router can determine that a
given tunnel is not functional, it MUST NOT use that tunnel. In given tunnel is not functional, it MUST NOT use that tunnel. In
particular, if the tunnel is identified in a TLV that has a Remote particular, if the tunnel is identified in a TLV that has a Tunnel
Endpoint sub-TLV, and if the IP address specified in the sub-TLV is Endpoint sub-TLV, and if the IP address specified in the sub-TLV is
not reachable from router R, then the tunnel MUST be considered non- not reachable from router R, then the tunnel MUST be considered non-
functional. Other means of determining whether a given tunnel is functional. Other means of determining whether a given tunnel is
functional MAY be used; specification of such means is outside the functional MAY be used; specification of such means is outside the
scope of this specification. Of course, if a non-functional tunnel scope of this specification. Of course, if a non-functional tunnel
later becomes functional, router R SHOULD reevaluate its choice of later becomes functional, router R SHOULD reevaluate its choice of
tunnels. tunnels.
If router R determines that it cannot use any of the tunnels If router R determines that it cannot use any of the tunnels
specified in the Tunnel Encapsulation attribute, it MAY either drop specified in the Tunnel Encapsulation attribute, it MAY either drop
packet P, or it MAY transmit packet P as it would had the Tunnel packet P, or it MAY transmit packet P as it would had the Tunnel
Encapsulation attribute not been present. This is a matter of local Encapsulation attribute not been present. This is a matter of local
policy. By default, the packet SHOULD be transmitted as if the policy. By default, the packet SHOULD be transmitted as if the
Tunnel Encapsulation attribute had not been present. Tunnel Encapsulation attribute had not been present.
A Tunnel Encapsulation attribute may contain several TLVs that all A Tunnel Encapsulation attribute may contain several TLVs that all
specify the same tunnel type. Each TLV should be considered as specify the same tunnel type. Each TLV should be considered as
specifying a different tunnel. Two tunnels of the same type may have specifying a different tunnel. Two tunnels of the same type may have
different Remote Endpoint sub-TLVs, different Encapsulation sub-TLVs, different Tunnel Endpoint sub-TLVs, different Encapsulation sub-TLVs,
etc. Choosing between two such tunnels is a matter of local policy. etc. Choosing between two such tunnels is a matter of local policy.
Once router R has decided to send packet P through a particular Once router R has decided to send packet P through a particular
tunnel, it encapsulates packet P appropriately and then forwards it tunnel, it encapsulates packet P appropriately and then forwards it
according to the route that leads to the tunnel's remote endpoint. according to the route that leads to the tunnel's egress endpoint.
This route may itself be a BGP route with a Tunnel Encapsulation This route may itself be a BGP route with a Tunnel Encapsulation
attribute. If so, the encapsulated packet is treated as the payload attribute. If so, the encapsulated packet is treated as the payload
and is encapsulated according to the Tunnel Encapsulation attribute and is encapsulated according to the Tunnel Encapsulation attribute
of that route. That is, tunnels may be "stacked". of that route. That is, tunnels may be "stacked".
Notwithstanding anything said in this document, a BGP speaker MAY Notwithstanding anything said in this document, a BGP speaker MAY
have local policy that influences the choice of tunnel, and the way have local policy that influences the choice of tunnel, and the way
the encapsulation is formed. A BGP speaker MAY also have a local the encapsulation is formed. A BGP speaker MAY also have a local
policy that tells it to ignore the Tunnel Encapsulation attribute policy that tells it to ignore the Tunnel Encapsulation attribute
entirely or in part. Of course, interoperability issues must be entirely or in part. Of course, interoperability issues must be
considered when such policies are put into place. considered when such policies are put into place.
6. Routing Considerations 6. Routing Considerations
6.1. Impact on BGP Decision Process 6.1. Impact on BGP Decision Process
The presence of the Tunnel Encapsulation attribute affects the BGP The presence of the Tunnel Encapsulation attribute affects the BGP
bestpath selection algorithm. For all the tunnels described in the bestpath selection algorithm. For all the tunnels described in the
Tunnel Encapsulation attribute for a path, if no Remote Tunnel Tunnel Encapsulation attribute for a path, if no Tunnel Endpoint
Endpoint address is feasible, then that path MUST NOT be considered address is feasible, then that path MUST NOT be considered resolvable
resolvable for the purposes of Route Resolvability Condition for the purposes of Route Resolvability Condition [RFC4271] section
[RFC4271] section 9.1.2.1. 9.1.2.1.
6.2. Looping, Infinite Stacking, Etc. 6.2. Looping, Infinite Stacking, Etc.
Consider a packet destined for address X. Suppose a BGP UPDATE for Consider a packet destined for address X. Suppose a BGP UPDATE for
address prefix X carries a Tunnel Encapsulation attribute that address prefix X carries a Tunnel Encapsulation attribute that
specifies a remote tunnel endpoint of Y. And suppose that a BGP specifies a 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 Remote Endpoint of X. It is easy to see that this that specifies a Tunnel Endpoint of X. It is easy to see that this
will cause an infinite number of encapsulation headers to be put on will cause an infinite number of encapsulation headers to be put on
the given packet. the given packet.
This could happen as a result of misconfiguration, either accidental This could happen as a result of misconfiguration, either accidental
or intentional. It could also happen if the Tunnel Encapsulation or intentional. It could also happen if the Tunnel Encapsulation
attribute were altered by a malicious agent. Implementations should attribute were altered by a malicious agent. Implementations should
be aware of this. This document does not specify a maximum number of be aware of this. This document does not specify a maximum number of
recursions; that is an implementation-specific matter. recursions; that is an implementation-specific matter.
Improper setting (or malicious altering) of the Tunnel Encapsulation Improper setting (or malicious altering) of the Tunnel Encapsulation
attribute could also cause data packets to loop. Suppose a BGP attribute could also cause data packets to loop. Suppose a BGP
UPDATE for address prefix X carries a Tunnel Encapsulation attribute UPDATE for address prefix X carries a Tunnel Encapsulation attribute
that specifies a remote tunnel endpoint of Y. Suppose router R that specifies a tunnel egress endpoint of Y. Suppose router R
receives and processes the update. When router R receives a packet receives and processes the update. When router R receives a packet
destined for X, it will apply the encapsulation and send the destined for X, it will apply the encapsulation and send the
encapsulated packet to Y. Y will decapsulate the packet and forward encapsulated packet to Y. Y will decapsulate the packet and forward
it further. If Y is further away from X than is router R, it is it further. If Y is further away from X than is router R, it is
possible that the path from Y to X will traverse R. This would cause possible that the path from Y to X will traverse R. This would cause
a long-lasting routing loop. The control plane itself cannot detect a long-lasting routing loop. The control plane itself cannot detect
this situation, though a TTL field in the payload packets would this situation, though a TTL field in the payload packets would
presumably prevent any given packet from looping infinitely. presumably prevent any given packet from looping infinitely.
These possibilities must also be kept in mind whenever the Remote These possibilities must also be kept in mind whenever the Tunnel
Endpoint for a given prefix differs from the BGP next hop for that Endpoint for a given prefix differs from the BGP next hop for that
prefix. prefix.
7. Recursive Next Hop Resolution 7. Recursive Next Hop Resolution
Suppose that: Suppose that:
o a given packet P must be forwarded by router R1; o a given packet P must be forwarded by router R1;
o the path along which P is to be forwarded is determined by BGP o the path along which P is to be forwarded is determined by BGP
skipping to change at page 31, line 49 skipping to change at page 31, line 49
an MPLS label stack, the embedded label does not appear in that an MPLS label stack, the embedded label does not appear in that
stack. stack.
9. Applicability Restrictions 9. Applicability Restrictions
In a given UPDATE of a labeled address family, the label embedded in In a given UPDATE of a labeled address family, the label embedded in
the NLRI is generally a label that is meaningful only to the router the NLRI is generally a label that is meaningful only to the router
whose address appears as the next hop. Certain of the procedures of whose address appears as the next hop. Certain of the procedures of
Section 8.2.2.1 or Section 8.2.2.2 cause the embedded label to be Section 8.2.2.1 or Section 8.2.2.2 cause the embedded label to be
carried by a data packet to the router whose address appears in the carried by a data packet to the router whose address appears in the
Remote Endpoint sub-TLV. If the Remote Endpoint sub-TLV does not Tunnel Endpoint sub-TLV. If the Tunnel Endpoint sub-TLV does not
identify the same router that is the next hop, sending the packet identify the same router that is the next hop, sending the packet
through the tunnel may cause the label to be misinterpreted at the through the tunnel may cause the label to be misinterpreted at the
tunnel's remote endpoint. This may cause misdelivery of the packet. tunnel's egress endpoint. This may cause misdelivery of the packet.
Therefore the embedded label MUST NOT be carried by a data packet Therefore the embedded label MUST NOT be carried by a data packet
traveling through a tunnel unless it is known that the label will be traveling through a tunnel unless it is known that the label will be
properly interpreted at the tunnel's remote endpoint. How this is properly interpreted at the tunnel's egress endpoint. How this is
known is outside the scope of this document. known is outside the scope of this document.
Note that if the Tunnel Encapsulation attribute is attached to a VPN- Note that if the Tunnel Encapsulation attribute is attached to a VPN-
IP route [RFC4364], and if Inter-AS "option b" (see section 10 of IP route [RFC4364], and if Inter-AS "option b" (see section 10 of
[RFC4364]) is being used, and if the Remote Endpoint sub-TLV contains [RFC4364]) is being used, and if the Tunnel Endpoint sub-TLV contains
an IP address that is not in same AS as the router receiving the an IP address that is not in same AS as the router receiving the
route, it is very likely that the embedded label has been changed. route, it is very likely that the embedded label has been changed.
Therefore use of the Tunnel Encapsulation attribute in an "Inter-AS Therefore use of the Tunnel Encapsulation attribute in an "Inter-AS
option b" scenario is not supported. option b" scenario is not supported.
10. Scoping 10. Scoping
The Tunnel Encapsulation attribute is defined as a transitive The Tunnel Encapsulation attribute is defined as a transitive
attribute, so that it may be passed along by BGP speakers that do not attribute, so that it may be passed along by BGP speakers that do not
recognize it. However, it is intended that the Tunnel Encapsulation recognize it. However, it is intended that the Tunnel Encapsulation
skipping to change at page 33, line 38 skipping to change at page 33, line 38
If the type code of a sub-TLV appears as "reserved" in the IANA "BGP If the type code of a sub-TLV appears as "reserved" in the IANA "BGP
Tunnel Encapsulation Attribute Sub-TLVs" registry, the sub-TLV MUST Tunnel Encapsulation Attribute Sub-TLVs" registry, the sub-TLV MUST
be treated as an unrecognized sub-TLV. be treated as an unrecognized sub-TLV.
In general, if a TLV contains a sub-TLV that is malformed (e.g., In general, if a TLV contains a sub-TLV that is malformed (e.g.,
contains a length field whose value is not legal for that sub-TLV), contains a length field whose value is not legal for that sub-TLV),
the sub-TLV should be treated as if it were an unrecognized sub-TLV. the sub-TLV should be treated as if it were an unrecognized sub-TLV.
This document specifies one exception to this rule -- within a tunnel This document specifies one exception to this rule -- within a tunnel
encapsulation attribute that is carried by a BGP UPDATE whose AFI/ encapsulation attribute that is carried by a BGP UPDATE whose AFI/
SAFI is one of those explicitly listed in the second paragraph of SAFI is one of those explicitly listed in the second paragraph of
Section 5, if a TLV contains a malformed Remote Endpoint sub-TLV (as Section 5, if a TLV contains a malformed Tunnel Endpoint sub-TLV (as
defined in Section 3.1), the entire TLV MUST be ignored, and MUST be defined in Section 3.1), the entire TLV MUST be ignored, and MUST be
removed from the Tunnel Encapsulation attribute before the route removed from the Tunnel Encapsulation attribute before the route
carrying that attribute is redistributed. carrying that attribute is redistributed.
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 5, a TLV that does not contain exactly one paragraph of Section 5, a TLV that does not contain exactly one
Remote Endpoint sub-TLV MUST be treated as if it contained a Tunnel Endpoint sub-TLV MUST be treated as if it contained a
malformed Remote Endpoint sub-TLV. malformed Tunnel Endpoint sub-TLV.
A TLV identifying a particular tunnel type may contain a sub-TLV that A TLV identifying a particular tunnel type may contain a sub-TLV that
is meaningless for that tunnel type. For example, perhaps the TLV is meaningless for that tunnel type. For example, perhaps the TLV
contains a "UDP Destination Port" sub-TLV, but the identified tunnel contains a "UDP Destination Port" sub-TLV, but the identified tunnel
type does not use UDP encapsulation at all. Sub-TLVs of this sort type does not use UDP encapsulation at all. Sub-TLVs of this sort
MUST be treated as a no-op. That is, they MUST NOT affect the MUST be treated as a no-op. That is, they MUST NOT affect the
creation of the encapsulation header. However, the sub-TLV MUST NOT creation of the encapsulation header. However, the sub-TLV MUST NOT
be considered to be malformed, and MUST NOT be removed from the TLV be considered to be malformed, and MUST NOT be removed from the TLV
before the route carrying the Tunnel Encapsulation attribute is before the route carrying the Tunnel Encapsulation attribute is
redistributed. (This allows for the possibility that such sub-TLVs redistributed. (This allows for the possibility that such sub-TLVs
may be given a meaning, in the context of the specified tunnel type, may be given a meaning, in the context of the specified tunnel type,
in the future.) in the future.)
There is no significance to the order in which the TLVs occur within There is no significance to the order in which the TLVs occur within
the Tunnel Encapsulation attribute. Multiple TLVs may occur for a the Tunnel Encapsulation attribute. Multiple TLVs may occur for a
given tunnel type; each such TLV is regarded as describing a given tunnel type; each such TLV is regarded as describing a
different tunnel. different tunnel.
The following sub-TLVs defined in this document MUST NOT occur more The following sub-TLVs defined in this document MUST NOT occur more
than once in a given Tunnel TLV: Remote Endpoint (discussed above), than once in a given Tunnel TLV: Tunnel Endpoint (discussed above),
Encapsulation, IPv4 DS, UDP Destination Port, Embedded Label Encapsulation, IPv4 DS, UDP Destination Port, Embedded Label
Handling, MPLS Label Stack, Prefix-SID. If a Tunnel TLV has more Handling, MPLS Label Stack, Prefix-SID. If a Tunnel TLV has more
than one of any of these sub-TLVs, all but the first occurrence of than one of any of these sub-TLVs, all but the first occurrence of
each such sub-TLV type MUST be treated as a no-op. However, the each such sub-TLV type MUST be treated as a no-op. However, the
Tunnel TLV containing them MUST NOT be considered to be malformed, Tunnel TLV containing them MUST NOT be considered to be malformed,
and all the sub-TLVs MUST be propagated if the route carrying the and all the sub-TLVs MUST be propagated if the route carrying the
Tunnel Encapsulation attribute is propagated. Tunnel Encapsulation attribute is propagated.
The following sub-TLVs defined in this document may appear zero or The following sub-TLVs defined in this document may appear zero or
more times in a given Tunnel TLV: Protocol Type, Color. Each more times in a given Tunnel TLV: Protocol Type, Color. Each
skipping to change at page 35, line 42 skipping to change at page 35, line 42
using the "First Come, First Served" registration procedure. using the "First Come, First Served" registration procedure.
o The values in the range 126-127 and 253-254 are reserved for o The values in the range 126-127 and 253-254 are reserved for
experimental use; IANA shall not allocate values from this range. experimental use; IANA shall not allocate values from this range.
IANA has assigned the following codepoints in the "BGP Tunnel IANA has assigned the following codepoints in the "BGP Tunnel
Encapsulation Attribute Sub-TLVs registry: Encapsulation Attribute Sub-TLVs registry:
6: Remote Endpoint 6: Remote Endpoint
IANA is requested to change the name of "Remote Endpoint" to
"Tunnel Egress Endpoint".
7: IPv4 DS Field 7: IPv4 DS Field
8: UDP Destination Port 8: UDP Destination Port
9: Embedded Label Handling 9: Embedded Label Handling
10: MPLS Label Stack 10: MPLS Label Stack
11: Prefix SID 11: Prefix SID
IANA has previously assigned codepoints from the "BGP Tunnel IANA has previously assigned codepoints from the "BGP Tunnel
Encapsulation Attribute Sub-TLVs" registry for "Encapsulation", Encapsulation Attribute Sub-TLVs" registry for "Encapsulation",
"Protocol Type", and "Color". IANA is requested to add this document "Protocol Type", and "Color". IANA is requested to add this document
as a reference. as a reference.
12.5. Tunnel Types 12.5. Tunnel Types
IANA is requested to add this document as a reference for tunnel IANA is requested to add this document as a reference for tunnel
skipping to change at page 37, line 10 skipping to change at page 37, line 13
registry. registry.
IANA is requested to add this document as a reference for value of 1 IANA is requested to add this document as a reference for value of 1
(Payload of MPLS with embedded label) and 2 (no embedded label in (Payload of MPLS with embedded label) and 2 (no embedded label in
payload) in the "sub-TLV's value field of the Embedded Label Handling payload) in the "sub-TLV's value field of the Embedded Label Handling
sub-TLV" registry. sub-TLV" registry.
13. Security Considerations 13. Security Considerations
The Tunnel Encapsulation attribute can cause traffic to be diverted The Tunnel Encapsulation attribute can cause traffic to be diverted
from its normal path, especially when the Remote Endpoint sub-TLV is from its normal path, especially when the Tunnel Endpoint sub-TLV is
used. This can have serious consequences if the attribute is added used. This can have serious consequences if the attribute is added
or modified illegitimately, as it enables traffic to be "hijacked". or modified illegitimately, as it enables traffic to be "hijacked".
The Remote Endpoint sub-TLV contains both an IP address and an AS The Tunnel Endpoint sub-TLV contains both an IP address and an AS
number. BGP Origin Validation [RFC6811] can be used to obtain number. BGP Origin Validation [RFC6811] can be used to obtain
assurance that the given IP address belongs to the given AS. While assurance that the given IP address belongs to the given AS. While
this provides some protection against misconfiguration, it does not this provides some protection against misconfiguration, it does not
prevent a malicious agent from inserting a sub-TLV that will appear prevent a malicious agent from inserting a sub-TLV that will appear
valid. valid.
Before sending a packet through the tunnel identified in a particular Before sending a packet through the tunnel identified in a particular
TLV of a Tunnel Encapsulation attribute, it may be advisable to use TLV of a Tunnel Encapsulation attribute, it may be advisable to use
BGP Origin Validation to obtain the following additional assurances: BGP Origin Validation to obtain the following additional assurances:
o the origin AS of the route carrying the Tunnel Encapsulation o the origin AS of the route carrying the Tunnel Encapsulation
attribute is correct; attribute is correct;
o the origin AS of the route to the IP address specified in the o the origin AS of the route to the IP address specified in the
Remote Endpoint sub-TLV is correct, and is the same AS that is Tunnel Endpoint sub-TLV is correct, and is the same AS that is
specified in the Remote Endpoint sub-TLV. specified in the Tunnel Endpoint sub-TLV.
One then has some level of assurance that the tunneled traffic is One then has some level of assurance that the tunneled traffic is
going to the same destination AS that it would have gone to had the going to the same destination AS that it would have gone to had the
Tunnel Encapsulation attribute not been present. However, this may Tunnel Encapsulation attribute not been present. However, this may
not suit all use cases, and in any event is not very strong not suit all use cases, and in any event is not very strong
protection against hijacking. protection against hijacking.
For these reasons, BGP Origin Validation should not be relied upon For these reasons, BGP Origin Validation should not be relied upon
exclusively, and the filtering procedures of Section 10 should always exclusively, and the filtering procedures of Section 10 should always
be in place. be in place.
Increased protection can be obtained by using BGPSEC [RFC8205] to Increased protection can be obtained by using BGPSEC [RFC8205] to
ensure that the route carrying the Tunnel Encapsulation attribute, ensure that the route carrying the Tunnel Encapsulation attribute,
and the routes to the Remote Endpoint of each specified tunnel, have and the routes to the Tunnel Endpoint of each specified tunnel, have
not been altered illegitimately. not been altered illegitimately.
If BGP Origin Validation is used as specified above, and the tunnel If BGP Origin Validation is used as specified above, and the tunnel
specified in a particular TLV of a Tunnel Encapsulation attribute is specified in a particular TLV of a Tunnel Encapsulation attribute is
therefore regarded as "suspicious", that tunnel should not be used. therefore regarded as "suspicious", that tunnel should not be used.
Other tunnels specified in (other TLVs of) the Tunnel Encapsulation Other tunnels specified in (other TLVs of) the Tunnel Encapsulation
attribute may still be used. attribute may still be used.
14. Acknowledgments 14. Acknowledgments
This document contains text from RFC5512, co-authored by Pradosh This document contains text from RFC5512, co-authored by Pradosh
Mohapatra. The authors of the current document wish to thank Pradosh Mohapatra. The authors of the current document wish to thank Pradosh
for his contribution. RFC5512 itself built upon prior work by Gargi for his contribution. RFC5512 itself built upon prior work by Gargi
Nalawade, Ruchi Kapoor, Dan Tappan, David Ward, Scott Wainner, Simon Nalawade, Ruchi Kapoor, Dan Tappan, David Ward, Scott Wainner, Simon
Barber, and Chris Metz, whom we also thank for their contributions. Barber, and Chris Metz, whom we also thank for their contributions.
 End of changes. 54 change blocks. 
76 lines changed or deleted 82 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/