RFC 5642
Dynamic Hostname Exchange Mechanism for OSPF
Dynamic Hostname Exchange Mechanism for OSPF 🎀
Okay bestie, this is RFC 5642 💖, and its title is "Dynamic Hostname Exchange Mechanism for OSPF." It's a Standards Track doc from the Network Working Group, dated August 2009 🗓️. The authors are S. Venkata (Google Inc.), S. Harwani, C. Pignataro (Cisco Systems), and D. McPherson (Arbor Networks, Inc.) 🫶. The header doesn't list anything it obsoletes or updates, so there's no drama there 🌈.
Abstract 🦋
Okay so this doc adds a brand new OSPF Router Information (RI) TLV 🧚. It lets OSPF routers flood their hostname-to-Router-ID mapping around the whole OSPF network, so they can dynamically learn symbolic hostnames, just like IS-IS routers already do 💅. It works for both OSPFv2 and OSPFv3 ✨.
Status of This Memo 📜
This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💜. For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1) 🔥. Distribution of this memo is unlimited 🌸.
Copyright Notice ⭐
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved 🎀.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please read these carefully, because they describe your rights and restrictions for this document 🙈.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English 😭.
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification of Requirements . . . . . . . . . . . . . . . 3
2. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 3
3. Implementation . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Dynamic Hostname TLV . . . . . . . . . . . . . . . . . . . 4
3.1.1. Flooding Scope . . . . . . . . . . . . . . . . . . . . 5
3.1.2. Multiple OSPF Instances . . . . . . . . . . . . . . . . 5
4. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 71. Introduction 🌸
Okay so OSPF uses a 32-bit Router ID to uniquely identify a node in the network 🧠. For management and ops reasons, network operators need to check OSPF adjacencies, routing table entries, and the OSPF link state database 📊. When you're looking at diagnostic info, numerical Router IDs (like dotted-decimal or hexadecimal) are way less clear to humans than symbolic names 🙈.
One way to fix this is a hostname-to-Router-ID mapping table on each router 🗺️. The mapping can work both ways (symbolic names for Router IDs, and Router IDs for symbolic names), or just one way (symbolic hostnames for Router IDs). Either way, every router has to keep a table of router names and Router IDs 💅.
These tables need every name and Router ID for every router in the network 🌐. If they're built with static definitions, it gets manual and tedious in real operational networks 😩. Changing those static entries whenever routers get added, removed, or changed is non-scalable and super error-prone 💀.
This document looks at possible solutions (see Section 2) and gives a way to populate those tables by defining a new OSPF Router Information TLV, the Dynamic Hostname TLV (see Section 3) 🦋. This mechanism applies to both OSPFv2 and OSPFv3 ✨.
1.1. Specification of Requirements 📜
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 💜.
2. Possible Solutions 🔥
There are a bunch of different approaches to providing a name-to-Router-ID mapping service 🧩.
One way to build the mapping table is static definitions. The problem is that the network admin has to keep updating those entries by hand as the network changes 😤. This doesn't scale as the network grows, because there needs to be an entry for every single router in the network, on every router in the network 🙃. So this approach really struggles with maintainability and scalability 💀.
Another approach is a centralized location where the name-to-Router-ID mapping lives. DNS could be used for this 🌈. The downside is that it's a single point of failure. Even if you design better availability for the central mapping service, it might not be able to resolve the hostname during reachability or network problems, which is especially bad when you're trying to fix problems 😭. Response time can also be an issue with a centralized solution, which is equally problematic 🐢. And if DNS is the central mapping table, a network operator might want a different name mapping than the one already in DNS, or new routers might not be in DNS yet 🙈.
Also, for OSPFv3 in native IPv6 deployments, the 32-bit Router ID value won't map to IPv4-addressed entities in the network, and it won't be DNS resolvable either (see Section 4) 🫠.
The third solution this document defines is to use the protocol itself to carry the name-to-Router-ID mapping in a TLV 🚀. Routers that understand this TLV can use it to build the symbolic name-to-Router-ID mapping, and routers that don't understand it can just ignore it 🎀. This spec provides these semantics and mapping mechanisms for OSPFv2 and OSPFv3, using the OSPF Router Information (RI) Link State Advertisement (LSA) ([RFC4970]) 👑.
3. Implementation 🛠️
This extension uses the Router Information (RI) Opaque LSA, defined in [RFC4970], for both OSPFv2 and OSPFv3. It does this by defining a new OSPF Router Information (RI) TLV: the Dynamic Hostname TLV 🧚.
The Dynamic Hostname TLV (see Section 3.1) is OPTIONAL. When a router receives the TLV, it may decide to ignore it or to install the symbolic name and Router ID in its hostname mapping table 🌸.
3.1. Dynamic Hostname TLV 💖
The format of the Dynamic Hostname TLV looks like this 🎀:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hostname ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the breakdown 🔍:
Type: the Dynamic Hostname TLV Type (7; see Section 6) 🏷️Length: the total length of the hostname (Value field) in octets, not including the optional padding 📏Value: the hostname, a string of 1 to 255 octets, padded with zeroes to 4-octet alignment, encoded in the US-ASCII charset ✨
Routers that don't recognize the Dynamic Hostname TLV Type ignore the TLV (see [RFC4970]) 🙈.
The Value field holds the symbolic hostname of the router that originated the LSA 🦋. That symbolic name can be the Fully Qualified Domain Name (FQDN) for the Router ID, a subset of the FQDN, or any string the operators want to use for the router 💅. Using the FQDN or a subset of it is strongly recommended, since it can be really useful to correlate the OSPF dynamic hostname with the DNS hostname 🌈. The format of the DNS hostname is described in [RFC1035] and [RFC2181]. If there's no DNS hostname for the Router ID, if the Router ID doesn't map to an IPv4-addressed entity (e.g., see Section 4), or if an alternate OSPF dynamic hostname naming convention is wanted, any string with significance in the OSPF routing domain can be used 🧚. The string is not null-terminated 🫶. The Router ID of this router comes from the LSA header, in the Advertising Router field of the Router Information (RI) Opaque LSA 👑.
The Value field is encoded in 7-bit ASCII 🔥. If a user interface for configuring or displaying this field allows Unicode characters, that user interface is responsible for applying the ToASCII and/or ToUnicode algorithm as described in [RFC3490] to get the correct format for transmission or display 💜.
The Dynamic Hostname TLV applies to both OSPFv2 and OSPFv3 ✨.
3.1.1. Flooding Scope 🌸
okay so the Dynamic Hostname TLV MAY be advertised inside an area-local or autonomous system (AS)-scope Router Information (RI) LSA 💅. But it SHOULD NOT be advertised into an area in more than one RI LSA, no matter what the scope of that LSA is. one area, one RI LSA, bestie 🫶
okay now this part is kind of a lot 😭 if a router makes a Dynamic Hostname TLV with an IGP domain (AS) flooding scope, it SHOULD NOT send area-scoped Dynamic Hostname TLVs, except into any attached Not-So-Stubby Area (NSSA) area(s). similarly, if a router makes an area-scoped Dynamic Hostname TLV (other than NSSA area scoped), it SHOULD NOT send an AS-scoped Dynamic Hostname TLV. and when the Dynamic Hostname TLV shows up in more than one LSA (like multiple area-scoped LSAs, or AS-scoped LSAs plus NSSA area-scope LSA(s)), the hostname SHOULD be the same. the vibe is consistency, always 🔥
if a router is advertising any AS-scope LSA (other than the Dynamic Hostname TLV RI LSA), that router SHOULD advertise the Dynamic Hostname TLV RI LSA in AS scope. otherwise, it SHOULD advertise the Dynamic Hostname TLV RI LSA in area scope. for example, an AS boundary router (ASBR) SHOULD send an AS-scope Dynamic Hostname TLV, whereas area boundary router (ABRs) and internal routers SHOULD send an area-scope Dynamic Hostname TLV 🦋
the flooding scope is controlled by the Opaque LSA type in OSPFv2 and by the S1 and S2 bits in OSPFv3. 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 the S2 bit clear. if the flooding scope is the entire routing domain (AS scope), the Dynamic Hostname TLV MUST be carried within an OSPFv2 Type 11 RI LSA, or an OSPFv3 RI LSA with the S1 bit clear and the S2 bit set. the scope bits are literally the whole game ✨
3.1.2. Multiple OSPF Instances 🧚
when an OSPF Router Information (RI) LSA, including the Dynamic Hostname TLV, is advertised in multiple OSPF instances, the hostname SHOULD either be preserved or include a common base element. it may be useful for debugging or other purposes to give separate instances different hostnames with a consistent set of suffixes or prefixes that can be tied to a specific instance -- especially when an instance is used for a discrete address family or non-routing information 🎀
4. IPv6 Considerations 🌈
okay so both OSPFv2 and OSPFv3 use Router IDs that are the same size: 32 bits 🔢. in IPv4, Router ID values were usually derived automatically from an IPv4 address, either configured on a loopback or on a physical interface defined on the local system, or explicitly defined inside the OSPF process configuration. but with IPv6 becoming more widely deployed, it's pretty likely that OSPF networks will show up with no native IPv4-addressed interfaces at all 😭 so that 32-bit OSPF Router ID will need to be either explicitly specified, or derived in some automatic way that avoids collisions with other OSPF routers inside the local routing domain.
and because this 32-bit value won't map to IPv4-addressed entities in the network, and it won't be DNS resolvable either, it's considered extremely desirable (operationally speaking) to have some mechanism that maps OSPF Router IDs to more easily understood values. ideally, human-readable strings 💖 this specification enables that mapping functionality, which takes some of the operational burden off when IPv6 gets deployed natively.
5. Security Considerations 💀
okay this section is serious, so listen up 👑 since the hostname-to-Router-ID mapping depends on information that the routers provide themselves, a misconfigured or compromised router can inject false mapping information, including a duplicate hostname for different Router IDs. so this information needs to be treated with suspicion when, for example, you're doing diagnostics about a suspected security incident 🙈
there's also potential confusion from name collisions if two routers use and advertise the same dynamic hostname. name conflicts aren't crucial, so there's no generic conflict detection or resolution mechanism in the protocol. however, a router that detects that a received hostname is the same as its local one can issue a notification or a management alert 🚨
the use of the FQDN as an OSPF dynamic hostname can potentially expose geographic or other commercial information that can be deduced from the hostname when it's sent in the clear 😭 OSPFv3 supports confidentiality via transport mode IPsec (see [RFC4552]). OSPFv2 could be operated over IPsec tunnels if confidentiality is required.
this document raises no other new security issues for OSPF. security considerations for the base OSPF protocol are covered in [RFC2328] and [RFC5340]. the use of authentication for the OSPF routing protocols is encouraged 🔐
6. IANA Considerations 📋
IANA maintains the "OSPF Router Information (RI) TLVs" registry [IANA-RI]. an additional OSPF Router Information TLV Type is defined in Section 3. it has been assigned by IANA from the Standards Action allocation range [RFC4970].
Registry Name: OSPF Router Information (RI) TLVs
Type Value Capabilities Reference
----------- -------------------------------------- ---------
7 OSPF Dynamic Hostname This document7. Acknowledgments 🫶
the authors of this document don't claim any originality for the ideas described 🙈 this document adapts format and text from similar work done in IS-IS [RFC5301] (which obsoletes [RFC2763]). we'd like to thank Naiming Shen and Henk Smit, the authors of [RFC2763] 💜
the authors would also like to thank Acee Lindem, Abhay Roy, Anton Smirnov, and Dave Ward for their valuable comments and suggestions ✨
8. References 📚
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S.
Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 4970, July 2007.8.2. Informative References
[IANA-RI] Internet Assigned Numbers Authority, "Open Shortest Path
First v2 (OSPFv2) Parameters", <http://www.iana.org>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2763] Shen, N. and H. Smit, "Dynamic Hostname Exchange Mechanism
for IS-IS", RFC 2763, February 2000.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, June 2006.
[RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange
Mechanism for IS-IS", RFC 5301, October 2008.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008.Authors' Addresses 🎀
Subbaiah Venkata
Google Inc.
EMail: svenkata@google.com
URI: http://www.google.com
Sanjay Harwani
Cisco Systems
EMail: sharwani@cisco.com
URI: http://www.cisco.com
Carlos Pignataro
Cisco Systems
EMail: cpignata@cisco.com
URI: http://www.cisco.com
Danny McPherson
Arbor Networks, Inc.
EMail: danny@arbor.net📦 where this page comes from
- ietf: rfc5642 2009-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms