Dynamic Hostname Exchange Mechanism for OSPF
Extracted elements (18)
Static hostname-to-Router-ID mapping tables do not scale because every router must maintain entries for all routers in the network, and manual updates are error-prone. DNS-based centralized mapping introduces a single point of failure and may be unreachable precisely when needed for problem resolution.
The in-protocol TLV approach was chosen so that routers that understand the TLV can build the symbolic name-to-Router-ID mapping automatically, while routers that do not understand it simply ignore it, preserving backward compatibility.
Use of FQDN or a subset of it as the hostname is strongly recommended because it allows correlation between the OSPF dynamic hostname and the DNS hostname, aiding operational diagnostics.
For OSPFv3 in native IPv6 deployments, the 32-bit Router ID does not map to an IPv4-addressed entity and is not DNS resolvable; the Dynamic Hostname TLV provides a human-readable mapping in such environments.
The Dynamic Hostname TLV is applicable to both OSPFv2 and OSPFv3, leveraging the OSPF Router Information (RI) Opaque LSA defined in RFC 4970. Routers that do not recognize TLV type 7 ignore it per RFC 4970 rules.
For area scope, the Dynamic Hostname TLV MUST be carried within an OSPFv2 Type 10 RI LSA or an OSPFv3 RI LSA with the S1 bit set and S2 bit clear. For AS scope, it MUST be carried within an OSPFv2 Type 11 RI LSA or OSPFv3 RI LSA with S1 clear and S2 set.
If a router is advertising any AS-scope LSA (other than Dynamic Hostname TLV RI LSA), it SHOULD advertise Dynamic Hostname TLV RI LSA in AS scope; otherwise it SHOULD advertise in area scope. ASBRs SHOULD send AS-scope; ABRs and internal routers SHOULD send area-scope.
If a router originates a Dynamic Hostname TLV with AS flooding scope, it SHOULD NOT send area-scoped Dynamic Hostname TLVs except into any attached NSSA areas.
The Dynamic Hostname TLV is OPTIONAL; upon receipt, a router may decide to ignore the TLV or install the symbolic name and Router ID in its hostname mapping table.
The Dynamic Hostname TLV SHOULD NOT be advertised into an area in more than one RI LSA, irrespective of the scope of the LSA, to avoid inconsistency.
The hostname Value field is encoded in 7-bit ASCII. If a user interface permits Unicode characters, it is responsible for applying the ToASCII and/or ToUnicode algorithm (RFC 3490) for correct transmission or display.
When the Dynamic Hostname TLV is advertised in multiple OSPF instances, the hostname SHOULD either be preserved or include a common base element across instances.
The Dynamic Hostname TLV is a new OSPF Router Information TLV (type 7) that carries a symbolic hostname-to-Router-ID mapping. The hostname Value field is 1 to 255 octets encoded in US-ASCII, padded with zeroes to 4-octet alignment. The Router ID is derived from the Advertising Router field in the RI Opaque LSA header.
IANA assigned TLV type value 7 ('OSPF Dynamic Hostname') in the 'OSPF Router Information (RI) TLVs' registry, allocated from the Standards Action range per RFC 4970.
A misconfigured or compromised router can inject false hostname-to-Router-ID mapping information, including duplicate hostnames for different Router IDs; this information should be treated with suspicion during security incident diagnostics.
There is no generic conflict detection or resolution mechanism for hostname collisions; however, a router that detects a received hostname matching its own local hostname can issue a notification or management alert.
Use of FQDN as the OSPF dynamic hostname may expose geographic or commercial information when sent in the clear. OSPFv3 supports confidentiality via transport mode IPsec (RFC 4552); OSPFv2 can be operated over IPsec tunnels if confidentiality is required.
The Dynamic Hostname TLV has a 2-octet Type field (value 7), a 2-octet Length field indicating the hostname length in octets (excluding optional padding), and a Value field of 1–255 octets containing the hostname in US-ASCII, zero-padded to 4-octet alignment.