OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement
Extracted elements (14)
OSPF parallel unnumbered links create a bidirectional connectivity verification problem: two unidirectional parallel links can be mistaken for a valid bidirectional link during route computation. Advertising both Local and Remote Interface IDs allows each link advertisement to be cross-checked from both sides of the adjacency.
The existing mechanism using Link Local TE Opaque LSA to communicate Local Interface IDs has two key drawbacks: LSAs can only be flooded over adjacencies in Exchange state or greater, meaning a link may be initially advertised without a Remote Interface ID; and the TE Opaque LSA is MPLS TE-specific, making it unnecessarily scoped for non-TE use cases.
During rare conditions in which the Local Interface ID changes, a timing window may exist where the values advertised through LLS and the Link Local TE Opaque LSA differ. This situation is temporary; values via both mechanisms should converge once the next Hello and/or Link Local TE Opaque LSA is regenerated.
The security considerations for RFC 5613 (OSPF Link-Local Signaling) apply in full to the Local Interface ID TLV defined in this document, as the TLV is carried within the LLS block.
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.
Local Interface ID TLV signaling using LLS is applicable to all OSPF interface types other than virtual links.
Receiving a malformed LLS Local Interface ID TLV MUST NOT result in a hard router or OSPF process failure.
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.
The Local Interface ID TLV is an OSPF LLS TLV (Type 18) that carries the router's Local Interface ID in OSPF Hello and Database Description (DD) packets, enabling Remote Interface ID learning as part of the neighbor discovery process.
IANA allocated code point 18 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 for the Local Interface ID TLV.
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, potentially preventing the link from being used. If authentication is used in the OSPF routing domain, the Cryptographic Authentication TLV SHOULD also protect the LLS block contents.
The Local Interface ID TLV has a 2-octet Type field (value 18), a 2-octet Length field (value 4), and a 4-octet Local Interface ID value field, for a total of 8 octets.