[要約] RFC 5642は、OSPFのための動的ホスト名交換メカニズムに関する規格です。このRFCの目的は、OSPFルーター間でホスト名を動的に交換するための手法を提供することです。
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
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ルーターからRouter-IDマッピング情報をOSPFネットワーク全体にフラッディングできるようにする新しいOSPFルーター情報（RI）TLVを定義して、OSPFを実行しているRouterがシンボリックホスト名について学習するためのシンプルで動的なメカニズムを提供します。Ruterが実行されているように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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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の数値表現（例えば、点線系または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.
この問題を克服する1つの方法は、ルーターにホスト名からルーターへのマッピングテーブルを定義することです。このマッピングは、双方向（例えば、ルーター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 OSPF Router Information TLV for OSPF, the Dynamic Hostname TLV (see Section 3). This mechanism is applicable to both OSPFv2 and OSPFv3.
このドキュメントは、この問題の可能な解決策を分析し（セクション2を参照）、ダイナミックホスト名TLVであるOSPFの新しいOSPFルーター情報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].
There are various approaches to providing a name-to-Router-ID mapping service.
Name-to-Router-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.
このマッピングのテーブルを構築する1つの方法は、静的定義によるものです。静的定義の問題は、ネットワーク管理者がネットワークが変更されるにつれてマッピングエントリを手動で更新し続ける必要があることです。ネットワーク内のすべてのルーターに、ネットワーク内のすべてのルーターのマッピングテーブルにエントリが必要である必要があるため、このアプローチはネットワークの成長に合わせて拡大しません。したがって、このアプローチは、保守性とスケーラビリティの考慮事項に大きく苦しんでいます。
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.
別のアプローチは、名前からルーターへのマッピングを保持できる集中場所を持つことです。これには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]).
このドキュメントで定義した3番目のソリューションは、プロトコル自体を利用して、TLVで名前からルーターへのマッピングを運ぶことです。このTLVを理解しているルーターは、それを使用してシンボリックな名前からルーターへのマッピングを作成でき、それを理解していないルーターは単純に無視できます。この仕様は、OSPFV2およびOSPFV3のこれらのセマンティクスとマッピングメカニズムを提供し、OSPFルーター情報（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.
この拡張機能は、新しいOSPFルーター情報（RI）TLV：動的ホスト名TLVを定義することにより、OSPFV2とOSPFV3の両方で[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オクテットの文字列、ゼロから4-OCTETアライメントでパッドでパッドで、US-ASCIIチャーセットにエンコードされています。
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.
値フィールドは、LSAを発信するルーターのシンボリックホスト名を識別します。このシンボリック名は、ルーターIDの完全な資格のあるドメイン名（FQDN）であり、FQDNのサブセットであるか、オペレーターがルーターに使用したい文字列にすることができます。FQDNまたはそのサブセットの使用は、OSPFの動的ホスト名とDNSホスト名を相関させることが有益である可能性があるため、強くお勧めします。DNSホスト名の形式は[RFC1035]および[RFC2181]で説明されています。ルーターIDにdnsホスト名がない場合、ルーターIDがIPv4 addressedエンティティにマッピングしない場合（例：セクション4を参照）、または代替のOSPFダイナミックホスト名の命名条約が望ましい場合、OSPFルーティングドメインを使用できます。文字列はヌル終端ではありません。このルーターのルーター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.
値フィールドは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） - スコープルーター情報（RI）LSA内で宣伝できます。ただし、LSAの範囲に関係なく、動的ホスト名TLVを複数の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エリアスコープ以外）を発信する場合、ASScoped Dynamic HostName 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.
ルーターがASSCOPE LSA（動的ホスト名TLV RI LSAを除く）を宣伝している場合、そのようなルーターは動的ホスト名TLV ri LSAを範囲として宣伝する必要があります。それ以外の場合は、エリアスコープで動的ホスト名TLV RI LSAを宣伝する必要があります。たとえば、AS Boundary Router（ASBR）はAS-Scope Dynamic HostName 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は、S1ビットセットを備えたOSPFV2タイプ10 RILSAまたはOSPFV3 RI LSA内で携帯する必要があり、S2ビットがクリアする必要があります。洪水スコープがルーティングドメイン全体（スコープとして）である場合、動的ホスト名TLVは、S1ビットクリアとS2ビットセットを備えたOSPFV2タイプ11 RI LSAまたはOSPFV3 RI LSA内で運ばなければなりません。
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の幅広い展開により、Native IPv4-AddressのインターフェイスがないOSPFネットワークが存在する可能性が非常に高いです。その結果、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 addressedエンティティにマッピングされず、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.
Hostname-to-Router-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 Dynamic HostNameとしての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）TLVS」レジストリ[IANA-RI]を維持しています。追加のOSPFルーター情報TLVタイプは、セクション3で定義されています。これは、標準アクション割り当て範囲[RFC4970]からIANAによって割り当てられています。
Registry Name: OSPF Router Information (RI) TLVs
レジストリ名：OSPFルーター情報（RI）TLVS
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].
この文書の著者は、説明されているアイデアの独創性について主張していません。このドキュメントは、IS-IS [RFC5301]（廃止[RFC2763]）で行われた同様の作業の形式とテキストを適合させます。[RFC2763]の著者であるNaiming ShenとHenk Smitに感謝します。
The authors would also like to thank Acee Lindem, Abhay Roy, Anton Smirnov, and Dave Ward for their valuable comments and suggestions.
著者はまた、貴重なコメントと提案をしてくれたAcee Lindem、Abhay Roy、Anton Smirnov、Dave Wardに感謝します。
[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月。
[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.、Shen、N.、Vasseur、JP。、Aggarwal、R.、およびS. Shaffer、「オプションのルーター機能の広告のためのOSPFへの拡張」、RFC 4970、2007年7月。
[IANA-RI] Internet Assigned Numbers Authority, "Open Shortest Path First v2 (OSPFv2) Parameters", <http://www.iana.org>.
[IANA-RI]インターネットが割り当てられた番号の権限、「Open Shortest Path First 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.
[RFC2181] Elz、R。およびR. Bush、「DNS仕様の説明」、RFC 2181、1997年7月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、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] 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月。
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006.
[RFC4552] Gupta、M。およびN. Melam、「OSPFV3の認証/機密性」、RFC 4552、2006年6月。
[RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange Mechanism for IS-IS", RFC 5301, October 2008.
[RFC5301] McPherson、D。およびN. Shen、「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.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、2008年7月。
Authors' Addresses
著者のアドレス
Subbaiah Venkata Google Inc.
Subbaiah Venkata Google Inc.
EMail: svenkata@google.com
URI: http://www.google.com
Sanjay Harwani Cisco Systems
Sanjay Harwani Cisco Systems
EMail: sharwani@cisco.com
URI: http://www.cisco.com
Carlos Pignataro Cisco Systems
Carlos Pignataro Cisco Systems
EMail: cpignata@cisco.com
URI: http://www.cisco.com
Danny McPherson Arbor Networks, Inc.
EMail: danny@arbor.net