doc: Add RFC documents

1 files changed, 283 insertions, 0 deletions

diff --git a/doc/rfc/rfc2763.txt b/doc/rfc/rfc2763.txt
new file mode 100644
index 0000000..964ef94
--- /dev/null
+++ b/doc/rfc/rfc2763.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                           N. Shen
+Request for Comments: 2763                                Siara Systems
+Category: Informational                                         H. Smit
+                                                          Cisco Systems
+                                                          February 2000
+
+
+                  Dynamic Hostname Exchange Mechanism
+                               for IS-IS
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   Currently, there does not exist a simple and dynamic mechanism for
+   routers running IS-IS to learn about symbolic hostnames. This
+   document defines a new TLV which allows the IS-IS routers to flood
+   their name to system ID mapping information across the IS-IS network.
+
+1. Introduction
+
+   IS-IS uses a 1-8 byte system ID (normally 6 bytes) to represent a
+   node in the network.  For management and operation reasons, network
+   operators need to check the status of IS-IS adjacencies, entries in
+   the routing table and the content of the IS-IS link state database.
+   It is obvious that, when looking at diagnostics information,
+   hexadecimal representations of systemIDs and LSP identifiers are less
+   clear than symbolic names.
+
+   One way to overcome this problem is to define a name-to-systemID
+   mapping on a router. This mapping can be used bidirectionally. E.g.,
+   to find symbolic names for systemIDs, and to find systemIDs for
+   symbolic names. One way to build this table of mappings is by static
+   definitions. Among network administrators who use IS-IS as their IGP
+   it is current practice to define such static mappings.
+
+   Thus every router has to maintain a table with mappings between
+   router names and systemIDs. These tables need to contain all names
+   and systemIDs of all routers in the network.
+
+
+
+
+Shen & Smit                  Informational                      [Page 1]
+
+RFC 2763                    Dynamic Hostname               February 2000
+
+
+   There are several ways one could build such a table. One is via
+   static configurations. Another scheme that could be implemented is
+   via DNS lookups. In this document we propose a third solution. We
+   hope the proposed solution is easier and more manageable than static
+   mapping or DNS schemes.
+
+2. Possible solutions
+
+   The obvious drawback of static configuration of mappings is the issue
+   of scalability and maintainability. The network operators have to
+   maintain the name tables. They have to maintain an entry in the table
+   for every router in the network. They have to maintain this table on
+   each router in the network. The effort to create and maintain these
+   static tables grows with the total number of routers on the network.
+   Changing the name or systemID of one router, or adding one new router
+   introduced will affect the configurations of all the other routers on
+   the network. This will make it very likely that those static tables
+   are outdated.
+
+   Having one table that can be updated in a centralized place would be
+   helpful. One could imagine using the DNS system for this. A drawback
+   is that during the time of network problems, the response time of DNS
+   services might not be satisfactory or the DNS services might not even
+   be available. Another possible drawback might be the added complexity
+   of DNS. Also, some DNS implementations might not support A and PTR
+   records for CLNS NSAPs.
+
+   A third way to build dynamic mappings would be to use the transport
+   mechanism of the routing protocol itself to advertise symbolic names
+   in IS-IS link-state PDU. This document defines a new TLV which allows
+   the IS-IS routers to include the name to systemID mapping information
+   in their LSPs. This will allow simple and reliable transport of name
+   mapping information across the IS-IS network.
+
+3. The Dynamic Hostname TLV
+
+   The Dynamic hostname TLV is defined here as TLV type 137.
+
+         LENGTH - total length of the value field.
+
+         VALUE - a string of 1 to 255 bytes.
+
+   The Dynamic hostname TLV is optional. This TLV may be present in any
+   fragment of a non-pseudo node LSP. The value field identifies the
+   symbolic name of the router originating the LSP. This symbolic name
+   can be the FQDN for the router, it can be a subset of the FQDN or any
+   string operators want to use for the router. The use of FQDN or a
+
+
+
+
+Shen & Smit                  Informational                      [Page 2]
+
+RFC 2763                    Dynamic Hostname               February 2000
+
+
+   subset of it is strongly recommended. The content of this value is a
+   domain name, see RFC 2181. The string is not null-terminated. The
+   systemID of this router can be derived from the LSP identifier.
+
+   If this TLV is present in a pseudo node LSP, then it should not be
+   interpreted as the DNS hostname of the router.
+
+4. Implementation
+
+   The Dynamic Hostname TLV is optional. When originating an LSP, a
+   router may decide to include this TLV in its LSP. Upon receipt of an
+   LSP with the dynamic hostname TLV, a router may decide to ignore this
+   TLV, or to install the symbolic name and systemID in its hostname
+   mapping table.
+
+   A router may also optionally insert this TLV in it's pseudo node LSP
+   for the association of a symbolic name to a local LAN.
+
+5. Security Considerations
+
+   This document raises no new security issues for IS-IS. However, it is
+   encouraged to use authentications for IS-IS routing protocol.  The
+   authentication mechanism for IS-IS protocol is specified in [1] and
+   it is being enhanced within IETF in [2].
+
+6. Acknowledgments
+
+   The authors would like to thank Enke Chen and Yakov Rekhter for their
+   comments on this work.
+
+7. References
+
+   [1] ISO, "Intermediate system to Intermediate system routing
+       information exchange protocol for use in conjunction with the
+       Protocol for providing the Connectionless-mode Network Service
+       (ISO 8473)," ISO/IEC 10589:1992.
+
+   [2] Li, T., "IS-IS HMAC-MD5 Authentication", Work in Progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shen & Smit                  Informational                      [Page 3]
+
+RFC 2763                    Dynamic Hostname               February 2000
+
+
+8. Authors' Addresses
+
+   Naiming Shen
+   Siara Systems, Inc.
+   1195 Borregas Avenue
+   Sunnyvale, CA, 94089
+
+   EMail: naiming@siara.com
+
+
+   Henk Smit
+   Cisco Systems, Inc.
+   170 Tasman Drive
+   San Jose, CA, 95134
+
+   EMail: hsmit@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shen & Smit                  Informational                      [Page 4]
+
+RFC 2763                    Dynamic Hostname               February 2000
+
+
+9. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shen & Smit                  Informational                      [Page 5]
+