OSPFv2 Multi-Instance Extensions
updates
- rfc-2328 — OSPF Version 2
Extracted elements (20)
Earlier drafts considered drastic mechanisms to prevent legacy OSPFv2 routers from receiving multicast OSPFv2 packets with non-zero Instance IDs. These were removed because implementers confirmed that authentication-mismatch log dampening would make the spurious-log problem manageable in practice.
The AuType field was reduced from 16 bits to 8 bits to make room for the new 8-bit Instance ID within the same 32-bit word of the packet header. This is justified by the fact that only three OSPFv2 authentication types have ever been standardized, leaving the upper 8 bits of the original AuType unused.
The three pre-assigned Instance IDs (0=Unicast, 1=Multicast, 2=In-band Management) are explicitly analogous to the Multi-Topology (MT) topology IDs in RFC 4915, providing a familiar conceptual mapping for operators familiar with MT-OSPF deployments.
Unlike OSPFv3, where the Instance ID can serve multiple purposes (e.g., placing the same interface in multiple areas), the OSPFv2 Instance ID is strictly reserved for identifying protocol instances. This narrower scope avoids ambiguity in OSPFv2 deployments.
Legacy OSPFv2 routers that do not support this specification will interpret a non-zero Instance ID in the packet header as being part of the AuType field, causing them to treat it as a mismatched authentication type and drop the packet. This behavior is intentional and desired — legacy routers should only participate in the default instance (Instance ID 0).
Reducing the AuType from 2 octets to 1 octet causes OSPFv2 routers not supporting this specification to fail packet authentication for any non-default instance. This is solely due to differing field definitions, not any explicit change to OSPFv2 authentication mechanisms (RFC 2328 Appendix D and RFC 5709).
Implementations that support both this specification and the OSPF MIB (RFC 4750) should also implement SNMP Notification filtering (RFC 3413 Section 6) to suppress spurious ospfIfAuthFailure or ospfVirtIfAuthFailure notifications generated when legacy OSPFv2 routers are deployed on the same subnet.
Received OSPFv2 packets whose Instance ID does not match any of the Instance IDs configured for OSPFv2 instances on the receiving interface MUST be discarded.
When sending OSPFv2 packets, the OSPFv2 Interface Instance ID MUST be set in the OSPFv2 packet header. When receiving, the Header Instance ID is used to demultiplex the packet and associate it with the correct OSPFv2 instance; packets with a non-matching Instance ID MUST be discarded.
Instance ID 0 designates the Base IPv4 Unicast Instance, corresponding to default IPv4 unicast routing and its attendant IPv4 routing table. This value provides backward compatibility with RFC 2328.
Instance ID 1 designates the Base IPv4 Multicast Instance, corresponding to a separate IPv4 routing table used for Reverse Path Forwarding (RPF) checking on IPv4 multicast traffic.
Instance ID 2 designates the Base IPv4 In-band Management Instance, corresponding to a separate IPv4 routing table used for network management applications.
Instance IDs 128–255 are Unassigned and require Standards Action for allocation. The first three Instance IDs (0–2) are analogous to the topology IDs defined in RFC 4915.
Instance IDs 3–127 are reserved for Private Use, defined and assigned by the local network administrator. They may be used, for example, to support independent non-congruent topologies for different classes of IPv4 unicast traffic.
The Instance ID is an 8-bit field in the OSPFv2 packet header that enables multiple OSPFv2 protocol instances to share a single interface. It has local subnet significance only; each protocol instance is assigned a distinct Instance ID. Unlike OSPFv3, the OSPFv2 Instance ID is strictly reserved for identifying protocol instances and cannot be used to put the same interface in multiple areas.
The OSPFv2 Interface Instance ID is added to the conceptual interface data structure defined in Section 9 of RFC 2328. Its default value is 0; non-zero values are set through configuration.
A new IANA registry 'OSPFv2 Instance IDs' is created with initial allocations: 0 (Base IPv4 Unicast, Assigned), 1 (Base IPv4 Multicast, Assigned), 2 (Base IPv4 In-band Management, Assigned), 3–127 (Private Use, reserved for local policy), 128–255 (Unassigned, Standards Action).
The OSPF Authentication Codes registry is modified: the AuType field is reduced from 16 bits to 8 bits, making values 256–65535 no longer defined and therefore deprecated. These values were previously designated 'Reserved and should not be assigned,' so there is no backward compatibility issue.
The multi-instance extension does not introduce additional security considerations beyond those already present in OSPFv2 (RFC 2328). The reduction of the AuType header field to 8 bits is considered reasonable given that only three OSPFv2 authentication types have been standardized.
The OSPFv2 packet header is modified by splitting the 16-bit Authentication Type field into two 8-bit fields: a new Instance ID field (bits 8–15 of the original AuType word, after the Checksum) and a reduced 8-bit AuType field. All other header fields (Version, Type, Packet length, Router ID, Area ID, Checksum, Authentication) remain unchanged.