OSPF WG S. Venkata Internet-Draft Google Inc. Intended status: Standards Track S. Harwani Expires: October 5, 2009 C. Pignataro Cisco Systems D. McPherson Arbor Networks, Inc. April 3, 2009 Dynamic Hostname Exchange Mechanism for OSPF draft-ietf-ospf-dynamic-hostname-03 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 5, 2009. Copyright Notice Venkata, et al. Expires October 5, 2009 [Page 1] Internet-Draft Dynamic Hostnames for OSPF April 2009 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. Abstract Currently, there does not exist a simple and dynamic mechanism for routers running OSPF to learn about symbolic hostnames just like for routers running IS-IS. This document defines a new OSPF Router Information (RI) TLV which allows the OSPF routers to flood their hostname-to-Router ID mapping information across the OSPF network. This mechanism is applicable to both OSPFv2 and OSPFv3. Venkata, et al. Expires October 5, 2009 [Page 2] Internet-Draft Dynamic Hostnames for OSPF April 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Specification of Requirements . . . . . . . . . . . . . . . 4 2. Possible solutions . . . . . . . . . . . . . . . . . . . . . . 4 3. Implementation . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Dynamic Hostname TLV . . . . . . . . . . . . . . . . . . . 5 3.1.1. Flooding Scope . . . . . . . . . . . . . . . . . . . . 6 3.1.2. Multiple OSPF Instances . . . . . . . . . . . . . . . . 7 4. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Venkata, et al. Expires October 5, 2009 [Page 3] Internet-Draft Dynamic Hostnames for OSPF April 2009 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. It is obvious that, 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 become a manual and tedious process in operational networks currently; 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 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 Venkata, et al. Expires October 5, 2009 [Page 4] Internet-Draft Dynamic Hostnames for OSPF April 2009 considerations. Another approach is having a centralized location where the name-to- Router ID mapping can be kept. DNS can be used for the same. A disadvantage with this centralized solution is that its 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. Also, the response time can be an issue with the centralized solution, which can be particularly problematic in times of problem resolution. If DNS is used as the centralized mapping table, a network operator may desire a different name mapping than the existing in the DNS, or new routers may not yet be in 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 who don't understand can simply ignore it. This specification provides these semantics and mapping mechanisms for OSPFv2 and OSPFv3, leveraging the OSPF Router Information (RI) LSA ([RFC4970]). 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 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 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Venkata, et al. Expires October 5, 2009 [Page 5] Internet-Draft Dynamic Hostnames for OSPF April 2009 Type Dynamic Hostname TLV Type (TBD, 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 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. 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. 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 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 TLV except into any attached Not-So-Stubby Area (NSSA) area(s). Similarly, if a router originates area-scoped Dynamic Hostname TLV (other than NSSA area scoped), it SHOULD NOT send 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 TLV RI LSA) such router SHOULD advertise Dynamic TLV RI LSA in AS scope. Otherwise, it SHOULD advertise Dynamic 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. Venkata, et al. Expires October 5, 2009 [Page 6] Internet-Draft Dynamic Hostnames for OSPF April 2009 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 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 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 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 either need to be 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 which 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. Thus, this information needs to be treated with suspicion when, for example, doing Venkata, et al. Expires October 5, 2009 [Page 7] Internet-Draft Dynamic Hostnames for OSPF April 2009 diagnostics about a suspected security incident. 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 reachable at [IANA-RI]. An additional OSPF Router Information TLV Type is defined in Section 3. It is required to be assigned by IANA from the Standards Action allocation range [RFC4970]. Registry Name: OSPF Router Information (RI) TLVs Type Value Capabilities Reference ----------- -------------------------------------- --------- TBD 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 [RFC2763]; we would like to thank Naiming Shen and and Henk Smit, authors of that document. 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. Venkata, et al. Expires October 5, 2009 [Page 8] Internet-Draft Dynamic Hostnames for OSPF April 2009 8.2. Informative References [IANA-RI] Internet Assigned Numbers Authority, "OSPFv2 Parameters", July 2008, . [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. [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. Expires October 5, 2009 [Page 9]