From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss <mail@thomasvoss.com> Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5642.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc5642.txt (limited to 'doc/rfc/rfc5642.txt') diff --git a/doc/rfc/rfc5642.txt b/doc/rfc/rfc5642.txt new file mode 100644 index 0000000..d9f7107 --- /dev/null +++ b/doc/rfc/rfc5642.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group S. Venkata +Request for Comments: 5642 Google Inc. +Category: Standards Track S. Harwani + C. Pignataro + Cisco Systems + D. McPherson + Arbor Networks, Inc. + August 2009 + + + Dynamic Hostname Exchange Mechanism for OSPF + +Abstract + + This document defines a new OSPF Router Information (RI) TLV that + allows OSPF routers to flood their hostname-to-Router-ID mapping + information across an OSPF network to provide a simple and dynamic + mechanism for routers running OSPF to learn about symbolic hostnames, + just like for routers running IS-IS. This mechanism is applicable to + both OSPFv2 and OSPFv3. + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. 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 review these documents carefully, as they describe your rights + and restrictions with respect to 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 obtaining 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 + + + +Venkata, et al. Standards Track [Page 1] + +RFC 5642 Dynamic Hostnames for OSPF August 2009 + + + 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 . . . . . . . . . . . . . . . . . . 7 + +1. Introduction + + OSPF uses a 32-bit Router ID to uniquely represent and identify a + node in the network. For management and operational reasons, network + operators need to check the status of OSPF adjacencies, entries in + the routing table, and the content of the OSPF link state database. + When looking at diagnostic information, numerical representations of + Router IDs (e.g., dotted-decimal or hexadecimal representations) are + less clear to humans than symbolic names. + + One way to overcome this problem is to define a hostname-to-Router-ID + mapping table on a router. This mapping can be used bidirectionally + (e.g., to find symbolic names for Router IDs and to find Router IDs + for symbolic names) or unidirectionally (e.g., to find symbolic + hostnames for Router IDs). Thus, every router has to maintain a + table with mappings between router names and Router IDs. + + These tables need to contain all names and Router IDs of all routers + in the network. If these mapping tables are built by static + definitions, it can currently become a manual and tedious process in + operational networks; modifying these static mapping entries when + additions, deletions, or changes occur becomes a non-scalable process + very prone to error. + + This document analyzes possible solutions to this problem (see + Section 2) and provides a way to populate tables by defining a new + + + + +Venkata, et al. Standards Track [Page 2] + +RFC 5642 Dynamic Hostnames for OSPF August 2009 + + + OSPF Router Information TLV for OSPF, the Dynamic Hostname TLV (see + Section 3). This mechanism is applicable 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 various approaches to providing a name-to-Router-ID mapping + service. + + One way to build this table of mappings is by static definitions. + The problem with static definitions is that the network administrator + needs to keep updating the mapping entries manually as the network + changes; this approach does not scale as the network grows, since + there needs to be an entry in the mapping table for each and every + router in the network, on every router in the network. Thus, this + approach greatly suffers from maintainability and scalability + considerations. + + Another approach is having a centralized location where the name-to- + Router-ID mapping can be kept. The DNS could be used for this. A + disadvantage with this centralized solution is that it is a single + point of failure; and although enhanced availability of the central + mapping service can be designed, it may not be able to resolve the + hostname in the event of reachability or network problems, which can + be particularly problematic in times of problem resolution. Also, + the response time can be an issue with the centralized solution, + which can be equally problematic. If the DNS is used as the + centralized mapping table, a network operator may desire a different + name mapping than the existing mapping in the DNS, or new routers may + not yet be in the DNS. + + Additionally, for OSPFv3 in native IPv6 deployments, the 32-bit + Router ID value will not map to IPv4-addressed entities in the + network, nor will it be DNS resolvable (see Section 4). + + The third solution that we have defined in this document is to make + use of the protocol itself to carry the name-to-Router-ID mapping in + a TLV. Routers that understand this TLV can use it to create the + symbolic name-to-Router-ID mapping, and routers that don't understand + it can simply ignore it. This specification provides these semantics + and mapping mechanisms for OSPFv2 and OSPFv3, leveraging the OSPF + Router Information (RI) Link State Advertisement (LSA) ([RFC4970]). + + + + +Venkata, et al. Standards Track [Page 3] + +RFC 5642 Dynamic Hostnames for OSPF August 2009 + + +3. Implementation + + This extension makes use of the Router Information (RI) Opaque LSA, + defined in [RFC4970], for both OSPFv2 and OSPFv3, by defining a new + OSPF Router Information (RI) TLV: the Dynamic Hostname TLV. + + The Dynamic Hostname TLV (see Section 3.1) is OPTIONAL. Upon receipt + of the TLV, a router may decide to ignore this TLV 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 is as follows: + + 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 ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type Dynamic Hostname TLV Type (7; see Section 6) + + Length Total length of the hostname (Value field) in octets, not + including the optional padding. + + Value Hostname, a string of 1 to 255 octets, padded with zeroes to + 4-octet alignment, encoded in the US-ASCII charset. + + Routers that do not recognize the Dynamic Hostname TLV Type ignore + the TLV (see [RFC4970]). + + The Value field identifies the symbolic hostname of the router + originating the LSA. This symbolic name can be the Fully Qualified + Domain Name (FQDN) for the Router ID, it can be a subset of the FQDN, + or it can be any string that operators want to use for the router. + The use of FQDN or a subset of it is strongly recommended since it + can be beneficial to correlate the OSPF dynamic hostname and the DNS + hostname. The format of the DNS hostname is described in [RFC1035] + and [RFC2181]. If there is no DNS hostname for the Router ID, if the + Router ID does not map to an IPv4-addressed entity (e.g., see + Section 4), or if an alternate OSPF dynamic hostname naming + convention is desired, any string with significance in the OSPF + routing domain can be used. The string is not null-terminated. The + Router ID of this router is derived from the LSA header, in the + Advertising Router field of the Router Information (RI) Opaque LSA. + + + + +Venkata, et al. Standards Track [Page 4] + +RFC 5642 Dynamic Hostnames for OSPF August 2009 + + + The Value field is encoded in 7-bit ASCII. If a user-interface for + configuring or displaying this field permits Unicode characters, that + user-interface is responsible for applying the ToASCII and/or + ToUnicode algorithm as described in [RFC3490] to achieve the correct + format for transmission or display. + + The Dynamic Hostname TLV is applicable to both OSPFv2 and OSPFv3. + +3.1.1. Flooding Scope + + The Dynamic Hostname TLV MAY be advertised within an area-local or + autonomous system (AS)-scope Router Information (RI) LSA. But the + Dynamic Hostname TLV SHOULD NOT be advertised into an area in more + than one RI LSA, irrespective of the scope of the LSA. + + In other words, if a router originates 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 originates an area-scoped + Dynamic Hostname TLV (other than NSSA area scoped), it SHOULD NOT + send an AS-scoped Dynamic Hostname TLV. When the Dynamic Hostname + TLV is advertised in more than one LSA (e.g., multiple area-scoped + LSAs, or AS-scoped LSAs plus NSSA area-scope LSA(s)), the hostname + SHOULD be the same. + + If a router is advertising any AS-scope LSA (other than Dynamic + Hostname TLV RI LSA), such router SHOULD advertise Dynamic Hostname + TLV RI LSA in AS scope. Otherwise, it SHOULD advertise 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 + OSPFv3 RI LSA with the S1 bit clear and the S2 bit set. + +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 assign separate + instances different hostnames with a consistent set of suffixes or + + + +Venkata, et al. Standards Track [Page 5] + +RFC 5642 Dynamic Hostnames for OSPF August 2009 + + + prefixes that can be associated with a specific instance -- in + particular, when an instance is used for a discrete address family or + non-routing information. + +4. IPv6 Considerations + + Both OSPFv2 and OSPFv3 employ Router IDs with a common size of 32 + bits. In IPv4, the Router ID values were typically derived + automatically from an IPv4 address either configured on a loopback or + physical interface defined on the local system or explicitly defined + within the OSPF process configuration. With broader deployment of + IPv6, it's quite likely that OSPF networks will exist that have no + native IPv4-addressed interfaces. As a result, a 32-bit OSPF Router + ID will need to be either explicitly specified or derived in some + automatic manner that avoids collisions with other OSPF routers + within the local routing domain. + + Because this 32-bit value will not map to IPv4-addressed entities in + the network, nor will it be DNS resolvable, it is considered + extremely desirable from an operational perspective that some + mechanism exist to map OSPF Router IDs to more easily interpreted + values -- ideally, human-readable strings. This specification + enables a mapping functionality that eases operational burdens that + may otherwise be introduced with native deployment of IPv6. + +5. Security Considerations + + Since the hostname-to-Router-ID mapping relies on information + provided by the routers themselves, a misconfigured or compromised + router can inject false mapping information, including a duplicate + hostname for different Router IDs. Thus, this information needs to + be treated with suspicion when, for example, doing diagnostics about + a suspected security incident. + + There is potential confusion from name collisions if two routers use + and advertise the same dynamic hostname. Name conflicts are not + crucial, and therefore there is no generic conflict detection or + resolution mechanism in the protocol. However, a router that detects + that a received hostname is the same as the local one can issue a + notification or a management alert. + + The use of the FQDN as OSPF dynamic hostname potentially exposes + geographic or other commercial information that can be deduced from + the hostname when sent in the clear. OSPFv3 supports confidentiality + via transport mode IPsec (see [RFC4552]). OSPFv2 could be operated + over IPsec tunnels if confidentiality is required. + + + + + +Venkata, et al. Standards Track [Page 6] + +RFC 5642 Dynamic Hostnames for OSPF August 2009 + + + 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 document + +7. Acknowledgments + + The authors of this document do not make any claims on the + originality of the ideas described. This document adapts format and + text from similar work done in IS-IS [RFC5301] (which obsoletes + [RFC2763]); we would like to thank Naiming Shen and Henk Smit, + 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. + + + + +Venkata, et al. Standards Track [Page 7] + +RFC 5642 Dynamic Hostnames for OSPF August 2009 + + + [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 + + + +Venkata, et al. Standards Track [Page 8] + -- cgit v1.2.3