Internet Engineering Task Force (IETF) P. Psenak, Ed. Request for Comments: 8510 K. Talaulikar Category: Standards Track Cisco Systems, Inc. ISSN: 2070-1721 W. Henderickx Nokia P. Pillay-Esnault Huawei USA January 2019
OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement
Abstract
Every OSPF interface is assigned an Interface ID that uniquely identifies the interface on the router. In some cases, it is useful to know the assigned Interface ID on the remote side of the adjacency (Remote Interface ID).
This document describes the extensions to OSPF link-local signaling (LLS) to advertise the Local Interface ID.
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 https://www.rfc-editor.org/info/rfc8510.
Psenak, et al. Standards Track [Page 1]
RFC 8510 OSPF LLS Extensions for Interface ID January 2019
Copyright Notice
Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) 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
1. Introduction ....................................................3 1.1. Interface ID Exchange Using Link Local TE Opaque LSA .......4 1.2. Requirements Language ......................................4 2. Interface ID Exchange Using OSPF LLS ............................4 2.1. Local Interface ID TLV .....................................5 3. Backward Compatibility with RFC 4203 ............................5 4. IANA Considerations .............................................6 5. Security Considerations .........................................6 6. References ......................................................6 6.1. Normative References .......................................6 6.2. Informative References .....................................7 Acknowledgments ....................................................8 Authors' Addresses .................................................8
Psenak, et al. Standards Track [Page 2]
RFC 8510 OSPF LLS Extensions for Interface ID January 2019
Every OSPF interface is assigned an Interface ID that uniquely identifies the interface on the router. [RFC2328] uses this Interface ID in the Router Link State Advertisement (Router-LSA) Link Data for unnumbered links and uses the value of the MIB-II ifIndex [RFC2863]. [RFC4203] refers to these Interface IDs as the Link Local/Remote Identifiers and defines a way to advertise and use them for GMPLS purposes. [RFC8379] defines a way to advertise Local/ Remote Interface IDs in the OSPFv2 Extended Link Opaque LSA.
There is a known OSPFv2 protocol problem in verifying the bidirectional connectivity with parallel unnumbered links. If there are two parallel unnumbered links between a pair of routers and each link is only advertised from a single direction, such two unidirectional parallel links could be considered as a valid single bidirectional link during the OSPF route computation on some other router. If each link is advertised with both its Local and Remote Interface IDs, the advertisement of each link from both sides of adjacency can be verified by cross-checking the Local and Remote Interface IDs of both advertisements.
From the perspective of the advertising router, the Local Interface ID is a known value. However, the Remote Interface ID needs to be learned before it can be advertised. [RFC4203] suggests using the TE Link Local LSA [RFC3630] to communicate the Local Interface ID to neighbors on the link. Though such a mechanism works, it has some drawbacks.
This document proposes an extension to OSPF link-local signaling (LLS) [RFC5613] to advertise the Local Interface ID.
Psenak, et al. Standards Track [Page 3]
RFC 8510 OSPF LLS Extensions for Interface ID January 2019
1.1. Interface ID Exchange Using Link Local TE Opaque LSA
Usage of the Link Local TE Opaque LSA to propagate the Local Interface ID to the neighbors on the link is described in [RFC4203]. This mechanism has the following problems:
o LSAs can only be flooded over an existing adjacency that is in Exchange state or greater. The adjacency state machine progresses independently on each side of the adjacency and, as such, may reach the Full state on one side before the Link Local TE Opaque LSA arrives. The consequence of this is that the link can be initially advertised without the Remote Interface ID. Later, when the Link Local TE Opaque LSA arrives, the link must be advertised again but this time with the valid Remote Interface ID. Implementations may choose to wait before advertising the link, but there is no guarantee that the neighbor will ever advertise the Link Local TE Opaque LSA with the Interface ID. In summary, the existing mechanism does not guarantee that the Remote Interface ID is known at the time the link is advertised.
o The Link Local TE Opaque LSA is defined for MPLS Traffic Engineering, but the knowledge of the Remote Interface ID is useful also for cases where MPLS TE is not used. One example is the mentioned lack of a valid 2-way connectivity check for parallel point-to-point links between OSPF routers.
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
To address the problems described earlier and to allow the Interface ID exchange to be part of the neighbor discovery process, we propose to extend OSPF link-local signaling to advertise the Local Interface ID in OSPF Hello and Database Description (DD) packets.
Psenak, et al. Standards Track [Page 4]
RFC 8510 OSPF LLS Extensions for Interface ID January 2019
If the Local Interface ID signaling via the Link Local TE Opaque LSA is supported in addition to the new LLS mechanism, implementations that support Local Interface ID signaling using LLS MUST prefer the Local Interface ID value received through LLS over the value received through the Link Local TE Opaque LSA if both are received from the same OSPF router.
Implementations that support Local Interface ID signaling via the Link Local TE Opaque LSA MAY continue to do so to ensure backward compatibility. If they also support Local Interface ID signaling using LLS as described in the document, they MUST signal the same Local Interface ID via both mechanisms.
During the rare conditions in which the Local Interface ID changes, a timing interval may exist where the received values of the Local Interface ID advertised through LLS and the Link Local TE Opaque LSA may differ. Such a situation is temporary, and received values via both mechanisms should become equal as soon as the next Hello and/or Link Local TE Opaque LSA is regenerated by the originator.
Psenak, et al. Standards Track [Page 5]
RFC 8510 OSPF LLS Extensions for Interface ID January 2019
IANA has allocated the following code point in the "Link Local Signalling TLV Identifiers (LLS Types)" subregistry of the "Open Shortest Path First (OSPF) Link Local Signalling (LLS) - Type/Length/ Value Identifiers (TLV)" registry.
The security considerations for "OSPF Link-Local Signaling" [RFC5613] also apply to the Local Interface ID TLV described in this document. The current usage of a neighbor's Local Interface ID is to disambiguate parallel links between OSPF routers. Hence, modification of the advertised Local Interface ID TLV may result in the wrong neighbor Interface ID being advertised in the OSPFv2 Extended Link Opaque LSA [RFC7684] and could prevent the link from being used. If authentication is being used in the OSPF routing domain [RFC5709][RFC7474], then the Cryptographic Authentication TLV [RFC5613] SHOULD also be used to protect the contents of the LLS block.
Receiving a malformed LLS Local Interface ID TLV MUST NOT result in a hard router or OSPF process failure. The reception of malformed LLS TLVs or sub-TLVs SHOULD be logged, but such logging MUST be rate- limited to prevent denial-of-service (DoS) attacks.
The Interface ID is assigned by the advertising OSPF router as a locally unique identifier and need not be unique in any broader context; it is not expected to contain any information about the device owner or traffic transiting the device, so there are no privacy concerns associated with its advertisement.