RFC5301 日本語訳
5301 Dynamic Hostname Exchange Mechanism for IS-IS. D. McPherson, N.Shen. October 2008. (Format: TXT=11740 bytes) (Obsoletes RFC2763) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. McPherson
Request for Comments: 5301 Arbor Networks
Obsoletes: 2763 N. Shen
Category: Standards Track Cisco Systems
October 2008
コメントを求めるワーキンググループD.マクファーソン要求をネットワークでつないでください: 5301のあずまやネットワークが以下を時代遅れにします。 2763年のN.シンカテゴリ: 標準化過程シスコシステムズ2008年10月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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.
RFC2763がルータ走りのために簡単でダイナミックなメカニズムを定義した、-、シンボリックなホスト名に関して学ぶために。 RFC2763がそれが許容する新しいTLVを定義した、-、ルータ、名前からsystemIDへのそれらのマッピング情報を横切ってあふれさせる、-、ネットワーク
This document obsoletes RFC 2763. This document moves the capability provided by RFC 2763 to the Standards Track.
このドキュメントはRFC2763を時代遅れにします。 このドキュメントはRFC2763によってStandards Trackに提供された能力を動かします。
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
1. 序論…2 1.1. 要件の仕様…2 2. 可能なソリューション…2 3. ダイナミックなホスト名TLV…3 4. 実装…4 5. セキュリティ問題…4 6. 承認…4 7. IANA問題…4 8. 有益な参照…4
McPherson & Shen Standards Track [Page 1] RFC 5301 Dynamic Hostname October 2008
マクファーソンとシンStandardsはダイナミックなホスト名2008年10月にRFC5301を追跡します[1ページ]。
1. Introduction
1. 序論
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.
-、ネットワークでノードを表すのに、システムID(通常6バイト)を1変数1-8バイト使用します。 管理と操作理由で、状態をチェックするオペレータの必要性をネットワークでつないでください、-、隣接番組、経路指定テーブル、および内容におけるエントリー、-、リンク州のデータベース。 それが明白である、それ、病気の特徴を見る、情報、システムIDとLink州プロトコルData Unit(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.
この問題を克服する1つの方法は名前からsystemIDへのルータに関するマッピングを定義することです。 例えばシステムIDに関して英字名を見つけて、英字名に関してシステムIDを見つけるのに双方向にこのマッピングを使用できます。 マッピングのこのテーブルを組立てる1つの方法は定義します静的な。 ネットワーク管理者、だれ、使用、-、彼らの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体系よりさらに簡単であって、処理しやすいと判明しました)。
1.1. Specification of Requirements
1.1. 要件の仕様
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Possible Solutions
2. 可能なソリューション
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を変えるか、または新しいルータがネットワークの他のすべてのルータの構成に影響すると言い足します。 これで、それらの静的なテーブルが時代遅れであることが非常にありそうになるでしょう。
McPherson & Shen Standards Track [Page 2] RFC 5301 Dynamic Hostname October 2008
マクファーソンとシンStandardsはダイナミックなホスト名2008年10月にRFC5301を追跡します[2ページ]。
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実装は、AとPTRがConnection Network Service(CLNS)ネットワークService Access Points(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 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番目の方法が英字名の広告を出すルーティング・プロトコル自体の移送機構を使用するだろうことである、-、リンク州のPDUs。 このドキュメントがそれが許容する新しいTLVを定義する、-、ルータ、それらのLSPsの名前からsystemIDへのマッピングデータを含むように。 これが横切って名前マッピング情報の簡単で信頼できる輸送を許容する、-、ネットワーク。
3. Dynamic Hostname TLV
3. ダイナミックなホスト名TLV
The Dynamic hostname TLV is defined here as TLV type 137.
Dynamicホスト名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.
Dynamicホスト名TLVは任意です。 このTLVは非pseudonode LSPのどんな断片にも存在しているかもしれません。 値の分野はLSPを溯源するルータの英字名を特定します。 この英字名がルータのためのFQDNであるかもしれない、それはFQDNの部分集合であるかもしれませんかそれが列演算子がルータに使用したがっているいずれであることができますも。 FQDNの使用かそれの部分集合が強く推薦されます。 [RFC2181]は、この価値の内容がドメイン名であると考えます。 ストリングは終えられた状態でヌルではありません。 LSP識別子からこのルータのシステムIDを得ることができます。
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に存在していて、次に、それはSHOULD NOTです。ルータに関する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でコード化されます。 この野原を構成するか、または表示するためのユーザーインタフェースがユニコード文字を可能にするなら、そのユーザーインタフェースはトランスミッションかディスプレイのための正しい形式を達成するために[RFC3490]で説明されるようにToASCII、そして/または、ToUnicodeアルゴリズムを適用するのに原因となります。
McPherson & Shen Standards Track [Page 3] RFC 5301 Dynamic Hostname October 2008
マクファーソンとシンStandardsはダイナミックなホスト名2008年10月にRFC5301を追跡します[3ページ]。
4. Implementation
4. 実装
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.
Dynamicホスト名TLVは任意です。 LSPを溯源するとき、ルータは、LSPにこのTLVを含んでいると決めるかもしれません。 Dynamicホスト名TLVとLSPを受け取り次第ルータが、このTLVを無視するか、または英字名とシステム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への英字名の協会のために任意にこのTLVをpseudonode LSPに挿入するかもしれません。
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のために、SHOULDは既存のマッピングを最新情報に取り替えます。
5. Security Considerations
5. セキュリティ問題
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へのマッピングがルータ自体によって提供された情報を当てにするので、misconfiguredされたか感染しているルータは誤ったマッピング情報を注入できます。 したがって、この情報は、例えば、疑われたセキュリティインシデントに関する病気の特徴をするとき、容疑で扱われる必要があります。
This document raises no other new security issues for IS-IS. Security issues with IS-IS are discussed in [RFC5304].
このドキュメントが他のどんな新しい安全保障問題も提起しない、- 安全保障問題、-、[RFC5304]では、議論します。
6. Acknowledgments
6. 承認
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]に提供されたオリジナルの取り組みと対応する承認はこの仕事を可能にしました。 特に、そのドキュメントの作者としてヘンク・スミットを承認したいと思います。
7. IANA Considerations
7. IANA問題
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.
TLV137、「ダイナミックな名前」をこのドキュメントは指定します。 このTLVは既に割り当てられて、予約されました[RFC2763]。 そういうものとして、どんな新しい動きもIANA側の必要ではありません。
8. Informative References
8. 有益な参照
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2181] ElzとR.とR.ブッシュ、「DNS仕様への明確化」、RFC2181、1997年7月。
[RFC2763] Shen, N. and H. Smit, "Dynamic Hostname Exchange Mechanism
for IS-IS", RFC 2763, February 2000.
[RFC2763] シン、N.、およびH.スミット、「ダイナミックなホスト名がメカニズムを交換する、-、」、RFC2763、2月2000日
McPherson & Shen Standards Track [Page 4] RFC 5301 Dynamic Hostname October 2008
マクファーソンとシンStandardsはダイナミックなホスト名2008年10月にRFC5301を追跡します[4ページ]。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、「アプリケーション(IDNA)におけるドメイン名を国際的にします」、RFC3490、2003年3月。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, October 2008.
[RFC5304] 李、T.、およびR.アトキンソン、「-、暗号の認証、」、RFC5304、10月2008日
Authors' Addresses
作者のアドレス
Danny McPherson Arbor Networks, Inc. EMail: danny@arbor.net
ダニーマクファーソンあずまやはInc.メールをネットワークでつなぎます: danny@arbor.net
Naiming Shen Cisco Systems, Inc. EMail: naiming@cisco.com
シンシスコシステムズInc.をNaimingして、メールしてください: naiming@cisco.com
McPherson & Shen Standards Track [Page 5] RFC 5301 Dynamic Hostname October 2008
マクファーソンとシンStandardsはダイナミックなホスト名2008年10月にRFC5301を追跡します[5ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
McPherson & Shen Standards Track [Page 6]
マクファーソンとシン標準化過程[6ページ]
一覧
スポンサーリンク
