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
draft-venkata-ospf-dynamic-hostname-02
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-
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 July 29, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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
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",
"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 July 29, 2008 [Page 3]
Internet-Draft Dynamic Hostnames for OSPF January 2008
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 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
alignment.
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
TLVs.
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,
<http://www.iana.org/assignments/ospfv2-parameters>.
[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
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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
http://www.ietf.org/ipr.
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
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Venkata, et al. Expires July 29, 2008 [Page 8]