OSPF Link-Local Signaling
obsoletes
- rfc-4813 — OSPF Link-Local Signaling
Extracted elements (22)
LLS appends a TLV data block to existing Hello and DD packets rather than introducing a new packet type. A new packet type would add extra packets on the network and cause backward compatibility issues; appending to existing packets avoids both problems because non-LLS routers simply ignore the trailing data.
Implementations compliant with the experimental predecessor RFC 4813 are already deployed; routers not implementing RFC 4813 ignore LLS data at the end of the OSPF packet. The primary behavioral change from RFC 4813 is the addition of OSPFv3 support, mandatory private enterprise codes in private TLVs, and promotion from Experimental to Standards Track.
OSPF routers that do not support LLS will ignore the LLS data block appended after the OSPF packet or cryptographic message digest, preserving backward compatibility. Changes caused by LLS TLVs MUST NOT affect basic routing when interacting with non-LLS routers.
Extensions to OSPF that require a new LLS TLV type MUST be reviewed by a Designated Expert from the routing area. LLS should not be used for information better suited to a link-local LSA, should be confined to signaling between direct neighbors, and volume should be kept small due to MTU and performance implications.
If the LLS block checksum is incorrect, the OSPF packet MUST still be processed, but the LLS block MUST be discarded. When cryptographic authentication is in use, the regular LLS checksum is not calculated and is instead set to 0.
Private TLVs use type values in the range 32768–65535. The first four octets of the Value field MUST be the private enterprise code (per IANA), allowing multiple vendor private extensions to coexist on the same network.
The CA-TLV is OSPFv2-only and MUST NOT be added to any OSPFv3 packet. If found on reception in an OSPFv3 context, this TLV MUST be ignored.
The CA-TLV's Sequence Number MUST match the Sequence Number in the OSPFv2 packet header Authentication field. On a mismatch or authentication failure, the whole LLS block MUST be ignored. The CA-TLV MUST NOT appear more than once, and when present MUST be the last TLV in the LLS block.
The EOF-TLV MUST only appear once in the LLS data block.
The L-bit MUST NOT be set except in Hello and DD packets that actually contain an LLS block.
The LLS block MAY be attached only to OSPF Hello and Database Description (DD) packets. It MUST NOT be attached to any other OSPF packet types on generation and MUST be ignored on reception if present on other packet types.
When cryptographic authentication is enabled on the corresponding interface, the LLS data block MUST also be cryptographically authenticated using the CA-TLV; all LLS TLVs MUST be 32-bit aligned (padded if necessary), with padding bytes not counted in the TLV Length field.
A new L-bit is defined in the OSPF Options field (both OSPFv2 and OSPFv3 variants). Routers set the L-bit in Hello and DD packets to signal that the packet contains an LLS data block; the LLS block is only examined when this bit is set.
The Extended Options and Flags (EOF) TLV has Type=1 and a 4-byte Value field. Its bits MAY announce OSPF link-local capabilities or perform boolean link-local signaling. The EOF-TLV MUST only appear once in the LLS data block.
The LLS block is appended after the OSPF packet body, or after the authentication data block when cryptographic authentication is used. Its length is not included in the OSPF packet length field but is included in the IPv4/IPv6 packet length.
The 'LLS Type 1 Extended Options and Flags' sub-registry (renamed from 'LLS Type 1 Extended Options') tracks bit assignments in the EOF-TLV. Currently assigned: bit 0x00000001 (LSDB Resynchronization, RFC 4811) and bit 0x00000002 (Restart Signal RS-bit, RFC 4812). Future allocations require Designated Expert review.
The 'OSPF Link-Local Signalling (LLS) Type/Length/Value Identifiers (TLV)' registry is updated to point to RFC 5613. Type 0 is Reserved; Type 1 is Extended Options and Flags; Type 2 is Cryptographic Authentication (OSPFv2 only); Types 3–32767 are reserved for IANA assignment via IETF Review; Types 32768–65535 are Private Use.
For OSPFv2, LLS data can be authenticated using the same cryptographic authentication mechanism as the base OSPFv2 protocol via the CA-TLV, providing the same level of security as the base protocol. The Sequence Number in the CA-TLV prevents simple replay attacks.
For OSPFv3, IPsec AH, ESP, or both are applied to the entire OSPFv3 payload including the LLS block, so OSPFv3 LLS data inherits the authentication and encryption provided by the OSPFv3 security architecture (RFC 4552).
Each LLS TLV consists of a 16-bit Type field (unique TLV ID), a 16-bit Length field (length of Value in bytes), and a variable-length Value field. TLVs are padded to a 32-bit boundary; padding bytes are not included in the TLV Length but are included in the LLS Data Length. Unrecognized TLV types are ignored.
The Cryptographic Authentication TLV (CA-TLV, Type=2) for OSPFv2 contains a 32-bit Sequence Number followed by an AuthData field holding the message digest of the LLS block up to (but not including) the CA-TLV AuthData. The Length field covers 4 bytes for the Sequence Number plus the digest length.
The LLS Data Block begins with a 16-bit Checksum (standard IP checksum over the entire LLS block, set to 0 before calculation) followed by a 16-bit LLS Data Length (in 32-bit words, including header and payload), followed by LLS TLVs.