Network Working Group D. McPherson
Request for Comments: 5301 Arbor Networks
Obsoletes: 2763 N. Shen
Category: Standards Track Cisco Systems
October 2008
Dynamic Hostname Exchange Mechanism for IS-IS
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
RFC 2763 defined a simple and dynamic mechanism for routers running IS-IS to learn about symbolic hostnames. RFC 2763 defined a new TLV that allows the IS-IS routers to flood their name-to-systemID mapping information across the IS-IS network.
RFC 2763には、実行しているルータのためのシンプルかつダイナミックなメカニズムがシンボリックホスト名について学ぶためにIS-IS定義されました。 RFC 2763は、IS-ISルータは、IS-ISネットワーク経由で自分の名前からsystemIDをマッピング情報をあふれさせることを可能にする新しいTLVを定義しました。
This document obsoletes RFC 2763. This document moves the capability provided by RFC 2763 to the Standards Track.
この文書は、この文書では、標準化過程にRFC 2763が提供する機能を移動RFC 2763.廃止します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
2. Possible Solutions ..............................................2
3. Dynamic Hostname TLV ............................................3
4. Implementation ..................................................4
5. Security Considerations .........................................4
6. Acknowledgments .................................................4
7. IANA Considerations .............................................4
8. Informative References ..........................................4
IS-IS uses a variable 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 system IDs and Link State Protocol Data Unit (LSP) identifiers are less clear than symbolic names.
IS-ISは、ネットワーク内のノードを表すために変数1-8バイトのシステムID（通常は6バイト）を使用します。管理・運用上の理由から、ネットワークオペレータは、IS-IS隣接関係、ルーティングテーブルのエントリ、およびIS-ISリンク状態データベースの内容のステータスをチェックする必要があります。診断情報を見たときに、システムIDおよびリンクステートプロトコルデータユニット（LSP）の識別子を16進数表現がシンボリック名未満明確である、ことは明らかです。
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 system IDs and to find system IDs 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.
この問題を克服する一つの方法は、ルータ上で、名前からsystemIDをマッピングを定義することです。このマッピングは、システムIDのシンボリック名を見つけ、シンボリック名のためのシステムIDを見つけるために、例えば、双方向で使用することができます。マッピングのこのテーブルを構築するための一つの方法は、静的な定義です。彼らのIGPとしてIS-ISを使用するネットワーク管理者の中で、そのような静的マッピングを定義するために、現在の慣行です。
Thus, every router has to maintain a statically-configured table with mappings between router names and system IDs. These tables need to contain the names and system IDs of all routers in the network, and must be modified each time an addition, deletion, or change occurs.
このように、すべてのルータは、ルータ名およびシステムIDの間のマッピングで静的に構成されたテーブルを維持しなければなりません。これらのテーブルは、ネットワーク内のすべてのルータの名前とシステムIDが含まれている必要があり、追加、削除、または変更されるたびに変更する必要があります。
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 provide a third solution, which in wide-scale implementation and deployment has proven to be easier and more manageable than static mapping or DNS schemes.
1は、このようなテーブルを構築することができ、いくつかの方法があります。一つは、静的な構成を介しています。実装することができ、別の方式では、DNSルックアップを介しています。この文書では、我々は大規模な実装と展開で静的マッピングまたはDNSスキームより簡単に、より管理しやすいことが証明されている第三ソリューションを提供します。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
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, on every 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 system ID of one router, or adding a new router will affect the configurations of all the other routers on the network. This will make it very likely that those static tables are outdated.
マッピングの静的な構成の明らかな欠点は、拡張性と保守性の問題です。ネットワークオペレータは、名前のテーブルを維持しなければなりません。彼らは、ネットワーク内のすべてのルータで、ネットワーク内のすべてのルータのためのテーブルにエントリを維持する必要があります。これらの静的テーブルを作成し、維持するための努力は、ネットワーク上のルータの合計数と成長します。 1つのルータの名前またはシステムIDを変更するか、新しいルータを追加すると、ネットワーク上の他のすべてのルータの構成に影響を与えます。これは、これらの静的テーブルが古くなっていること、それは非常に可能性が高いでしょう。
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 Connection Network Service (CLNS) Network Service Access Points (NSAPs).
中心的な場所で更新することができる一つのテーブルを持つことは有用であろう。一つは、このためにDNSシステムを使用して想像できます。欠点は、ネットワークの問題の時間の間に、DNSサービスの応答時間が十分ではないかもしれないか、DNSサービスも利用できない場合がありますということです。別の可能な欠点は、DNSの追加複雑かもしれません。また、一部のDNS実装は、接続ネットワークサービス（CLNS）ネットワークサービスアクセスポイント（NSAPを）のためにAおよびPTRレコードをサポートしていない可能性があります。
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 PDUs. This document defines a new TLV that allows the IS-IS routers to include the name-to-systemID mapping data in their LSPs. This will allow simple and reliable transport of name mapping information across the IS-IS network.
動的なマッピングを構築するための第三の方法は、IS-ISリンクステートPDUの中でシンボル名を宣伝するために、ルーティングプロトコル自体のトランスポート機構を使用することです。この文書では、IS-ISルータが自分のLSPで、名前からsystemIDをマッピングデータを含めることができる新しいTLVを定義します。これは、IS-ISネットワーク全体名のマッピング情報を簡単かつ確実な輸送を可能にします。
The Dynamic hostname TLV is defined here as TLV type 137.
ダイナミックホスト名TLVはTLVタイプ137としてここで定義されています。
Length - total length of the value field.
長さ - 値フィールドの長さの合計。
Value - a string of 1 to 255 bytes.
値 - 1〜255バイトの文字列。
The Dynamic hostname TLV is optional. This TLV may be present in any fragment of a non-pseudonode 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 it can be any string operators want to use for the router. The use of FQDN or a subset of it is strongly recommended. The content of this value is a domain name, see [RFC2181]. The string is not null-terminated. The system ID of this router can be derived from the LSP identifier.
ダイナミックホスト名TLVはオプションです。このTLVは、非擬似LSPの任意の断片中に存在してもよいです。値フィールドは、LSPを発信側ルータのシンボル名を識別します。このシンボル名は、ルータのFQDNすることができ、それはFQDNのサブセットであることができ、またはそれは、オペレータがルータに使用する任意の文字列を指定できます。 FQDNまたはそれのサブセットを使用することを強くお勧めします。この値の内容は、ドメイン名である、[RFC2181]を参照してください。文字列は、NULLで終了ではありません。このルータのシステムIDは、LSP識別子から導出することができます。
If this TLV is present in a pseudonode LSP, then it SHOULD NOT be interpreted as the DNS hostname of the router.
このTLVは、擬似ノードLSPに存在する場合、それはルータのDNSホスト名として解釈されるべきではありません。
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.
Valueフィールドは7ビットASCIIで符号化されます。構成またはこのフィールドを表示するためのユーザインタフェースは、Unicode文字を許可する場合、そのユーザインターフェイスは、送信又は表示するための正しいフォーマットを達成するために、[RFC3490]に記載されているようにもしToASCII及び/又はのToUnicodeアルゴリズムを適用する責任があります。
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 system ID in its hostname mapping table for the IS-IS network.
ダイナミックホスト名TLVはオプションです。 LSPを発信すると、ルータはそのLSPにこのTLVを含めることを決定することができます。ダイナミックホスト名TLVとLSPを受信すると、ルータはこのTLVを無視する、またはIS-ISネットワークのホスト名のマッピングテーブルにシンボリック名およびシステムIDをインストールすることもできます。
A router may also optionally insert this TLV in its pseudonode LSP for the association of a symbolic name to a local LAN.
ルータはまた、必要に応じて、ローカルLANへのシンボリック名の関連付けのために、その擬似LSPにこのTLVを挿入することができます。
If a system receives a mapping for a name or system ID that is different from the mapping in the local cache, an implementation SHOULD replace the existing mapping with the latest information.
システムは、ローカルキャッシュ内のマッピングと異なる名前またはシステムIDのマッピングを受信した場合、実装は、最新の情報と既存のマッピングを置き換える必要があります。
Since the name-to-systemID mapping relies on information provided by the routers themselves, a misconfigured or compromised router can inject false mapping information. Thus, this information needs to be treated with suspicion when, for example, doing diagnostics about a suspected security incident.
名前からsystemIDをマッピングは、ルータ自身によって提供された情報に依存しているため、誤設定または妥協ルータが偽のマッピング情報を注入することができます。したがって、この情報は、例えば、疑わしいセキュリティインシデントに関する診断を行う際に、疑いで処理する必要があります。
This document raises no other new security issues for IS-IS. Security issues with IS-IS are discussed in [RFC5304].
この文書では、IS-ISのための他の新しいセキュリティ問題を提起していません。 IS-ISとセキュリティの問題は、[RFC5304]で議論されています。
The original efforts and corresponding acknowledgements provided in [RFC2763] have enabled this work. In particular, we'd like to acknowledge Henk Smit as an author of that document.
[RFC2763]に提供されたオリジナルの努力とそれに対応する確認応答は、この作業を有効にしています。特に、我々は、その文書の著者としてヘンクスミットを承認したいと思います。
This document specifies TLV 137, "Dynamic Name". This TLV has already been allocated and reserved [RFC2763]. As such, no new actions are required on the part of IANA.
この文書では、TLV 137、「動的名」を指定します。このTLVは、すでに割り当てられ、[RFC2763]を予約されています。そのため、新しいアクションはIANAの一部には必要ありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
"DNS仕様の明確化" [RFC2181]エルツ、R.とR.ブッシュ、RFC 2181、1997年7月。
[RFC2763] Shen, N. and H. Smit, "Dynamic Hostname Exchange Mechanism for IS-IS", RFC 2763, February 2000.
[RFC2763]シェン、N.およびH.スミット、 "IS-ISのための動的ホスト名交換メカニズム"、RFC 2763、2000年2月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、 "アプリケーションにおける国際化ドメイン名（IDNA）"、RFC 3490、2003年3月。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.
[RFC5304]李、T.、およびR.アトキンソンは、 "IS-IS暗号認証"、RFC 5304、2008年10月。
Authors' Addresses
著者のアドレス
Danny McPherson Arbor Networks, Inc. EMail: danny@arbor.net
ダニー・マクファーソンアーバーネットワークス株式会社Eメール：danny@arbor.net
Naiming Shen Cisco Systems, Inc. EMail: naiming@cisco.com
Naimingシェンシスコシステムズ、株式会社Eメール：naiming@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78および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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。