OSPF WG                                                       S. Venkata
Internet-Draft                                               Google Inc.
Intended status: Standards Track                              S. Harwani
Expires: July 29, 2008                                      C. Pignataro
                                                           Cisco Systems
                                                            D. McPherson
                                                    Arbor Networks, Inc.
                                                        January 26, 2008

              Dynamic Hostname Exchange Mechanism for OSPF

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 July 29, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).


   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

Venkata, et al.           Expires July 29, 2008                 [Page 1]

Internet-Draft         Dynamic Hostnames for OSPF           January 2008

   hostname-to-Router ID mapping information across the OSPF network.
   This mechanism is applicable to both OSPFv2 and OSPFv3.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Specification of Requirements . . . . . . . . . . . . . . . 3
   2.  Possible solutions  . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Implementation  . . . . . . . . . . . . . . . . . . . . . . . . 4
     3.1.  Dynamic Hostname TLV  . . . . . . . . . . . . . . . . . . . 4
   4.  IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7
   Intellectual Property and Copyright Statements  . . . . . . . . . . 8

Venkata, et al.           Expires July 29, 2008                 [Page 2]

Internet-Draft         Dynamic Hostnames for OSPF           January 2008

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",
   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 July 29, 2008                 [Page 3]

Internet-Draft         Dynamic Hostnames for OSPF           January 2008


   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 July 29, 2008                 [Page 4]

Internet-Draft         Dynamic Hostnames for OSPF           January 2008

   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

   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 Dynamic Hostname TLV is applicable to both OSPFv2 and OSPFv3.

   The Dynamic Hostname TLV MAY be advertised within an area-local or AS
   scope Router Information LSA.  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.  An AS boundary router (ASBR) may choose to send an AS scope
   Dynamic Hostname TLV, whereas area boundary router (ABRs) and
   internal routers may choose to send an area scope Dynamic Hostname
   TLV.  If a router originates Dynamic Hostname TLVs with an IGP domain
   (AS) flooding scope, it MAY omit sending area-scoped Dynamic Hostname

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

Venkata, et al.           Expires July 29, 2008                 [Page 5]

Internet-Draft         Dynamic Hostnames for OSPF           January 2008

   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

   This document raises no new security issues for OSPF.  Security
   considerations for the base OSPF protocol are covered in [RFC2328]
   and [RFC2740].  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 Lindam and Abhay Roy for
   their valuable comments.

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.

Venkata, et al.           Expires July 29, 2008                 [Page 6]

Internet-Draft         Dynamic Hostnames for OSPF           January 2008

   [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, "OSPFv2 Parameters",
              January 2008,

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC2740]  Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
              RFC 2740, December 1999.

   [RFC2763]  Shen, N. and H. Smit, "Dynamic Hostname Exchange Mechanism
              for IS-IS", RFC 2763, February 2000.

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 July 29, 2008                 [Page 7]

Internet-Draft         Dynamic Hostnames for OSPF           January 2008

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Venkata, et al.           Expires July 29, 2008                 [Page 8]