[要約] RFC 5301はIS-ISのための動的ホスト名交換メカニズムであり、IS-ISルーター間でホスト名を交換するための手法を提供します。目的は、ネットワーク管理者がホスト名を手動で設定する必要なく、ネットワーク内のルーター間でホスト名を自動的に交換することです。
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
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は、実行されているルーターのシンプルで動的なメカニズムを定義し、シンボリックホスト名について学習します。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リンク状態データベースのコンテンツを確認する必要があります。診断情報を見ると、システムIDの16進表現とリンク状態プロトコルデータユニット（LSP）識別子がシンボリック名よりも明確ではないことは明らかです。
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.
この問題を克服する1つの方法は、ルーターで名前からシステムへのマッピングを定義することです。このマッピングは、システムIDのシンボリック名を見つけ、シンボリック名のシステムIDを見つけるために、双方向に使用できます。このマッピングのテーブルを構築する1つの方法は、静的定義です。IS-ISをIGPとして使用するネットワーク管理者の間で、このような静的マッピングを定義することは現在の慣行です。
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つは静的構成を介してです。実装できるもう1つのスキームは、DNSルックアップを介してです。このドキュメントでは、3番目のソリューションを提供します。これは、幅広い実装および展開で、静的マッピングまたは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).
一元化された場所で更新できるテーブルを1つ持っておくことが役立ちます。これに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.
動的マッピングを構築する3番目の方法は、ルーティングプロトコル自体のトランスポートメカニズムを使用して、IS-ISリンク状態のPDUでシンボリック名を宣伝することです。このドキュメントでは、IS-ISルーターがLSPに名前からシステムへのマッピングデータを含めることができる新しい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]を参照してください。文字列はヌル終端ではありません。このルーターのシステム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がPseudonode 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.
値フィールドは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を発信する場合、ルーターはこのTLVをLSPに含めることを決定する場合があります。ダイナミックホスト名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.
ルーターは、オプションで、このTLVをPseudonode LSPに挿入して、シンボリック名とローカルLANに挿入することもできます。
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.
名前からシステムへのマッピングは、ルーター自体が提供する情報に依存しているため、誤った状態または侵害されたルーターは、誤ったマッピング情報を挿入できます。したがって、たとえば、セキュリティ事件の疑いについて診断を行う場合、この情報は疑いで治療する必要があります。
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]で提供される当初の取り組みと対応する謝辞により、この作業が可能になりました。特に、Henk Smitをその文書の著者として認めたいと思います。
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「Dynamic Name」を指定します。このTLVはすでに割り当てられ、予約されています[RFC2763]。そのため、IANAの一部には新しいアクションは必要ありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181] Elz、R。およびR. Bush、「DNS仕様の説明」、RFC 2181、1997年7月。
[RFC2763] Shen, N. and H. Smit, "Dynamic Hostname Exchange Mechanism for IS-IS", RFC 2763, February 2000.
[RFC2763] Shen、N。およびH. Smit、「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.、Hoffman、P。、およびA. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年3月。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.
[RFC5304] Li、T。およびR. Atkinson、「IS-IS暗号認証」、RFC 5304、2008年10月。
Authors' Addresses
著者のアドレス
Danny McPherson Arbor Networks, Inc. EMail: danny@arbor.net
Danny McPherson Arbor Networks、Inc。メール：danny@arbor.net
Naiming Shen Cisco Systems, Inc. EMail: naiming@cisco.com
Naiming Shen Cisco Systems、Inc。電子メール：naiming@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（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.
この文書は、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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。