[要約] RFC 7503は、OSPFv3の自動設定に関する仕様であり、IPv6ネットワークでのOSPFv3の自動設定を可能にするための手法を提供しています。このRFCの目的は、手動での設定作業を減らし、ネットワークの展開と管理を簡素化することです。
Internet Engineering Task Force (IETF) A. Lindem
Request for Comments: 7503 Cisco Systems
Updates: 5340 J. Arkko
Category: Standards Track Ericsson
ISSN: 2070-1721 April 2015
OSPFv3 Autoconfiguration
OSPFv3自動構成
Abstract
概要
OSPFv3 is a candidate for deployments in environments where autoconfiguration is a requirement. One such environment is the IPv6 home network where users expect to simply plug in a router and have it automatically use OSPFv3 for intra-domain routing. This document describes the necessary mechanisms for OSPFv3 to be self-configuring. This document updates RFC 5340 by relaxing the HelloInterval/ RouterDeadInterval checking during OSPFv3 adjacency formation and adding hysteresis to the update of self-originated Link State Advertisements (LSAs).
OSPFv3は、自動構成が必要な環境での展開の候補です。そのような環境の1つはIPv6ホームネットワークで、ユーザーはルーターにプラグインするだけで、ドメイン内ルーティングにOSPFv3を自動的に使用することを期待しています。このドキュメントでは、OSPFv3を自動構成するために必要なメカニズムについて説明します。このドキュメントでは、OSPFv3隣接関係の形成中にHelloInterval / RouterDeadIntervalチェックを緩和し、自己発信リンク状態アドバタイズ（LSA）の更新にヒステリシスを追加することにより、RFC 5340を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7503.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7503で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. OSPFv3 Default Configuration . . . . . . . . . . . . . . . . 4
3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility . . . . . 5
3.1. Wait Timer Reduction . . . . . . . . . . . . . . . . . . 5
4. OSPFv3 Minimal Authentication Configuration . . . . . . . . . 5
5. OSPFv3 Router ID Selection . . . . . . . . . . . . . . . . . 5
6. OSPFv3 Adjacency Formation . . . . . . . . . . . . . . . . . 6
7. OSPFv3 Duplicate Router ID Detection and Resolution . . . . . 6
7.1. Duplicate Router ID Detection for Neighbors . . . . . . . 6
7.2. Duplicate Router ID Detection for Non-neighbors . . . . . 7
7.2.1. OSPFv3 Router Autoconfiguration LSA . . . . . . . . . 7
7.2.2. Router-Hardware-Fingerprint TLV . . . . . . . . . . . 9
7.3. Duplicate Router ID Resolution . . . . . . . . . . . . . 9
7.4. Change to RFC 2328, Section 13.4 ("Receiving
Self-Originated LSAs") . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Management Considerations . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
OSPFv3 [OSPFV3] is a candidate for deployments in environments where autoconfiguration is a requirement. This document describes extensions to OSPFv3 to enable it to operate in these environments. In this mode of operation, the protocol is largely unchanged from the base OSPFv3 protocol specification [OSPFV3]. Since the goals of autoconfiguration and security can be conflicting, operators and network administrators should carefully consider their security requirements before deploying the solution described in this document. Refer to Section 8 for more information.
OSPFv3 [OSPFV3]は、自動構成が必要な環境での展開の候補です。このドキュメントでは、OSPFv3がこれらの環境で動作できるようにするための拡張機能について説明します。この動作モードでは、プロトコルは基本のOSPFv3プロトコル仕様[OSPFV3]からほとんど変更されていません。自動構成とセキュリティの目的は相反する可能性があるため、オペレーターとネットワーク管理者は、このドキュメントで説明するソリューションを展開する前に、セキュリティ要件を慎重に検討する必要があります。詳細については、セクション8を参照してください。
The following aspects of OSPFv3 autoconfiguration are described in this document:
このドキュメントでは、OSPFv3自動設定の次の側面について説明します。
1. Default OSPFv3 Configuration
1. OSPFv3のデフォルト設定
2. HelloInterval/RouterDeadInterval Flexibility
2. HelloInterval / RouterDeadIntervalの柔軟性
3. OSPFv3 Minimal Authentication Configuration
3. OSPFv3最小認証設定
4. Unique OSPFv3 Router ID Generation
4. ユニークなOSPFv3ルーターIDの生成
5. OSPFv3 Adjacency Formation
5. OSPFv3隣接関係の形成
6. Duplicate OSPFv3 Router ID Resolution
6. 重複するOSPFv3ルーターIDの解決
7. Self-Originated LSA Processing
7. 自己発信LSA処理
OSPFv3 [OSPFV3] is updated by allowing OSPFv3 adjacencies to be formed between OSPFv3 routers with differing HelloIntervals or RouterDeadIntervals (refer to Section 3). Additionally, hysteresis has been added to the processing of stale self-originated LSAs to mitigate the flooding overhead created by an OSPFv3 Router with a duplicate OSPFv3 Router ID in the OSPFv3 routing domain (refer to Section 7.4). Both updates are fully backward compatible.
OSPFv3 [OSPFV3]は、異なるHelloIntervalsまたはRouterDeadIntervalsを持つOSPFv3ルーター間でOSPFv3隣接関係を形成できるようにすることで更新されます（セクション3を参照）。さらに、OSPFv3ルーティングドメインでOSPFv3ルーターIDが重複しているOSPFv3ルーターによって生じるフラッディングオーバーヘッドを軽減するために、古い自己発信LSAの処理にヒステリシスが追加されています（セクション7.4を参照）。どちらのアップデートも完全に下位互換性があります。
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-KEYWORDS].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC-KEYWORDS]で説明されているように解釈されます。
For complete autoconfiguration, OSPFv3 will need to choose suitable configuration defaults. These include:
完全な自動構成のために、OSPFv3は適切な構成のデフォルトを選択する必要があります。これらには以下が含まれます：
1. Area 0 Only - All autoconfigured OSPFv3 interfaces MUST be in area 0.
1. エリア0のみ-すべての自動構成されたOSPFv3インターフェイスはエリア0にある必要があります。
2. OSPFv3 SHOULD be autoconfigured on all IPv6-capable interfaces on the router. An interface MAY be excluded if it is clear that running OSPFv3 on the interface is not required. For example, if manual configuration or another condition indicates that an interface is connected to an Internet Service Provider (ISP), there is typically no need to employ OSPFv3. In fact, [IPv6-CPE] specifically requires that IPv6 Customer Premise Equipment (CPE) routers not initiate any dynamic routing protocol by default on the router's WAN, i.e., ISP-facing, interface. In home networking environments, an interface where no OSPFv3 neighbors are found, but a DHCP IPv6 prefix can be acquired, may be considered an ISP-facing interface, and running OSPFv3 is unnecessary.
2. OSPFv3は、ルーターのすべてのIPv6対応インターフェースで自動構成する必要があります（SHOULD）。インターフェース上でOSPFv3を実行する必要がないことが明らかな場合は、インターフェースを除外してもよい（MAY）。たとえば、インターフェイスがインターネットサービスプロバイダー（ISP）に接続されていることを手動構成または別の条件が示している場合、通常、OSPFv3を使用する必要はありません。実際、[IPv6-CPE]では特に、IPv6顧客宅内機器（CPE）ルーターが、ルーターのWAN、つまりISP側のインターフェースで、デフォルトで動的ルーティングプロトコルを開始しないようにする必要があります。ホームネットワーキング環境では、OSPFv3ネイバーは見つかりませんが、DHCP IPv6プレフィックスを取得できるインターフェイスはISPに面したインターフェイスと見なされる可能性があり、OSPFv3の実行は不要です。
3. OSPFv3 interfaces will be autoconfigured to an interface type corresponding to their Layer 2 capability. For example, Ethernet interfaces and Wi-Fi interfaces will be autoconfigured as OSPFv3 broadcast networks and Point-to-Point Protocol (PPP) interfaces will be autoconfigured as OSPFv3 Point-to-Point interfaces. Most extant OSPFv3 implementations do this already. autoconfigured operation over wireless networks requiring a point-to-multipoint (P2MP) topology and dynamic metrics based on wireless feedback is not within the scope of this document. However, autoconfiguration is not precluded in these environments.
3. OSPFv3インターフェイスは、レイヤ2機能に対応するインターフェイスタイプに自動設定されます。たとえば、イーサネットインターフェイスとWi-FiインターフェイスはOSPFv3ブロードキャストネットワークとして自動設定され、ポイントツーポイントプロトコル（PPP）インターフェイスはOSPFv3ポイントツーポイントインターフェイスとして自動設定されます。現存するほとんどのOSPFv3実装では、これがすでに行われています。ポイントツーマルチポイント（P2MP）トポロジとワイヤレスフィードバックに基づく動的メトリックを必要とするワイヤレスネットワークでの自動構成操作は、このドキュメントの範囲外です。ただし、これらの環境では自動構成は除外されません。
4. OSPFv3 interfaces MAY use an arbitrary HelloInterval and RouterDeadInterval as specified in Section 3. Of course, an identical HelloInterval and RouterDeadInterval will still be required to form an adjacency with an OSPFv3 router not supporting autoconfiguration [OSPFV3].
4. OSPFv3インターフェイスは、セクション3で指定されているように、任意のHelloIntervalとRouterDeadIntervalを使用できます。もちろん、自動構成をサポートしていないOSPFv3ルーターとの隣接関係を形成するには、同一のHelloIntervalとRouterDeadIntervalが必要です[OSPFV3]。
5. All OSPFv3 interfaces SHOULD be autoconfigured to use an Interface Instance ID of 0 that corresponds to the base IPv6 unicast address family instance ID as defined in [OSPFV3-AF]. Similarly, if IPv4 unicast addresses are advertised in a separate autoconfigured OSPFv3 instance, the base IPv4 unicast address family instance ID value, i.e., 64, SHOULD be autoconfigured as the Interface Instance ID for all interfaces corresponding to the IPv4 unicast OSPFv3 instance [OSPFV3-AF].
5. [OSPFV3-AF]で定義されているベースIPv6ユニキャストアドレスファミリインスタンスIDに対応する0のインターフェイスインスタンスIDを使用するように、すべてのOSPFv3インターフェイスを自動構成する必要があります。同様に、IPv4ユニキャストアドレスが別の自動構成されたOSPFv3インスタンスでアドバタイズされる場合、ベースIPv4ユニキャストアドレスファミリインスタンスID値、つまり64は、IPv4ユニキャストOSPFv3インスタンスに対応するすべてのインターフェースのインターフェースインスタンスIDとして自動構成されるべきです[OSPFV3- AF]。
autoconfigured OSPFv3 routers will not require an identical HelloInterval and RouterDeadInterval to form adjacencies. Rather, the received HelloInterval will be ignored and the received RouterDeadInterval will be used to determine OSPFv3 liveliness with the sending router. In other words, the Neighbor Inactivity Timer (Section 10 of [OSPFV2]) for each neighbor will reflect that neighbor's advertised RouterDeadInterval and MAY be different from other OSPFv3 routers on the link without impacting adjacency formation. A similar mechanism requiring additional signaling is proposed for all OSPFv2 and OSPFv3 routers [ASYNC-HELLO].
自動構成されたOSPFv3ルーターは、隣接関係を形成するために同一のHelloIntervalとRouterDeadIntervalを必要としません。代わりに、受信したHelloIntervalは無視され、受信したRouterDeadIntervalを使用して、送信元ルーターとのOSPFv3の活性を判断します。言い換えると、各ネイバーのネイバー非アクティブタイマー（[OSPFV2]のセクション10）は、ネイバーのアドバタイズされたRouterDeadIntervalを反映し、隣接関係の形成に影響を与えることなく、リンク上の他のOSPFv3ルーターとは異なる場合があります。追加のシグナリングを必要とする同様のメカニズムが、すべてのOSPFv2およびOSPFv3ルーターに提案されています[ASYNC-HELLO]。
In many situations, autoconfigured OSPFv3 routers will be deployed in environments where back-to-back ethernet connections are utilized. When this is the case, an OSPFv3 broadcast interface will not come up until the other OSPFv3 router is connected, and the routers will wait RouterDeadInterval seconds before forming an adjacency [OSPFV2]. In order to reduce this delay, an autoconfigured OSPFv3 router MAY reduce the wait interval to a value no less than (HelloInterval + 1). Reducing the setting will slightly increase the likelihood of the Designated Router (DR) flapping but is preferable to the long adjacency formation delay. Note that this value is not included in OSPFv3 Hello packets and does not impact interoperability.
多くの場合、自動構成されたOSPFv3ルーターは、バックツーバックイーサネット接続が利用される環境に展開されます。この場合、OSPFv3ブロードキャストインターフェイスは、他のOSPFv3ルーターが接続されるまで起動せず、ルーターは隣接関係を形成する前にRouterDeadInterval秒待機します[OSPFV2]。この遅延を減らすために、自動構成されたOSPFv3ルーターは、待機間隔を（HelloInterval + 1）以上の値に減らすことができます（MAY）。設定を小さくすると、指定ルーター（DR）がフラッピングする可能性がわずかに高くなりますが、隣接関係の遅延が長くなるよりは望ましいです。この値はOSPFv3 Helloパケットには含まれておらず、相互運用性には影響しないことに注意してください。
In many deployments, the requirement for OSPFv3 authentication overrides the goal of complete OSPFv3 autoconfiguration. Therefore, it is RECOMMENDED that OSPFv3 routers supporting this specification minimally offer an option to explicitly configure a single password for HMAC-SHA authentication as described in [OSPFV3-AUTH-TRAILER]. It is RECOMMENDED that the password be entered as ASCII hexadecimal digits and that 32 or more digits be accepted to facilitate a password with a high degree of entropy. When configured, the password will be used on all autoconfigured interfaces with the Security Association Identifier (SA ID) set to 1 and HMAC-SHA-256 used as the authentication algorithm.
多くの展開では、OSPFv3認証の要件により、完全なOSPFv3自動構成の目標が上書きされます。したがって、この仕様をサポートするOSPFv3ルーターは、[OSPFV3-AUTH-TRAILER]で説明されているように、HMAC-SHA認証用に単一のパスワードを明示的に構成するオプションを最小限提供することをお勧めします。高度なエントロピーを持つパスワードを容易にするために、パスワードはASCII 16進数字として入力し、32桁以上を受け入れることをお勧めします。構成すると、パスワードは、セキュリティアソシエーション識別子（SA ID）が1に設定され、HMAC-SHA-256が認証アルゴリズムとして使用され、自動構成されたすべてのインターフェイスで使用されます。
An OSPFv3 router requires a unique Router ID within the OSPFv3 routing domain for correct protocol operation. Existing Router ID selection algorithms (Appendix C.1 in [OSPFV2] and [OSPFV3]) are not viable since they are dependent on a unique IPv4 interface address that is not likely to be available in autoconfigured deployments. An OSPFv3 router implementing this specification will select a Router ID that has a high probability of uniqueness. A pseudorandom number SHOULD be used for the OSPFv3 Router ID. The generation SHOULD be seeded with a variable that is likely to be unique in the applicable OSPFv3 router deployment. A good choice of seed would be some portion or hash of the Router-Hardware-Fingerprint as described in Section 7.2.2.
OSPFv3ルーターは、正しいプロトコル操作のためにOSPFv3ルーティングドメイン内で一意のルーターIDを必要とします。既存のルーターID選択アルゴリズム（[OSPFV2]および[OSPFV3]の付録C.1）は、自動構成された展開では利用できない可能性のある一意のIPv4インターフェイスアドレスに依存しているため、実行できません。この仕様を実装するOSPFv3ルーターは、一意である可能性が高いルーターIDを選択します。 OSPFv3ルーターIDには、疑似乱数を使用する必要があります（SHOULD）。世代には、該当するOSPFv3ルーターの展開で一意である可能性が高い変数をシードする必要があります。シードの適切な選択は、セクション7.2.2で説明されているように、Router-Hardware-Fingerprintの一部またはハッシュです。
Since there is a possibility of a Router ID collision, duplicate Router ID detection and resolution are required as described in Sections 7 and 7.3. OSPFv3 routers SHOULD maintain the last successfully chosen Router ID in nonvolatile storage to avoid collisions subsequent to when an autoconfigured OSPFv3 router is first added to the OSPFv3 routing domain.
ルーターIDの衝突の可能性があるため、セクション7と7.3で説明されているように、ルーターIDの重複検出と解決が必要です。 OSPFv3ルーターは、自動構成されたOSPFv3ルーターが最初にOSPFv3ルーティングドメインに追加された後の衝突を回避するために、最後に正常に選択されたルーターIDを不揮発性ストレージに維持する必要があります。
Since OSPFv3 uses IPv6 link-local addresses for all protocol messages other than messages sent on virtual links (which are not applicable to autoconfiguration), OSPFv3 adjacency formation can proceed as soon as a Router ID has been selected and the IPv6 link-local address has completed Duplicate Address Detection (DAD) as specified in IPv6 Stateless Address Autoconfiguration [SLAAC]. Otherwise, the only changes to the OSPFv3 base specification are supporting HelloInterval/RouterDeadInterval flexibility as described in Section 3 and duplicate Router ID detection and resolution as described in Sections 7 and 7.3.
OSPFv3は、仮想リンクで送信されたメッセージ（自動構成には適用されない）以外のすべてのプロトコルメッセージにIPv6リンクローカルアドレスを使用するため、ルーターIDが選択され、IPv6リンクローカルアドレスが設定されるとすぐに、OSPFv3隣接関係の形成を続行できます。 IPv6ステートレスアドレス自動構成[SLAAC]で指定されている重複アドレス検出（DAD）を完了しました。それ以外の場合、OSPFv3基本仕様に対する唯一の変更は、セクション3で説明されているようにHelloInterval / RouterDeadIntervalの柔軟性をサポートし、セクション7と7.3で説明されているようにルーターIDの検出と解決を複製します。
There are two cases of duplicate OSPFv3 Router ID detection. One where the OSPFv3 router with the duplicate Router ID is directly connected and one where it is not. In both cases, the duplicate resolution is for one of the routers to select a new OSPFv3 Router ID.
OSPFv3ルーターIDの重複検出には2つのケースがあります。重複するルーターIDを持つOSPFv3ルーターが直接接続されているものと、そうでないものがあります。どちらの場合も、重複解決は、ルーターの1つが新しいOSPFv3ルーターIDを選択するためのものです。
In this case, a duplicate Router ID is detected if any valid OSPFv3 packet is received with the same OSPFv3 Router ID but a different IPv6 link-local source address. Once this occurs, the OSPFv3 router with the numerically smaller IPv6 link-local address will need to select a new Router ID as described in Section 7.3. Note that the fact that the OSPFv3 router is a neighbor on a non-virtual interface implies that the router is directly connected. An OSPFv3 router implementing this specification should ensure that the inadvertent connection of multiple router interfaces to the same physical link is not misconstrued as detection of an OSPFv3 neighbor with a duplicate Router ID.
この場合、同じOSPFv3ルーターIDを持つがIPv6リンクローカルソースアドレスが異なる有効なOSPFv3パケットを受信すると、重複するルーターIDが検出されます。これが発生すると、数値が小さいIPv6リンクローカルアドレスを持つOSPFv3ルーターは、7.3項で説明されているように、新しいルーターIDを選択する必要があります。 OSPFv3ルーターが非仮想インターフェイスのネイバーであることは、ルーターが直接接続されていることを意味します。この仕様を実装するOSPFv3ルーターは、同じ物理リンクへの複数のルーターインターフェイスの不注意な接続が、ルーターIDが重複するOSPFv3ネイバーの検出と誤解されないようにする必要があります。
OSPFv3 routers implementing autoconfiguration, as specified herein, MUST originate an Autoconfiguration (AC) Link State Advertisement (LSA) including the Router-Hardware-Fingerprint Type-Length-Value (TLV). The Router-Hardware-Fingerprint TLV contains a variable-length value that has a very high probability of uniquely identifying the advertising OSPFv3 router. An OSPFv3 router implementing this specification MUST detect received Autoconfiguration LSAs with its Router ID specified in the LSA header. LSAs received with the local OSPFv3 Router's Router ID in the LSA header are perceived as self-originated (see Section 4.6 of [OSPFV3]). In these received Autoconfiguration LSAs, the Router-Hardware-Fingerprint TLV is compared against the OSPFv3 Router's own router hardware fingerprint. If the fingerprints are not equal, there is a duplicate Router ID conflict and the OSPFv3 router with the numerically smaller router hardware fingerprint MUST select a new Router ID as described in Section 7.3.
ここで指定されているように、自動構成を実装しているOSPFv3ルーターは、Router-Hardware-Fingerprint Type-Length-Value（TLV）を含むAutoconfiguration（AC）Link State Advertisement（LSA）を発信しなければなりません。 Router-Hardware-Fingerprint TLVには、アドバタイズOSPFv3ルーターを一意に識別する可能性が非常に高い可変長の値が含まれています。この仕様を実装するOSPFv3ルーターは、LSAヘッダーにルーターIDが指定されている受信した自動構成LSAを検出する必要があります。 LSAヘッダー内のローカルOSPFv3ルーターのルーターIDで受信されたLSAは、自己生成されたものとして認識されます（[OSPFV3]のセクション4.6を参照）。これらの受信した自動構成LSAで、ルーターハードウェアフィンガープリントTLVは、OSPFv3ルーター自身のルーターハードウェアフィンガープリントと比較されます。フィンガープリントが等しくない場合、重複するルーターIDの競合があり、数値が小さいルーターハードウェアフィンガープリントを持つOSPFv3ルーターは、セクション7.3で説明されているように新しいルーターIDを選択する必要があります。
This new LSA is designated for information related to OSPFv3 autoconfiguration and, in the future, could be used for other autoconfiguration information, e.g., global IPv6 prefixes. However, this is beyond the scope of this document.
この新しいLSAは、OSPFv3自動構成に関連する情報用に指定されており、将来、グローバルIPv6プレフィックスなどの他の自動構成情報に使用できるようになります。ただし、これはこのドキュメントの範囲を超えています。
The OSPFv3 Autoconfiguration (AC) LSA has a function code of 15 and the S2/S1 bits set to 01 indicating Area Flooding Scope. The U bit will be set indicating that the OSPFv3 AC LSA should be flooded even if it is not understood. The Link State ID (LSID) value will be an integer index used to discriminate between multiple AC LSAs originated by the same OSPFv3 router. This specification only describes the contents of an AC LSA with an LSID of 0.
OSPFv3自動構成（AC）LSAの機能コードは15で、S2 / S1ビットは01に設定され、エリアフラッディングスコープを示します。 Uビットが設定され、OSPFv3 AC LSAが理解されていなくてもフラッディングする必要があることを示します。リンク状態ID（LSID）値は、同じOSPFv3ルーターから発信された複数のAC LSAを区別するために使用される整数のインデックスになります。この仕様は、LSIDが0のAC LSAの内容のみを説明しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |1|0|1| 15 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
OSPFv3 Autoconfiguration (AC) LSA
OSPFv3自動構成（AC）LSA
The format of the TLVs within the body of an AC LSA is the same as the format used by the Traffic Engineering Extensions to OSPFv2 [TE]. The LSA payload consists of one or more nested TLV triplets. The format of each TLV is:
AC LSAの本体内のTLVの形式は、OSPFv2 [TE]へのトラフィックエンジニアリング拡張機能で使用される形式と同じです。 LSAペイロードは、1つ以上のネストされたTLVトリプレットで構成されています。各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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Format
TLV形式
The Length field defines the length of the value portion in octets (thus a TLV with no value portion would have a length of 0). The TLV is padded to 4-octet alignment; padding is not included in the length field (so a 3-octet value would have a length of 3, but the total size of the TLV would be 8 octets). Nested TLVs are also 32-bit aligned. For example, a 1-byte value would have the length field set to 1, and 3 octets of padding would be added to the end of the value portion of the TLV. Unrecognized types are ignored.
長さフィールドは、値の部分の長さをオクテットで定義します（したがって、値の部分がないTLVの長さは0になります）。 TLVは4オクテットアライメントにパディングされます。パディングは長さフィールドには含まれません（したがって、3オクテットの値は長さが3になりますが、TLVの合計サイズは8オクテットになります）。ネストされたTLVも32ビット境界で整列されます。たとえば、1バイトの値では、長さフィールドが1に設定され、3オクテットのパディングがTLVの値部分の最後に追加されます。認識されないタイプは無視されます。
The new LSA is designated for information related to OSPFv3 autoconfiguration and, in the future, can be used other autoconfiguration information.
新しいLSAは、OSPFv3自動構成に関連する情報用に指定されており、将来、他の自動構成情報を使用できるようになります。
The Router-Hardware-Fingerprint TLV is the first TLV defined for the OSPFv3 Autoconfiguration (AC) LSA. It will have type 1 and MUST be advertised in the LSID OSPFv3 AC LSA with an LSID of 0. It SHOULD occur, at most, once and the first instance of the TLV will take precedence over subsequent TLV instances. The length of the Router-Hardware-Fingerprint is variable but must be 32 octets or greater. If the Router-Hardware-Fingerprint TLV is not present as the first TLV, the AC LSA is considered malformed and is ignored for the purposes of duplicate Router ID detection. Additionally, the event SHOULD be logged.
Router-Hardware-Fingerprint TLVは、OSPFv3自動構成（AC）LSAに対して定義された最初のTLVです。タイプは1であり、LSIDが0のLSID OSPFv3 AC LSAでアドバタイズされる必要があります。最大で1回発生し、TLVの最初のインスタンスが後続のTLVインスタンスよりも優先されます。 Router-Hardware-Fingerprintの長さは可変ですが、32オクテット以上である必要があります。 Router-Hardware-Fingerprint TLVが最初のTLVとして存在しない場合、AC LSAは形式が正しくないと見なされ、重複するルーターIDを検出するために無視されます。さらに、イベントはログに記録する必要があります。
The contents of the hardware fingerprint MUST have an extremely high probability of uniqueness. It SHOULD be constructed from the concatenation of a number of local values that themselves have a high likelihood of uniqueness, such as Media Access Control (MAC) addresses, CPU ID, or serial numbers. It is RECOMMENDED that one or more available universal tokens (e.g., IEEE 802 48-bit MAC addresses or IEEE EUI-64 Identifiers [EUI64]) associated with the OSPFv3 router be included in the hardware fingerprint. It MUST be based on hardware attributes that will not change across hard and soft restarts.
ハードウェアフィンガープリントの内容は、一意性の可能性が非常に高い必要があります。メディアアクセスコントロール（MAC）アドレス、CPU ID、シリアル番号など、固有性が高い可能性が高いローカル値の連結から構築する必要があります。 OSPFv3ルーターに関連付けられた1つ以上の利用可能なユニバーサルトークン（IEEE 802 48ビットMACアドレスまたはIEEE EUI-64識別子[EUI64]など）をハードウェアフィンガープリントに含めることをお勧めします。ハード再起動とソフト再起動で変更されないハードウェア属性に基づいている必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | >32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Hardware Fingerprint |
o
o
o
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Router-Hardware-Fingerprint TLV Format
ルーター-ハードウェア-フィンガープリントTLV形式
The OSPFv3 router selected to resolve the duplicate OSPFv3 Router ID condition must select a new OSPFv3 Router ID. The OSPFv3 router SHOULD reduce the possibility of a subsequent Router ID collision by checking the Link State Database (LSDB) for an OSPFv3 Autoconfiguration LSA with the newly selected Router ID and a different Router-Hardware-Fingerprint. If one is detected, a new Router ID should be selected without going through the resolution process (Section 7). After selecting a new Router ID, all self-
重複するOSPFv3ルーターID条件を解決するために選択されたOSPFv3ルーターは、新しいOSPFv3ルーターIDを選択する必要があります。 OSPFv3ルーターは、新たに選択されたルーターIDと異なるルーターハードウェアフィンガープリントを使用してOSPFv3自動構成LSAのリンク状態データベース（LSDB）をチェックすることにより、その後のルーターIDの衝突の可能性を低減する必要があります。検出された場合は、解決プロセス（セクション7）を行わずに、新しいルーターIDを選択する必要があります。新しいルーターIDを選択すると、すべてのセルフ
originated LSAs MUST be reoriginated, and any OSPFv3 neighbor adjacencies MUST be reestablished. The OSPFv3 router retaining the Router ID causing the conflict will reoriginate or flush any stale self-originated LSAs as described in Section 13.4 of [OSPFV2].
発信されたLSAを再発信する必要があり、すべてのOSPFv3ネイバー隣接関係を再確立する必要があります。 [OSPFV2]のセクション13.4で説明されているように、競合を引き起こしているルーターIDを保持しているOSPFv3ルーターは、古い自己発信LSAを再発信またはフラッシュします。
7.4. Change to RFC 2328, Section 13.4 ("Receiving Self-Originated LSAs")
7.4. RFC 2328のセクション13.4に変更（「Receiving Self-Originated LSAs」）
RFC 2328 [OSPFV2], Section 13.4, describes the processing of received self-originated LSAs. If the received LSA doesn't exist, the receiving router will flush it from the OSPF routing domain. If the LSA is newer than the version in the LSDB, the receiving router will originate a newer version by advancing the LSA sequence number and reoriginating. Since it is possible for an autoconfigured OSPFv3 router to choose a duplicate OSPFv3 Router ID, OSPFv3 routers implementing this specification should detect when multiple instances of the same self-originated LSA are flushed or reoriginated since this is indicative of an OSPFv3 router with a duplicate Router ID in the OSPFv3 routing domain. When this condition is detected, the OSPFv3 router SHOULD delay self-originated LSA processing for LSAs that have recently been flushed or reoriginated. This specification recommends 10 seconds as the interval defining recent self-originated LSA processing and an exponential back-off of 1 to 8 seconds for the processing delay. This additional delay should allow for the mechanisms described in Section 7 to resolve the duplicate OSPFv3 Router ID conflict.
RFC 2328 [OSPFV2]、セクション13.4では、受信した自己発信LSAの処理について説明しています。受信したLSAが存在しない場合、受信ルーターはそれをOSPFルーティングドメインからフラッシュします。 LSAがLSDBのバージョンより新しい場合、受信側ルーターは、LSAシーケンス番号を進めて再発信することにより、新しいバージョンを発信します。自動構成されたOSPFv3ルーターが重複するOSPFv3ルーターIDを選択する可能性があるため、この仕様を実装しているOSPFv3ルーターは、同じ自己発信LSAの複数のインスタンスがフラッシュまたは再発信されたことを検出する必要があります。これは、ルーターが重複しているOSPFv3ルーターを示しているためです。 OSPFv3ルーティングドメインのID。この状態が検出されると、OSPFv3ルーターは、最近フラッシュまたは再生成されたLSAの自己生成LSA処理を遅延させる必要があります（SHOULD）。この仕様では、最近の自己発信LSA処理を定義する間隔として10秒、処理遅延のために1〜8秒の指数バックオフを推奨しています。この追加の遅延により、セクション7で説明されているメカニズムで、重複するOSPFv3ルーターIDの競合を解決できます。
Since this mechanism is useful in mitigating the flooding overhead associated with the inadvertent or malicious introduction of an OSPFv3 router with a duplicate Router ID into an OSPFv3 routing domain, it MAY be deployed outside of autoconfigured deployments. The detection of a self-originated LSA that is being repeatedly reoriginated or flushed SHOULD be logged.
このメカニズムは、OSPFv3ルーティングドメインへのルーターIDが重複するOSPFv3ルーターの不注意または悪意のある導入に関連するフラッディングオーバーヘッドを軽減するのに役立つため、自動構成されたデプロイメントの外部にデプロイできます。繰り返し再生成またはフラッシュされている自己生成LSAの検出はログに記録する必要があります（SHOULD）。
The goals of security and complete OSPFv3 autoconfiguration are somewhat contradictory. When no explicit security configuration takes place, autoconfiguration implies that additional devices placed in the network are automatically adopted as a part of the network. However, autoconfiguration can also be combined with password configuration (see Section 4) or future extensions for automatic pairing between devices. These mechanisms can help provide an automatically configured, securely routed network.
セキュリティの目標と完全なOSPFv3自動構成は、多少矛盾しています。明示的なセキュリティ設定が行われない場合、自動設定は、ネットワークに配置された追加のデバイスがネットワークの一部として自動的に採用されることを意味します。ただし、自動構成をパスワード構成（セクション4を参照）または将来の拡張機能と組み合わせて、デバイス間の自動ペアリングを行うこともできます。これらのメカニズムは、自動的に構成され、安全にルーティングされたネットワークを提供するのに役立ちます。
In deployments where a different authentication algorithm or encryption is required (or different per-interface keys are required), OSPFv3 IPsec [OSPFV3-IPSEC] or alternate OSPFv3
異なる認証アルゴリズムまたは暗号化が必要な（またはインターフェイスごとの異なるキーが必要な）展開では、OSPFv3 IPsec [OSPFV3-IPSEC]または代替OSPFv3
Authentication Trailer [OSPFV3-AUTH-TRAILER] algorithms MAY be used at the expense of additional configuration. The configuration and operational description of such deployments are beyond the scope of this document. However, a deployment could always revert to explicit configuration as described in Section 9 for features such as IPsec, per-interface keys, or alternate authentication algorithms.
認証トレーラー[OSPFV3-AUTH-TRAILER]アルゴリズムは、追加の構成を犠牲にして使用される場合があります。そのようなデプロイメントの構成と操作の説明は、このドキュメントの範囲を超えています。ただし、IPsec、インターフェイスごとのキー、代替認証アルゴリズムなどの機能については、セクション9で説明されているように、展開を常に明示的な構成に戻すことができます。
The introduction, either malicious or accidental, of an OSPFv3 router with a duplicate Router ID is an attack point for OSPFv3 routing domains. This is due to the fact that OSPFv3 routers will interpret LSAs advertised by the router with the same Router ID as self-originated LSAs and attempt to flush them from the routing domain. The mechanisms in Section 7.4 will mitigate the effects of duplication.
ルーターIDが重複しているOSPFv3ルーターの悪意のある、または偶発的な導入は、OSPFv3ルーティングドメインの攻撃ポイントです。これは、OSPFv3ルーターが同じルーターIDを持つルーターによってアドバタイズされたLSAを自己発信LSAと解釈し、ルーティングドメインからそれらをフラッシュしようとするためです。セクション7.4のメカニズムは、複製の影響を軽減します。
It is RECOMMENDED that OSPFv3 routers supporting this specification also support explicit configuration of OSPFv3 parameters as specified in Appendix C of [OSPFV3]. This would allow explicit override of autoconfigured parameters in situations where it is required (e.g., if the deployment requires multiple OSPFv3 areas). This is in addition to the authentication key configuration recommended in Section 4. Additionally, it is RECOMMENDED that OSPFv3 routers supporting this specification allow autoconfiguration to be completely disabled.
この仕様をサポートするOSPFv3ルーターは、[OSPFV3]の付録Cで指定されているように、OSPFv3パラメータの明示的な構成もサポートすることをお勧めします。これにより、自動構成されたパラメーターを明示的にオーバーライドすることが可能になります（たとえば、展開で複数のOSPFv3エリアが必要な場合など）。これは、セクション4で推奨されている認証キー構成に追加されるものです。さらに、この仕様をサポートするOSPFv3ルーターでは、自動構成を完全に無効にすることをお勧めします。
Since there is a small possibility of OSPFv3 Router ID collisions, manual configuration of OSPFv3 Router IDs is RECOMMENDED in OSPFv3 routing domains where route convergence due to a Router ID change is intolerable.
OSPFv3ルーターIDの衝突の可能性はわずかであるため、ルーターIDの変更によるルートの収束が許容できないOSPFv3ルーティングドメインでは、OSPFv3ルーターIDの手動構成を推奨します。
OSPFv3 routers supporting this specification MUST augment mechanisms for displaying or otherwise conveying OSPFv3 operational state to indicate whether or not the OSPFv3 router was autoconfigured and whether or not its OSPFv3 interfaces have been autoconfigured.
この仕様をサポートするOSPFv3ルーターは、OSPFv3ルーターが自動構成されたかどうか、およびそのOSPFv3インターフェイスが自動構成されたかどうかを示すために、OSPFv3の動作状態を表示または伝達するメカニズムを強化する必要があります。
This specification defines an OSPFv3 LSA Type for the OSPFv3 Autoconfiguration (AC) LSA, as described in Section 7.2.1. The value 15 has been allocated from the existing "OSPFv3 LSA Function Codes" registry for the OSPFv3 Autoconfiguration (AC) LSA.
この仕様は、セクション7.2.1で説明されているように、OSPFv3自動構成（AC）LSAのOSPFv3 LSAタイプを定義します。値15は、OSPFv3自動構成（AC）LSA用の既存の「OSPFv3 LSA機能コード」レジストリから割り当てられています。
This specification also creates a registry for OSPFv3 Autoconfiguration (AC) LSA TLVs. This registry has been placed in the existing OSPFv3 IANA registry, and new values will be allocated via IETF Review or, under exceptional circumstances, IESG Approval. [IANA-GUIDELINES]
この仕様は、OSPFv3自動構成（AC）LSA TLVのレジストリも作成します。このレジストリは既存のOSPFv3 IANAレジストリに配置されており、新しい値はIETFレビューまたは例外的な状況ではIESG承認を介して割り当てられます。 [IANAガイドライン]
Three initial values are allocated:
3つの初期値が割り当てられます。
o 0 is marked as Reserved.
o 0は予約済みとしてマークされています。
o 1 is Router-Hardware-Fingerprint TLV (Section 7.2.2).
o 1は、Router-Hardware-Fingerprint TLVです（セクション7.2.2）。
o 65535 is an Autoconfiguration-Experiment-TLV, a common value that can be used for experimental purposes.
o 65535はAutoconfiguration-Experiment-TLVであり、実験目的で使用できる一般的な値です。
[OSPFV2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998, <http://www.rfc-editor.org/info/rfc2328>.
[OSPFV2] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月、<http://www.rfc-editor.org/info/rfc2328>。
[OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008, <http://www.rfc-editor.org/info/rfc5340>.
[OSPFV3] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、2008年7月、<http://www.rfc-editor.org/info/ rfc5340>。
[OSPFV3-AF] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, April 2010, <http://www.rfc-editor.org/info/rfc5838>.
[OSPFV3-AF] Lindem、A.、Ed。、Mirtorabi、S.、Roy、A.、Barnes、M.、and R. Aggarwal、 "Support of Address Families in OSPFv3"、RFC 5838、April 2010、<http ：//www.rfc-editor.org/info/rfc5838>。
[OSPFV3-AUTH-TRAILER] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 7166, March 2014, <http://www.rfc-editor.org/info/rfc7166>.
[OSPFV3-AUTH-TRAILER] Bhatia、M.、Manral、V。、およびA. Lindem、「Supporting Authentication Trailer for OSPFv3」、RFC 7166、2014年3月、<http://www.rfc-editor.org/info / rfc7166>。
[RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC-KEYWORDS] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[SLAAC] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.
[SLAAC] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月、<http://www.rfc-editor.org/info/rfc4862>。
[TE] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003, <http://www.rfc-editor.org/info/rfc3630>.
[TE] Katz、D.、Kompella、K.、D。Yeung、「Traffic Engineering（TE）Extensions to OSPF Version 2」、RFC 3630、2003年9月、<http://www.rfc-editor.org/ info / rfc3630>。
[ASYNC-HELLO] Anand, M., Grover, H., and A. Roy, "Asymmetric OSPF Hold Timer", Work in Progress, draft-madhukar-ospf-agr-asymmetric-01, June 2013.
[ASYNC-HELLO]アナンド、M。、グローバー、H。、およびA.ロイ、「非対称OSPFホールドタイマー」、作業中、draft-madhukar-ospf-agr-asymmetric-01、2013年6月。
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)", Registration Authority Tutorial, March 1997, <http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html>.
[EUI64] IEEE、「64ビットグローバルID（EUI-64）のガイドライン」、登録機関チュートリアル、1997年3月、<http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html>。
[IANA-GUIDELINES] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[IANA-GUIDELINES] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月、<http://www.rfc-editor.org/info/ rfc5226>。
[IPv6-CPE] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, November 2013, <http://www.rfc-editor.org/info/rfc7084>.
[IPv6-CPE] Singh、H.、Beebee、W.、Donley、C。、およびB. Stark、「IPv6カスタマーエッジルーターの基本要件」、RFC 7084、2013年11月、<http：//www.rfc- editor.org/info/rfc7084>。
[OSPFV3-IPSEC] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006, <http://www.rfc-editor.org/info/rfc4552>.
[OSPFV3-IPSEC] Gupta、M。およびN. Melam、「Authentication / Confidentiality for OSPFv3」、RFC 4552、2006年6月、<http://www.rfc-editor.org/info/rfc4552>。
Acknowledgments
謝辞
This specification was inspired by the work presented in the HOMENET working group meeting in October 2011 in Philadelphia, Pennsylvania. In particular, we would like to thank Fred Baker, Lorenzo Colitti, Ole Troan, Mark Townsley, and Michael Richardson.
この仕様は、ペンシルベニア州フィラデルフィアで2011年10月に開催されたHOMENETワーキンググループミーティングで発表された作業に触発されました。特に、Fred Baker、Lorenzo Colitti、Ole Troan、Mark Townsley、Michael Richardsonに感謝します。
Arthur Dimitrelis and Aidan Williams did prior work in OSPFv3 autoconfiguration in the expired Internet-Draft titled "Autoconfiguration of routers using a link state routing protocol". There are many similarities between the concepts and techniques in this document.
Arthur DimitrelisとAidan Williamsは、「リンク状態ルーティングプロトコルを使用したルーターの自動構成」というタイトルの期限切れのインターネットドラフトで、OSPFv3自動構成の以前の作業を行いました。このドキュメントの概念と手法の間には多くの類似点があります。
Thanks for Abhay Roy and Manav Bhatia for comments regarding duplicate Router ID processing.
ルーターIDの重複処理に関するコメントを提供してくれたAbhay RoyとManav Bhatiaに感謝します。
Thanks for Alvaro Retana and Michael Barnes for comments regarding OSPFv3 Instance ID autoconfiguration.
OSPFv3インスタンスID自動構成に関するコメントを提供してくれたAlvaro RetanaとMichael Barnesに感謝します。
Thanks to Faraz Shamim for review and comments.
レビューとコメントをしてくれたFaraz Shamimに感謝します。
Thanks to Mark Smith for the requirement to reduce the adjacency formation delay in the back-to-back ethernet topologies that are prevalent in home networks.
ホームネットワークで一般的なバックツーバックイーサネットトポロジでの隣接関係の形成遅延を減らす必要があるというマークスミスに感謝します。
Thanks to Les Ginsberg for document review and recommendations on OSPFv3 hardware fingerprint content.
OSPFv3ハードウェアフィンガープリントコンテンツに関するドキュメントのレビューと推奨事項について、Les Ginsbergに感謝します。
Thanks to Curtis Villamizar for document review and analysis of duplicate Router ID resolution nuances.
ドキュメントのレビューとルーターID解決のニュアンスの重複の分析については、Curtis Villamizarに感謝します。
Thanks to Uma Chunduri for comments during OSPF WG last call.
OSPF WGの最後の電話でのコメントについては、Uma Chunduriに感謝します。
Thanks to Martin Vigoureux for Routing Area Directorate review and comments.
Routing Area Directorateのレビューとコメントを提供してくれたMartin Vigoureuxに感謝します。
Thanks to Adam Montville for Security Area Directorate review and comments.
Security Area Directorateのレビューとコメントを提供してくれたAdam Montvilleに感謝します。
Thanks to Qin Wu for Operations & Management Area Directorate review and comments.
運営管理区域総局のレビューとコメントを寄せてくれたQin Wuに感謝します。
Thanks to Robert Sparks for General Area (GEN-ART) review and comments.
General Area（GEN-ART）のレビューとコメントを提供してくれたRobert Sparksに感謝します。
Thanks to Rama Darbha for review and comments.
レビューとコメントをしてくれたRama Darbhaに感謝します。
Special thanks to Adrian Farrel for his in-depth review, copious comments, and suggested text.
Adrian Farrel氏の詳細なレビュー、豊富なコメント、提案されたテキストについて、特に感謝します。
Special thanks go to Markus Stenberg for his implementation of this specification in Bird.
この仕様をBirdに実装してくれたMarkus Stenbergに特に感謝します。
Special thanks also go to David Lamparter for his implementation of this specification in Quagga.
Quaggaでのこの仕様の実装について、David Lamparterにも特に感謝します。
This document was initially produced using the xml2rfc tool.
このドキュメントは、当初xml2rfcツールを使用して作成されました。
Authors' Addresses
著者のアドレス
Acee Lindem Cisco Systems 301 Midenhall Way Cary, NC 27513 United States
Acee Lindem Cisco Systems 301 Midenhall Way Cary、NC 27513 United States
EMail: acee@cisco.com
Jari Arkko Ericsson Jorvas, 02420 Finland
Jari Arkko Ericsson Jorvas、02420フィンランド
EMail: jari.arkko@piuha.net