OSPF Advertisement of Tunnel EncapsulationsCapitalonlinexiaohu.xu@capitalonline.netOrangebruno.decraene@orange.comNTT Network Innovations940 Stewart DrSunnyvaleCA94085United States of Americarobert@raszuk.netTelefonica I+Dluismiguel.contrerasmurillo@telefonica.comVerizonluay.jalil@verizon.comBGPNetworks use tunnels for a variety of reasons. A large variety of
tunnel types are defined, and the tunnel encapsulator router needs to select a
type of tunnel that is supported by the tunnel decapsulator router. This document
defines how to advertise, in OSPF Router Information Link State Advertisements (LSAs),
the list of tunnel encapsulations supported by the tunnel decapsulator.Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
. Introduction
. Terminology
. Tunnel Encapsulations TLV
. Tunnel Sub-TLV
. Tunnel Parameter Sub-TLVs
. Encapsulation Sub-TLV
. Protocol Type Sub-TLV
. Tunnel Egress Endpoint Sub-TLV
. Color Sub-TLV
. Load-Balancing Block Sub-TLV
. DS Field Sub-TLV
. UDP Destination Port Sub-TLV
. Operation
. IANA Considerations
. OSPF Router Information (RI) TLVs Registry
. OSPF Tunnel Parameter Sub-TLVs Registry
. Security Considerations
. References
. Normative References
. Informative References
Acknowledgements
Contributors
Authors' Addresses
IntroductionNetworks use tunnels for a variety of reasons, such as:
Partial deployment of IPv6 in IPv4 networks or IPv4 in IPv6
networks, as described in , where IPvx
tunnels are used between IPvx-enabled routers so as to traverse
non-IPvx routers.
Remote Loop-Free Alternate (RLFA) repair tunnels as described in
, where tunnels are used between the Point
of Local Repair and the selected PQ node.
The tunnel encapsulator router needs to select a type of tunnel that is
supported by the tunnel decapsulator router. This document
defines how to advertise, in OSPF Router Information Link State Advertisements (LSAs),
the list of tunnel encapsulations supported by the tunnel decapsulator.
In this document, OSPF refers to both OSPFv2
and OSPFv3 .TerminologyThis memo makes use of the terms defined in .
The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are
to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.
Tunnel Encapsulations TLVRouters advertise their supported tunnel encapsulation type(s) by
advertising a new TLV of the OSPF Router Information (RI) Opaque LSA
, referred to as the "Tunnel Encapsulations TLV".
This TLV is applicable to both OSPFv2 and OSPFv3.The Type code of the Tunnel Encapsulations TLV is 13, the
Length value is variable, and the Value field contains one or more
Tunnel Sub-TLVs, as defined in .
Each Tunnel Sub-TLV indicates a particular encapsulation
format that the advertising router supports, along with the parameters
corresponding to the tunnel type.The Tunnel Encapsulations TLV MAY appear more than once
within a given OSPF Router Information (RI) Opaque LSA. If the Tunnel
Encapsulations TLV appears more than once in an OSPF Router
Information LSA, the set of all Tunnel Sub-TLVs from all Tunnel
Encapsulations TLVs SHOULD be considered. The scope of
the advertisement depends on the
application, but it is recommended that it SHOULD be
domain wide.Tunnel Sub-TLVThe Tunnel Sub-TLV is structured as shown in .Tunnel Sub-TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Type (2 octets) | Length (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Tunnel Parameter Sub-TLVs |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tunnel Type (2 octets):
Identifies the type of tunneling
technology signaled. Tunnel types are shared with the BGP
extension and hence are
defined in the IANA registry "BGP Tunnel Encapsulation Attribute
Tunnel Types". Unknown tunnel types are to be ignored upon
receipt.
Length (2 octets):
Unsigned 16-bit integer indicating the total
number of octets of the Tunnel Parameter Sub-TLVs field.
Tunnel Parameter Sub-TLVs (variable):
Zero or more Tunnel Parameter
Sub-TLVs, as defined in .
If a Tunnel Sub-TLV is invalid, it MUST be ignored and skipped. However,
other Tunnel Sub-TLVs MUST be considered.Tunnel Parameter Sub-TLVsA Tunnel Parameter Sub-TLV is structured as shown in .Tunnel Parameter Sub-TLV
+---------------------------------------------+
| Tunnel Parameter Sub-Type (2 octets) |
+---------------------------------------------+
| Tunnel Parameter Length (2 octets) |
+---------------------------------------------+
| Tunnel Parameter Value (variable) |
| |
+---------------------------------------------+
Tunnel Parameter Sub-Type (2 octets):
Each sub-type defines a
parameter of the Tunnel Sub-TLV. Sub-types are
registered in the IANA registry "OSPF Tunnel Parameter Sub-TLVs"
(see ).
Tunnel Parameter Length (2 octets):
Unsigned 16-bit integer indicating the
total number of octets of the Tunnel Parameter Value field.
Tunnel Parameter Value (variable):
Encodings of the Value field depend on
the sub-TLV type. The following subsections
define the encoding in detail.
Any unknown Tunnel Parameter sub-type MUST be ignored
and skipped upon receipt. When a reserved
value (see ) is seen in an LSA, it
MUST be treated as an invalid Tunnel Parameter Sub-TLV. When a Tunnel Parameter Value has an incorrect syntax or semantics, it MUST be treated as an invalid Tunnel Parameter Sub-TLV. If a Tunnel Parameter Sub-TLV is invalid, its
Tunnel Sub-TLV MUST be ignored. However,
other Tunnel Sub-TLVs MUST be considered.Encapsulation Sub-TLVThis sub-TLV type is 1. The syntax, semantics, and usage of its
Value field are defined in Section "Encapsulation Sub-TLVs for
Particular Tunnel Types" of .Protocol Type Sub-TLVThis sub-TLV type is 2. The syntax, semantics, and usage of its
Value field are defined in Section "Protocol Type Sub-TLV" of
.Tunnel Egress Endpoint Sub-TLVThe Tunnel Egress Endpoint Sub-TLV specifies the address of the egress endpoint of the tunnel -- that is, the address of the router that will decapsulate the payload.This sub-TLV type is 3. It MUST be present once and only once in a given Tunnel Sub-TLV. The Value field contains two subfields:
a two-octet Address Family subfield
an Address subfield, whose length depends upon the Address Family
Tunnel Egress Endpoint Sub-TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ (variable length) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Address Family subfield contains a value from IANA's "Address
Family Numbers" registry. In this document, we assume that the
Address Family is either IPv4 or IPv6; use of other address families
is outside the scope of this document.If the Address Family subfield contains the value for IPv4, the
Address subfield MUST contain an IPv4 address (a /32 IPv4 prefix).
In this case, the Length field of the Tunnel Egress Endpoint Sub-TLV MUST contain the value 6.If the Address Family subfield contains the value for IPv6, the
address subfield MUST contain an IPv6 address (a /128 IPv6 prefix).
In this case, the Length field of the Tunnel Egress Endpoint Sub-TLV MUST
contain the value 18 (0x12). IPv6 link-local addresses are not valid
values of the IP address field.Color Sub-TLVThis sub-TLV type is 4. It may appear zero or more times in a given
Tunnel Sub-TLV. The Value field is a 4-octet opaque unsigned
integer.The color value is user-defined and configured locally on the
advertising routers. It may be used by service providers to define
policies on the tunnel encapsulator routers, for example, to control the
selection of the tunnel to use.This color value can be referenced by BGP routes carrying the Color
Extended Community . If the
tunnel is used to reach the BGP next hop of BGP routes, then attaching
a Color Extended Community to those routes expresses the
willingness of the BGP speaker to use a tunnel of the same color.Load-Balancing Block Sub-TLVThis sub-TLV type is 5. The syntax, semantics, and usage of its
Value field are defined in .DS Field Sub-TLVThis sub-TLV type is 6. The syntax, semantics, and usage of its
Value field are defined in Section "DS Field"
of .UDP Destination Port Sub-TLVThis sub-TLV type is 7. The syntax, semantics, and usage of its
Value field are defined in Section "UDP Destination Port" of .OperationThe advertisement of a Tunnel Encapsulations Sub-TLV indicates that the advertising router
supports a particular tunnel decapsulation along with the parameters to
be used for the tunnel. The decision to use that tunnel is driven by the
capability of the tunnel encapsulator router to support the encapsulation type and
the policy on the tunnel encapsulator router. The Color Sub-TLV (see ) may be used as an input to this policy. Note that
some tunnel types may require the execution of an explicit tunnel setup
protocol before they can be used to transit data. A tunnel MUST NOT be
used if there is no route toward the IP address specified in the
Tunnel Egress Endpoint Sub-TLV (see ) or if the route is
not advertised in the same OSPF domain.IANA ConsiderationsOSPF Router Information (RI) TLVs RegistryIANA has allocated the following new code point in the
"OSPF Router Information (RI) TLVs" registry.
Addition to OSPF Router Information (RI) TLVs Registry
Value
TLV Name
Reference
13
Tunnel Encapsulations
RFC 9013
OSPF Tunnel Parameter Sub-TLVs RegistryIANA has created a new subregistry called the "OSPF Tunnel
Parameter Sub-TLVs" registry under the "Open Shortest Path
First (OSPF) Parameters" registry. The registration procedures are as follows:
The values in the range 1-34999 are to be allocated using the
"Standards Action" registration procedure defined in .
The values in the range 35000-65499 are to be allocated using the
"First Come First Served" registration procedure.
The initial contents of the registry are as follows:
Initial Contents of OSPF Tunnel Parameter Sub-TLVs Registry
Value
TLV Name
Reference
0
Reserved
RFC 9013
1
Encapsulation
RFC 9013 & RFC 9012
2
Protocol Type
RFC 9013 & RFC 9012
3
Endpoint
RFC 9013
4
Color
RFC 9013
5
Load-Balancing Block
RFC 9013 & RFC 5640
6
DS Field
RFC 9013 & RFC 9012
7
UDP Destination Port
RFC 9013 & RFC 9012
8-65499
Unassigned
65500-65534
Experimental
RFC 9013
65535
Reserved
RFC 9013
Security ConsiderationsSecurity considerations applicable to softwires can be found in the
mesh framework . In general, security issues of
the tunnel protocols signaled through this OSPF capability extension are
inherited.If a third party is able to modify any of the information that is
used to form encapsulation headers, choose a tunnel type, or
choose a particular tunnel for a particular payload type, user data
packets may end up getting misrouted, misdelivered, and/or dropped.
However, since an OSPF routing domain is usually a well-controlled network
under a single administrative domain, the possibility of the above attack is very low.We note that the last paragraph of forbids the establishment of a tunnel toward
arbitrary destinations. It prohibits a destination outside of the OSPF
domain. This prevents a third
party that has gained access to an OSPF router from being able to send
the traffic to other destinations, e.g., for inspection purposes.Security considerations for the base OSPF protocol are covered in
and .ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Load-Balancing for Mesh SoftwiresPayloads transported over a Softwire mesh service (as defined by BGP Encapsulation Subsequent Address Family Identifier (SAFI) information exchange) often carry a number of identifiable, distinct flows. It can, in some circumstances, be desirable to distribute these flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Currently, the payload of a packet entering the Softwire can only be interpreted by the ingress and egress routers. Thus, the load-balancing decision of a core router is only based on the encapsulating header, presenting much less entropy than available in the payload or the encapsulated header since the Softwire encapsulation acts in a tunneling fashion. This document describes a method for achieving comparable load-balancing efficiency in a network carrying Softwire mesh service over Layer Two Tunneling Protocol - Version 3 (L2TPv3) over IP or Generic Routing Encapsulation (GRE) encapsulation to what would be achieved without such encapsulation. [STANDARDS-TRACK]Extensions to OSPF for Advertising Optional Router CapabilitiesIt is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This document proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities. The Router Information (RI) Link State Advertisement (LSA) is defined for this purpose. In OSPFv2, the RI LSA will be implemented with an Opaque LSA type ID. In OSPFv3, the RI LSA will be implemented with a unique LSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). This document obsoletes RFC 4970 by providing a revised specification that includes support for advertisement of multiple instances of the RI LSA and a TLV for functional capabilities.Guidelines for Writing an IANA Considerations Section in RFCsMany protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.This is the third edition of this document; it obsoletes RFC 5226.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.The BGP Tunnel Encapsulation AttributeInformative ReferencesOSPF Version 2This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK]OSPF for IPv6This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3).Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP).Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible.All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6. [STANDARDS-TRACK]The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation AttributeIn certain situations, transporting a packet from one Border Gateway Protocol (BGP) speaker to another (the BGP next hop) requires that the packet be encapsulated by the first BGP speaker and decapsulated by the second. To support these situations, there needs to be some agreement between the two BGP speakers with regard to the "encapsulation information", i.e., the format of the encapsulation header as well as the contents of various fields of the header.The encapsulation information need not be signaled for all encapsulation types. In cases where signaling is required (such as Layer Two Tunneling Protocol - Version 3 (L2TPv3) or Generic Routing Encapsulation (GRE) with key), this document specifies a method by which BGP speakers can signal encapsulation information to each other. The signaling is done by sending BGP updates using the Encapsulation Subsequent Address Family Identifier (SAFI) and the IPv4 or IPv6 Address Family Identifier (AFI). In cases where no encapsulation information needs to be signaled (such as GRE without key), this document specifies a BGP extended community that can be attached to BGP UPDATE messages that carry payload prefixes in order to indicate the encapsulation protocol type to be used. [STANDARDS-TRACK]Softwire Mesh FrameworkThe Internet needs to be able to handle both IPv4 and IPv6 packets. However, it is expected that some constituent networks of the Internet will be "single-protocol" networks. One kind of single-protocol network can parse only IPv4 packets and can process only IPv4 routing information; another kind can parse only IPv6 packets and can process only IPv6 routing information. It is nevertheless required that either kind of single-protocol network be able to provide transit service for the "other" protocol. This is done by passing the "other kind" of routing information from one edge of the single-protocol network to the other, and by tunneling the "other kind" of data packet from one edge to the other. The tunnels are known as "softwires". This framework document explains how the routing information and the data packets of one protocol are passed through a single-protocol network of the other protocol. The document is careful to specify when this can be done with existing technology and when it requires the development of new or modified technology. [STANDARDS-TRACK]Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)This document describes an extension to the basic IP fast reroute mechanism, described in RFC 5286, that provides additional backup connectivity for point-to-point link failures when none can be provided by the basic mechanisms.AcknowledgementsThis document is partially inspired by .The authors would like to thank ,
, , and for their
valuable comments on this
document. Special thanks should be given to for his multiple
detailed reviews of this document and help. The authors would like to
thank , , , , , and
for their Last Call reviews. The authors also thank
, , , , ,
, and for their AD reviews.ContributorsHuaweiuma.chunduri@gmail.comAuthors' AddressesCapitalonlinexiaohu.xu@capitalonline.netOrangebruno.decraene@orange.comNTT Network Innovations940 Stewart DrSunnyvaleCA94085United States of Americarobert@raszuk.netTelefonica I+Dluismiguel.contrerasmurillo@telefonica.comVerizonluay.jalil@verizon.com