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.
この文書は、単に、OSPFルータがシンボリックホスト名について学ぶためにOSPFを実行するルータのためのシンプルかつダイナミックなメカニズムを提供するために、OSPFネットワークを介してそのホスト名からルータ-IDのマッピング情報をあふれさせることを可能にする新しいOSPFルータ情報（RI）TLVを定義します以下のようなルータの実行のためにIS-IS。このメカニズムは、OSPFv2のと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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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 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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
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
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.
OSPFは一意表し、ネットワーク内のノードを識別するために、32ビットのルータIDを使用します。管理および運用上の理由から、ネットワークオペレータは、OSPFの隣接関係の状態、ルーティングテーブルのエントリ、およびOSPFリンクステートデータベースの内容を確認する必要があります。診断情報を見たときに、ルータIDの数値表現（例えば、ドット付き10進数または16進数表現）はシンボル名より人間にあまり明らかです。
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.
この問題を克服する一つの方法は、ルータ上でホスト名からルータ-IDマッピングテーブルを定義することです。このマッピングは、（例えば、ルータIDのシンボル名を検索し、シンボル名のためのルータIDを見つけるために）単一または（例えば、ルータIDのシンボリックホスト名を見つけるために）双方向に用いることができます。このように、すべてのルータは、ルータ名とルータIDの間のマッピングを持つテーブルを維持しなければなりません。
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.
これらのテーブルは、ネットワーク内のすべてのルータのすべての名前とルータIDを含める必要があります。これらのマッピングテーブルは、静的な定義によって構築されている場合は、それが現在動作ネットワークのマニュアルと退屈なプロセスになることができます。追加、削除、または変更が発生したときに、これらの静的マッピングエントリを変更すると、エラーすることが非常に発生しやすい非スケーラブルなプロセスとなります。
This document analyzes possible solutions to this problem (see Section 2) and provides a way to populate tables by defining a new
この文書では、この問題に対する可能な解決策を分析する（第2節を参照）、新しいを定義することによって、表に移入する方法を提供します
OSPF Router Information TLV for OSPF, the Dynamic Hostname TLV (see Section 3). This mechanism is applicable to both OSPFv2 and OSPFv3.
OSPFのためのOSPFルータ情報TLV、ダイナミックホスト名TLV（セクション3を参照）。このメカニズムは、OSPFv2のとOSPFv3の両方に適用可能です。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
There are various approaches to providing a name-to-Router-ID mapping service.
名前とルータ-IDマッピングサービスを提供するための様々なアプローチがあります。
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.
別のアプローチは、名前とルータ-IDマッピングを維持することができる中央の場所を有しています。 DNSは、このために使用することができます。この集中溶液の欠点は、それが単一障害点であるということです。中央のマッピングサービスの強化された可用性を設計することができるが、問題解決の時間で特に問題となることが到達可能性やネットワークの問題、のイベントでホスト名を解決できない場合があります。また、応答時間も同様に問題となる可能性が集中溶液、の問題であることができます。 DNSは、集中型のマッピングテーブルとして使用される場合、ネットワークオペレータは、DNS内の既存のマッピングとは異なる名前マッピングを望むことができる、または新しいルータは、まだ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).
さらに、ネイティブIPv6展開でのOSPFv3のために、32ビットルータID値は、ネットワーク内のIPv4アドレス指定エンティティにマップしないであろう、またそれは、DNS解決を（セクション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]).
私たちは、この文書で定義されている第三の溶液は、TLVで名前ツールータ-IDのマッピングを運ぶためにプロトコル自体を利用することです。それを理解していないこのTLVがシンボリック名・ツー・ルータ-IDのマッピングを作成するためにそれを使用することができます理解ルータ、およびルータは、単にそれを無視することができます。この仕様は、OSPFルータ情報を活用する、のOSPFv2とOSPFv3のためのこれらのセマンティクスとのマッピング機構を提供する（RI）リンク状態広告（LSA）（[RFC4970]）。
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.
ダイナミックホスト名TLV：この拡張モジュールは、OSPFv2のとOSPFv3の両方のために、新しいOSPFルータ情報（RI）TLVを定義することによって、[RFC4970]で定義されたルータ情報（RI）オペークLSAの使用を行います。
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.
ダイナミックホスト名TLV（セクション3.1を参照）はオプションです。 TLVを受信すると、ルータはこのTLVを無視するか、そのホスト名のマッピングテーブルにシンボリック名およびルータIDをインストールすることもできます。
The format of the Dynamic Hostname TLV is as follows:
次のようにダイナミックホスト名TLVの形式は次のとおりです。
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)
ダイナミックホスト名TLVタイプ入力します（7; 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.
値ホスト名、1〜255オクテットの文字列は、US-ASCII文字セットでエンコードされた4オクテットのアライメントに0でパディング。
Routers that do not recognize the Dynamic Hostname TLV Type ignore the TLV (see [RFC4970]).
ダイナミックホスト名TLVタイプTLV（[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.
Valueフィールドは、LSAを発信するルータのシンボリックホスト名を識別します。このシンボル名は、ルータIDの完全修飾ドメイン名（FQDN）することができ、それはFQDNのサブセットであることができ、または事業者がルータで使用することを任意の文字列を指定できます。 OSPFダイナミックホスト名とDNSホスト名を関連付けることが有益であり得るので、FQDNまたはそのサブセットを使用することを強くお勧めします。 DNSホスト名の形式は、[RFC1035]及び[RFC2181]に記載されています。ルータIDは、IPv4アドレス指定エンティティにマップされない場合、ルータのIDのためのDNSホスト名が存在しない場合（例えば、第4節を参照）、または代替OSPF動的ホスト名の命名規則は、所望される場合、に意義のある任意の文字列OSPFルーティングドメインを使用することができます。文字列は、NULLで終了ではありません。このルータのルータIDは、ルータ情報（RI）オペークLSAの広告ルータフィールドに、LSAヘッダから導出されます。
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 applicable to both OSPFv2 and OSPFv3.
ダイナミックホスト名TLVは、OSPFv2のとOSPFv3の両方に適用可能です。
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.
ダイナミックホスト名TLVは、地域ローカルまたは自律システム（AS）-scopeルータ情報（RI）LSA内に通知されるかもしれません。しかし、ダイナミックホスト名TLVは関係なく、LSAの範囲の、複数のRI 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.
ルータは、IGPドメイン（AS）フラッディングスコープでダイナミックホスト名TLVを発信言い換えれば、それは任意の添付なし準スタブエリア（NSSA）エリア（複数可）に除いエリアスコープのダイナミックホスト名TLVを送るべきではありません。ルータがエリアスコープのダイナミックホスト名TLV（NSSAエリアはスコープ以外）を発信する場合は同様に、それはASスコープのダイナミックホスト名TLVを送るべきではありません。ダイナミックホスト名TLVが複数のLSA（例えば、複数のエリアスコープのLSA、またはASスコープのLSAプラスNSSAエリアスコープLSA（S））でアドバタイズされた場合、ホスト名が同じでなければなりません。
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.
ルータが（ダイナミックホスト名TLV RI LSA以外の）AS-スコープのLSAの広告を出している場合は、そのようなルータは、スコープASにダイナミックホスト名TLV RI LSAを宣伝すべきです。それ以外の場合は、エリアスコープにダイナミックホスト名TLV RI LSAを宣伝すべきです。例えば、AS境界ルータ（ASBR）は、AS-範囲ダイナミックホスト名TLVを送信すべきである領域境界ルータ一方（のABR）と内部ルータはエリア範囲ダイナミックホスト名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.
氾濫範囲はOSPFv2の不透明なLSAのタイプによってとのOSPFv3でS1とS2のビットによって制御されます。エリア範囲のために、ダイナミックホスト名TLVはOSPFv2のタイプ内で実施しなければならない10のRI LSAまたはS1とOSPFv3のRI LSAのセットとS2ビットがクリアビット。氾濫範囲は（スコープAS）全体のルーティングドメインである場合、動的ホスト名TLVはクリアS1ビットとOSPFv2のタイプ11のRI LSAまたはOSPFv3のRI LSA内で実施しなければならないとS2は、ビットセット。
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 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.
ダイナミックホスト名TLVを含むOSPFルータ情報（RI）LSAは、複数のOSPFインスタンスでアドバタイズされた場合、ホスト名がいずれかの保存または共通のベース要素を含むされるべきです。これは、デバッグまたは別々のインスタンスを特定のインスタンスに関連付けることができる接尾辞または接頭辞の一貫したセットと異なるホスト名を割り当てるために、他の目的のために有用である可能性がある - 特に、インスタンスが別個のアドレスファミリーまたは非ルーティングに使用された場合情報。
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.
両方のOSPFv2とOSPFv3は、32ビットの共通のサイズでルータIDを使用します。 IPv4では、ルータIDの値は、典型的には、IPv4アドレスから自動的に導出されたいずれかのOSPFプロセス構成内で定義されたループバック又は明示的ローカル・システムで定義された、または物理インターフェイスに設定します。 IPv6のより広範な展開と、それはOSPFネットワークはネイティブのIPv4アドレス指定のインターフェイスを持っていないことが存在するということは非常に可能性があります。結果として、32ビットのOSPFルータIDを明示的に指定するか、ローカルルーティングドメイン内の他のOSPFルータとの衝突を回避するいくつかの自動的な方法で導出される必要があります。
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.
この32ビット値は、ネットワーク内のIPv4アドレス指定エンティティにマップしないであろう、またそれが解決DNSされるので、いくつかのメカニズムがより容易値を解釈するためにOSPFルータIDをマップするために存在することを運用の観点から非常に望ましいと考えられます - 理想的には、人間が読める文字列。この仕様は、それ以外のIPv6のネイティブの展開を導入してもよい運用の負担を緩和するマッピング機能を有効にします。
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.
ホスト・ツー・ルータ-IDマッピングがルータ自身によって提供される情報に依存しているので、設定ミスや損なわルータが別のルータIDの重複したホスト名を含む、偽マッピング情報を注入することができます。したがって、この情報は、例えば、疑わしいセキュリティインシデントに関する診断を行う際に、疑いで処理する必要があります。
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.
2つのルータに同じ動的ホスト名を使用して広告を出す場合は、名前の衝突からの潜在的な混乱があります。名前の競合は重要ではないので、プロトコルには、一般的な競合の検出または解決メカニズムは存在しません。しかし、受け取ったホスト名がローカルのものと同じであることを検出したルータは、通知または管理警告を発行することができます。
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.
OSPFダイナミックホスト名とFQDNを使用することは、潜在的に平文で送信する場合、ホスト名から推定することができる地理的またはその他の商業情報を公開します。 OSPFv3は、トランスポートモードのIPsec（[RFC4552]を参照）を介して機密性をサポートしています。機密性が必要な場合は、OSPFv2は、IPsecトンネルを介して操作することができます。
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.
この文書では、OSPFのための他の新しいセキュリティ問題を提起していません。ベースOSPFプロトコルのためのセキュリティ上の考慮事項は、[RFC2328]と[RFC5340]でカバーされています。 OSPFルーティングプロトコルの認証を使用することが奨励されています。
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].
IANAは、 "OSPFルータ情報（RI）のTLV" レジストリ[IANA-RI]を維持しています。追加のOSPFルータ情報TLVタイプは、それが標準化アクション割り当て範囲[RFC4970]からIANAによって割り当てられている第3節で定義されています。
Registry Name: OSPF Router Information (RI) TLVs
レジストリ名：OSPFルータ情報（RI）のTLV
Type Value Capabilities Reference
----------- -------------------------------------- ---------
7 OSPF Dynamic Hostname This document
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].
本書の著者は述べたアイデアの独創性に申し立てを行うことはありません。この文書では、（[RFC2763]を時代遅れ）IS-IS [RFC5301]で行わ同様の作業からフォーマットとテキストを適合させます。我々はNaimingシェンとヘンクスミット、[RFC2763]の著者に感謝したいと思います。
The authors would also like to thank Acee Lindem, Abhay Roy, Anton Smirnov, and Dave Ward for their valuable comments and suggestions.
著者はまた、彼らの貴重なコメントや提案のためACEE Lindem、アブヘイロイ、アントン・スミルノフ、とデイブ・ワードに感謝したいと思います。
[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月。
[RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 4970, July 2007.
[RFC4970] Lindem、A.、シェン、N.、Vasseur、JPは。、アガルワル、R.、およびS.シェイファー、 "広告オプションのルータの機能のためのOSPFへの拡張"、RFC 4970、2007年7月。
[IANA-RI] Internet Assigned Numbers Authority, "Open Shortest Path First v2 (OSPFv2) Parameters", <http://www.iana.org>.
[IANA-RI]インターネット割り当て番号機関、 "オープン最短パスファーストv2の（OSPFv2の）パラメータ"、<http://www.iana.org>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
"DNS仕様の明確化" [RFC2181]エルツ、R.とR.ブッシュ、RFC 2181、1997年7月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[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月。
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006.
[RFC4552]グプタ、M.およびN.メラム、 "OSPFv3のための認証/機密性"、RFC 4552、2006年6月。
[RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange Mechanism for IS-IS", RFC 5301, October 2008.
[RFC5301]マクファーソン、D.およびN.シェン、 "IS-ISのための動的ホスト名交換メカニズム"、RFC 5301、2008年10月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340] Coltun、R.、ファーガソン、D.、モイ、J.、およびA. Lindem、 "IPv6のためのOSPF"、RFC 5340、2008年7月。
Authors' Addresses
著者のアドレス
Subbaiah Venkata Google Inc.
ヴェンカタSubbaiahグーグル株式会社
EMail: svenkata@google.com URI: http://www.google.com
電子メール：svenkata@google.com URI：http://www.google.com
Sanjay Harwani Cisco Systems
サンジャイHarwaniシスコシステムズ
EMail: sharwani@cisco.com URI: http://www.cisco.com
電子メール：sharwani@cisco.com URI：http://www.cisco.com
Carlos Pignataro Cisco Systems
カルロスPignataroシスコシステムズ
EMail: cpignata@cisco.com URI: http://www.cisco.com
電子メール：cpignata@cisco.com URI：http://www.cisco.com
Danny McPherson Arbor Networks, Inc.
ダニー・マクファーソンアーバーネットワークス株式会社
EMail: danny@arbor.net
メールアドレス：danny@arbor.net