doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

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]
+