Skip to main content

Dynamic Hostname Exchange Mechanism for OSPF

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 5642.
Authors Subbaiah Venkata , Sanjay , Carlos Pignataro , Danny R. McPherson
Last updated 2015-10-14 (Latest revision 2009-07-12)
Replaces draft-venkata-ospf-dynamic-hostname
RFC stream Internet Engineering Task Force (IETF)
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state RFC 5642 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Ross Callon
Send notices to (None)
OSPF WG                                                       S. Venkata
Internet-Draft                                               Google Inc.
Intended status: Standards Track                              S. Harwani
Expires: January 13, 2010                                   C. Pignataro
                                                           Cisco Systems
                                                            D. McPherson
                                                    Arbor Networks, Inc.
                                                           July 12, 2009

              Dynamic Hostname Exchange Mechanism for OSPF

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 13, 2010.

Copyright Notice

Venkata, et al.         Expires January 13, 2010                [Page 1]
Internet-Draft         Dynamic Hostnames for OSPF              July 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 (
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.


   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.

Venkata, et al.         Expires January 13, 2010                [Page 2]
Internet-Draft         Dynamic Hostnames for OSPF              July 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 . . . . . . . . . . . . . . . . . . .  6
       3.1.1.  Flooding Scope . . . . . . . . . . . . . . . . . . . .  7
       3.1.2.  Multiple OSPF Instances  . . . . . . . . . . . . . . .  7
   4.  IPv6 Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     8.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10

Venkata, et al.         Expires January 13, 2010                [Page 3]
Internet-Draft         Dynamic Hostnames for OSPF              July 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.
   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",
   document are to be interpreted as described in [RFC2119].

2.  Possible solutions

   There are various approaches to providing a name-to-Router ID mapping

   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 January 13, 2010                [Page 4]
Internet-Draft         Dynamic Hostnames for OSPF              July 2009


   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
   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]).

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.

Venkata, et al.         Expires January 13, 2010                [Page 5]
Internet-Draft         Dynamic Hostnames for OSPF              July 2009

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 ...                         |

   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 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 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, the
   Router ID does not map to an IPv4-addressed entity (e.g., see
   Section 4), or 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.

   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.

Venkata, et al.         Expires January 13, 2010                [Page 6]
Internet-Draft         Dynamic Hostnames for OSPF              July 2009

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 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.

   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

Venkata, et al.         Expires January 13, 2010                [Page 7]
Internet-Draft         Dynamic Hostnames for OSPF              July 2009

   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, 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.

   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.

Venkata, et al.         Expires January 13, 2010                [Page 8]
Internet-Draft         Dynamic Hostnames for OSPF              July 2009

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 [RFC5301] (obsoletes [RFC2763]);
   we would like to thank Naiming Shen and and Henk Smit, authors of

   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", April 2009,

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS

Venkata, et al.         Expires January 13, 2010                [Page 9]
Internet-Draft         Dynamic Hostnames for OSPF              July 2009

              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.


   Sanjay Harwani
   Cisco Systems


   Carlos Pignataro
   Cisco Systems


Venkata, et al.         Expires January 13, 2010               [Page 10]
Internet-Draft         Dynamic Hostnames for OSPF              July 2009

   Danny McPherson
   Arbor Networks, Inc.


Venkata, et al.         Expires January 13, 2010               [Page 11]