OSPFv3 Autoconfiguration
updates
- rfc-5340 — OSPF for IPv6
Extracted elements (22)
Autoconfigured OSPFv3 routers do not require identical HelloInterval and RouterDeadInterval to form adjacencies. The received HelloInterval is ignored, and the received RouterDeadInterval is used to determine liveliness, allowing each neighbor's Inactivity Timer to reflect that neighbor's advertised RouterDeadInterval independently.
Hysteresis (delayed processing) was added to self-originated LSA handling to mitigate flooding overhead caused by a router with a duplicate Router ID. This mechanism MAY be deployed outside of autoconfigured deployments as it also mitigates inadvertent or malicious introduction of duplicate Router IDs.
An identical HelloInterval and RouterDeadInterval is still required to form an adjacency with an OSPFv3 router not supporting autoconfiguration per RFC 5340. The HelloInterval flexibility in Section 3 applies only when both sides support autoconfiguration.
A pseudorandom number SHOULD be used for the OSPFv3 Router ID in autoconfigured deployments, seeded with a variable likely to be unique such as a portion or hash of the Router-Hardware-Fingerprint. OSPFv3 routers SHOULD maintain the last successfully chosen Router ID in nonvolatile storage.
After a router selects a new Router ID to resolve a duplicate conflict, all self-originated LSAs MUST be reoriginated and any OSPFv3 neighbor adjacencies MUST be reestablished.
All autoconfigured OSPFv3 interfaces MUST be in area 0.
All OSPFv3 interfaces SHOULD be autoconfigured to use an Interface Instance ID of 0 for the base IPv6 unicast address family. If IPv4 unicast addresses are advertised, the base IPv4 unicast address family instance ID value of 64 SHOULD be used for those interfaces.
An autoconfigured OSPFv3 router MAY reduce the wait interval to a value no less than (HelloInterval + 1) to reduce adjacency formation delay in back-to-back Ethernet topologies.
It is RECOMMENDED that OSPFv3 routers supporting autoconfiguration minimally offer an option to explicitly configure a single password for HMAC-SHA authentication. The password should be entered as ASCII hexadecimal digits with 32 or more digits accepted; when configured, it applies to all autoconfigured interfaces with SA ID 1 and HMAC-SHA-256.
OSPFv3 routers implementing autoconfiguration MUST originate an Autoconfiguration (AC) LSA including the Router-Hardware-Fingerprint TLV, and MUST detect received Autoconfiguration LSAs with their own Router ID in the LSA header to identify duplicate Router ID conflicts.
OSPFv3 routers supporting this specification MUST augment mechanisms for displaying or conveying OSPFv3 operational state to indicate whether the router and its interfaces were autoconfigured.
OSPFv3 SHOULD be autoconfigured on all IPv6-capable interfaces on the router. An interface MAY be excluded if it is clear that running OSPFv3 on the interface is not required, such as an ISP-facing WAN interface.
The Router-Hardware-Fingerprint TLV MUST be based on hardware attributes that will not change across hard and soft restarts. It is RECOMMENDED that one or more universal tokens (e.g., IEEE 802 48-bit MAC addresses or IEEE EUI-64 Identifiers) be included.
When a duplicate Router ID conflict is detected via AC LSA comparison, the OSPFv3 router with the numerically smaller router hardware fingerprint MUST select a new Router ID as described in Section 7.3.
When repeated flushing or reorigination of self-originated LSAs is detected (indicative of a duplicate Router ID in the domain), the OSPFv3 router SHOULD delay self-originated LSA processing. A 10-second window defines 'recent' and an exponential back-off of 1 to 8 seconds is recommended for the processing delay.
The OSPFv3 Autoconfiguration (AC) LSA has function code 15, S2/S1 bits set to 01 (Area Flooding Scope), and the U bit set indicating it should be flooded even if not understood. The Link State ID is an integer index to discriminate between multiple AC LSAs from the same router; LSID 0 is defined by this specification.
The Router-Hardware-Fingerprint TLV has type 1 and MUST be advertised in the AC LSA with LSID 0. It contains a variable-length value of 32 octets or greater constructed from hardware attributes (e.g., MAC addresses, CPU ID, serial numbers) with an extremely high probability of uniqueness that persists across restarts.
This specification allocates value 15 from the existing 'OSPFv3 LSA Function Codes' registry for the OSPFv3 Autoconfiguration (AC) LSA, and creates a new 'OSPFv3 Autoconfiguration (AC) LSA TLVs' registry under the OSPFv3 IANA registry. New values are allocated via IETF Review or IESG Approval. Initial values: 0 (Reserved), 1 (Router-Hardware-Fingerprint TLV), 65535 (Autoconfiguration-Experiment-TLV).
Introduction of an OSPFv3 router with a duplicate Router ID, whether malicious or accidental, is an attack point: other routers will interpret its LSAs as self-originated and attempt to flush them. The hysteresis mechanism in Section 7.4 mitigates the flooding effect of this attack.
The goals of security and complete OSPFv3 autoconfiguration are contradictory — autoconfiguration automatically adopts new devices into the network. Operators should carefully consider security requirements before deploying. Password-based HMAC-SHA authentication (Section 4) or OSPFv3 IPsec may be combined with autoconfiguration to mitigate this risk.
The OSPFv3 AC LSA body consists of TLVs in the same format as Traffic Engineering Extensions to OSPFv2: a 2-octet Type field, a 2-octet Length field (value portion only, excluding padding), and a variable-length Value field padded to 4-octet alignment. Nested TLVs are also 32-bit aligned.
The Router-Hardware-Fingerprint TLV format: Type field = 1 (2 octets), Length field > 32 (2 octets), followed by the variable-length Router Hardware Fingerprint value of at least 32 octets.