[要約] RFC 8196は、IS-IS（Intermediate System to Intermediate System）ルーティングプロトコルの自動設定に関する仕様です。その目的は、IS-ISネットワークの設定を簡素化し、自動化することです。
Internet Engineering Task Force (IETF) B. Liu, Ed.
Request for Comments: 8196 Huawei Technologies
Category: Standards Track L. Ginsberg
ISSN: 2070-1721 Cisco Systems
B. Decraene
Orange
I. Farrer
Deutsche Telekom AG
M. Abrahamsson
T-Systems
July 2017
IS-IS Autoconfiguration
IS-IS自動構成
Abstract
概要
This document specifies IS-IS autoconfiguration mechanisms. The key components are IS-IS System ID self-generation, duplication detection, and duplication resolution. These mechanisms provide limited IS-IS functions and are therefore suitable for networks where plug-and-play configuration is expected.
このドキュメントでは、IS-IS自動構成メカニズムについて説明します。主なコンポーネントは、IS-ISシステムIDの自己生成、重複検出、および重複解決です。これらのメカニズムは限られたIS-IS機能を提供するため、プラグアンドプレイ構成が予想されるネットワークに適しています。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc8196.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8196で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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 Language . . . . . . . . . . . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Specification . . . . . . . . . . . . . . . . . . . 4
3.1. IS-IS Default Configuration . . . . . . . . . . . . . . . 4
3.2. IS-IS NET Generation . . . . . . . . . . . . . . . . . . 4
3.3. Router-Fingerprint TLV . . . . . . . . . . . . . . . . . 6
3.4. Protocol Operation . . . . . . . . . . . . . . . . . . . 7
3.4.1. Startup Mode . . . . . . . . . . . . . . . . . . . . 7
3.4.2. Adjacency Formation . . . . . . . . . . . . . . . . . 8
3.4.3. IS-IS System ID Duplication Detection . . . . . . . . 8
3.4.4. Duplicate System ID Resolution Procedures . . . . . . 8
3.4.5. System ID and Router-Fingerprint Generation
Considerations . . . . . . . . . . . . . . . . . . . 9
3.4.6. Duplication of Both System ID and Router-Fingerprint 10
3.5. Additional IS-IS TLVs Usage Guidelines . . . . . . . . . 12
3.5.1. Authentication TLV . . . . . . . . . . . . . . . . . 12
3.5.2. Metric Used in Reachability TLVs . . . . . . . . . . 12
3.5.3. Dynamic Name TLV . . . . . . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
This document specifies mechanisms for IS-IS [RFC1195] [ISO_IEC10589] [RFC5308] to be autoconfiguring. Such mechanisms could reduce the management burden for configuring a network, especially where plug-and-play device configuration is required.
このドキュメントでは、IS-IS [RFC1195] [ISO_IEC10589] [RFC5308]が自動設定されるメカニズムを指定しています。このようなメカニズムにより、特にプラグアンドプレイのデバイス構成が必要な場合に、ネットワークを構成するための管理負担を軽減できます。
IS-IS autoconfiguration is comprised of the following functions:
IS-IS自動設定は、次の機能で構成されています。
1. IS-IS default configuration
1. IS-ISのデフォルト設定
2. IS-IS System ID self-generation
2. IS-ISシステムIDの自己生成
3. System ID duplication detection and resolution
3. システムIDの重複の検出と解決
4. IS-IS TLV utilization (authentication TLV, metrics in reachability advertisements, and Dynamic Name TLV)
4. IS-IS TLV使用率（認証TLV、到達可能性通知のメトリック、および動的名TLV）
This document also defines mechanisms to prevent the unintentional interoperation of autoconfigured routers with non-autoconfigured routers. See Section 3.3.
このドキュメントでは、自動構成されたルーターと自動構成されていないルーターとの意図しない相互運用を防ぐためのメカニズムも定義しています。セクション3.3を参照してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. When these words are not in ALL CAPS (such as "should" or "Should"), they have their usual English meanings and are not to be interpreted as [RFC2119] key words.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。これらの単語がすべて大文字（ "should"または "Should"など）にない場合、それらは通常の英語の意味を持ち、[RFC2119]キーワードとして解釈されません。
The autoconfiguration mechanisms support both IPv4 and IPv6 deployments.
自動構成メカニズムは、IPv4とIPv6の両方の展開をサポートします。
These autoconfiguration mechanisms aim to cover simple deployment cases. The following important features are not supported:
これらの自動構成メカニズムは、単純な展開ケースを対象としています。次の重要な機能はサポートされていません。
o multiple IS-IS instances
o 複数のIS-ISインスタンス
o multi-area and level-2 routing
o マルチエリアおよびレベル2ルーティング
o interworking with other routing protocols IS-IS autoconfiguration is primarily intended for use in small (i.e., 10s of devices) and unmanaged deployments. It allows IS-IS to be used without the need for any configuration by the user. It is not recommended for larger deployments.
o他のルーティングプロトコルとの相互作用IS-IS自動構成は、主に小規模（つまり、数十台のデバイス）および管理されていない展開での使用を目的としています。これにより、ユーザーが構成を行うことなくIS-ISを使用できます。大規模な展開にはお勧めしません。
This section defines the default configuration for an autoconfigured router.
このセクションでは、自動構成されたルーターのデフォルト構成を定義します。
o IS-IS interfaces MUST be autoconfigured to an interface type corresponding to their Layer 2 capability. For example, Ethernet interfaces will be autoconfigured as broadcast networks and Point-to-Point Protocol (PPP) interfaces will be autoconfigured as Point-to-Point interfaces.
o IS-ISインターフェイスは、レイヤ2機能に対応するインターフェイスタイプに自動設定する必要があります。たとえば、イーサネットインターフェイスはブロードキャストネットワークとして自動設定され、ポイントツーポイントプロトコル（PPP）インターフェイスはポイントツーポイントインターフェイスとして自動設定されます。
o IS-IS autoconfiguration instances MUST be configured as level-1 so that the interfaces operate as level-1 only.
o IS-IS自動構成インスタンスは、インターフェイスがレベル1としてのみ動作するように、レベル1として構成する必要があります。
o originatingLSPBufferSize is set to 512.
o originatingLSPBufferSizeは512に設定されています。
o MaxAreaAddresses is set to 3.
o MaxAreaAddressesは3に設定されています。
o Extended IS reachability (TLV 22) and IP reachability (TLV 135) TLVs [RFC5305] MUST be used, i.e., a router operating in autoconfiguration mode MUST NOT use any of the following TLVs:
o 拡張IS到達可能性（TLV 22）およびIP到達可能性（TLV 135）TLV [RFC5305]を使用する必要があります。つまり、自動構成モードで動作するルーターは、次のTLVを使用してはなりません（MUST NOT）。
* IIS Neighbors (TLV 2)
* IISネイバー（TLV 2）
* IP Int. Reach (TLV 128)
* IP Int。リーチ（TLV 128）
* IP Ext. Address (TLV 130)
* IP拡張住所（TLV 130）
The TLVs listed above MUST be ignored on receipt.
上記のTLVは受信時に無視する必要があります。
In IS-IS, a router (known as an Intermediate System) is identified by a Network Entity Title (NET), which is a type of Network Service Access Point (NSAP). The NET is the address of an instance of the IS-IS protocol running on an IS.
IS-ISでは、ルーター（中間システム）は、ネットワークサービスアクセスポイント（NSAP）の一種であるネットワークエンティティタイトル（NET）によって識別されます。 NETは、ISで実行されているIS-ISプロトコルのインスタンスのアドレスです。
The autoconfiguration mechanism generates the IS-IS NET as the following:
自動構成メカニズムは、次のようにIS-IS NETを生成します。
o Area address
o エリアアドレス
In IS-IS autoconfiguration, this field MUST be 13 octets long and set to all 0s.
IS-IS自動設定では、このフィールドは13オクテット長で、すべて0に設定する必要があります。
o System ID
o システムID
This field follows the area address field and is 6 octets in length. There are two basic requirements for the System ID generation:
このフィールドはエリアアドレスフィールドの後に続き、長さは6オクテットです。システムIDの生成には、2つの基本的な要件があります。
- As specified by the IS-IS protocol, this field must be unique among all routers in the same area.
- IS-ISプロトコルで指定されているように、このフィールドは同じエリア内のすべてのルーター間で一意である必要があります。
- After its initial generation, the System ID SHOULD remain stable. Changes such as interface enable/disable, interface connect/disconnect, device reboot, firmware update, or configuration changes SHOULD NOT cause the System ID to change. System ID change as part of the System ID collision resolution process MUST be supported. Implementations SHOULD allow the System ID to be cleared by a user-initiated system reset.
- 最初の生成後、システムIDは安定したままである必要があります。インターフェースの有効化/無効化、インターフェースの接続/切断、デバイスの再起動、ファームウェアの更新、構成の変更などの変更によって、システムIDが変更されることはありません。システムIDの衝突解決プロセスの一部としてのシステムIDの変更をサポートする必要があります。実装では、ユーザーが開始したシステムリセットによってシステムIDをクリアできるようにする必要があります（SHOULD）。
More specific considerations for System ID generation are described in Section 3.4.5.
システムID生成に関するより具体的な考慮事項については、3.4.5項で説明します。
The Router-Fingerprint TLV is similar to the Router-Hardware-Fingerprint TLV defined in [RFC7503]. However, the TLV defined here includes a Flags field to support indicating that the router is in startup mode and is operating in autoconfiguration mode.
Router-Fingerprint TLVは、[RFC7503]で定義されているRouter-Hardware-Fingerprint 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | |
+-+-+-+-+-+-+-+-+ Router-Fingerprint (Variable) .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 15.
タイプ：15。
Length: The length, in octets, of the "Flags" and "Router-Fingerprint" fields.
長さ：「Flags」フィールドと「Router-Fingerprint」フィールドの長さ（オクテット単位）。
Flags: 1 octet.
フラグ：1オクテット。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S|A| Reserved |
+-+-+-+-+-+-+-+-+
S flag: When set, indicates the router is in "startup" mode.
Sフラグ：設定されている場合、ルーターが「起動」モードであることを示します。
A flag: When set, indicates that the router is operating in autoconfiguration mode. The purpose of the flag is so that two routers can identify if they are both using autoconfiguration. If the A flag setting does not match in hellos, then no adjacency should be formed.
フラグ：設定されている場合、ルーターが自動構成モードで動作していることを示します。フラグの目的は、2つのルーターが両方とも自動構成を使用しているかどうかを識別できるようにすることです。 Aフラグ設定がhelloで一致しない場合、隣接関係は形成されません。
Reserved: These flags MUST be set to zero and MUST be ignored by the receiver.
予約済み：これらのフラグはゼロに設定する必要があり、受信者は無視する必要があります。
Router-Fingerprint: 32 or more octets.
ルーターフィンガープリント：32オクテット以上。
More specific considerations for Router-Fingerprint are described in Section 3.4.5.
Router-Fingerprintに関するより具体的な考慮事項は、セクション3.4.5で説明されています。
The Router-Fingerprint TLV with the A flag set MUST be included in IS-IS Hellos (IIHs) originated by a router operating in autoconfiguration mode. An autoconfiguration mode router MUST ignore IIHs that don't contain the Router-Fingerprint TLV with the A flag set.
Aフラグが設定されたルーターフィンガープリントTLVは、自動構成モードで動作しているルーターから発信されたIS-IS Hello（IIH）に含める必要があります。自動構成モードのルーターは、Aフラグが設定されたルーターフィンガープリントTLVを含まないIIHを無視する必要があります。
The Router-Fingerprint TLV with the A flag set MUST be included in Link State PDU (LSP) #0 originated by a router operating in autoconfiguration mode. If an LSP #0 is received by a router operating in autoconfiguration mode and the LSP either does NOT contain a Router-Fingerprint TLV or it does contain a Router-Fingerprint TLV but the A flag is NOT set, then the LSP is flooded as normal, but the entire LSP set originated by the sending router MUST be ignored when running the Decision Process.
Aフラグが設定されたルーターフィンガープリントTLVは、自動構成モードで動作しているルーターから発信されたリンク状態PDU（LSP）＃0に含まれている必要があります。 LSP＃0が自動構成モードで動作しているルーターによって受信され、LSPにルーターフィンガープリントTLVが含まれていないか、ルーターフィンガープリントTLVが含まれているが、Aフラグが設定されていない場合、LSPは通常どおりフラッディングされます。ですが、決定プロセスを実行するときは、送信側ルーターから発信されたLSPセット全体を無視する必要があります。
The Router-Fingerprint TLV MUST NOT be included in an LSP with a non-zero number and when received MUST be ignored.
Router-Fingerprint TLVは、ゼロ以外の番号のLSPに含めてはならず（MUST NOT）、受け取った場合は無視する必要があります。
This section describes the operation of a router supporting autoconfiguration mode.
このセクションでは、自動構成モードをサポートするルーターの操作について説明します。
When a router starts operation in autoconfiguration mode, both the S and A flags MUST be set in the Router-Fingerprint TLV included in both hellos and LSP #0. During this mode, only LSP #0 is generated and IS or IP/IPv6 reachability TLVs MUST NOT be included in LSP #0. A router remains in startup mode for a minimum period of time (recommended to be 1 minute). This time should be sufficient to bring up adjacencies to all expected neighbors. A router leaves startup mode once the minimum time has elapsed and full LSP database synchronization is achieved with all neighbors in the UP state.
ルータが自動設定モードで動作を開始するとき、HとLSP＃0の両方に含まれるルータフィンガープリントTLVでSフラグとAフラグの両方を設定する必要があります。このモードでは、LSP＃0のみが生成され、ISまたはIP / IPv6到達可能性TLVをLSP＃0に含めてはなりません（MUST NOT）。ルーターは、最小限の時間（1分間にすることをお勧めします）は起動モードのままです。この時間は、予想されるすべてのネイバーに隣接関係をもたらすのに十分なはずです。最小時間が経過すると、ルータはスタートアップモードを終了し、すべてのネイバーがUP状態の完全なLSPデータベース同期が達成されます。
When a router exits startup mode, it clears the S flag in Router-Fingerprint TLVs that it sends in hellos and LSP #0. The router MAY now advertise the IS neighbor and IP/IPv6 prefix reachability in its LSPs and MAY generate LSPs with a non-zero number.
ルータがスタートアップモードを終了すると、helloおよびLSP＃0で送信するルータフィンガープリントTLVのSフラグがクリアされます。ルータは、LSPでISネイバーとIP / IPv6プレフィックス到達可能性をアドバタイズし、ゼロ以外の数のLSPを生成してもよい（MAY）。
The purpose of startup mode is to minimize the occurrence of System ID changes for a router once it has become fully operational. Any System ID change during startup mode will have minimal impact on a running network because, while in startup mode, the router is not yet being used for forwarding traffic.
起動モードの目的は、ルーターが完全に機能するようになったら、ルーターのシステムID変更の発生を最小限に抑えることです。起動モードの間、ルーターはまだトラフィックの転送に使用されていないため、起動モード中にシステムIDを変更しても、実行中のネットワークへの影響は最小限です。
Routers operating in autoconfiguration mode MUST NOT form adjacencies with routers that are NOT operating in autoconfiguration mode. The presence of the Router-Fingerprint TLV with the A flag set indicates the router is operating in autoconfiguration mode.
自動構成モードで動作しているルーターは、自動構成モードで動作していないルーターと隣接関係を形成してはなりません。 Aフラグが設定されたルーターフィンガープリントTLVが存在することは、ルーターが自動構成モードで動作していることを示します。
NOTE: The use of the special area address of all 0s makes it unlikely that a router that is not operating in autoconfiguration mode will be in the same area as a router operating in autoconfiguration mode. However, the check for the Router-Fingerprint TLV with the A flag set provides additional protection.
注：すべて0の特別なエリアアドレスを使用すると、自動構成モードで動作していないルーターが自動構成モードで動作しているルーターと同じエリアになることはほとんどありません。ただし、Aフラグが設定されたルーターフィンガープリントTLVのチェックは、追加の保護を提供します。
The System ID of each node MUST be unique. As described in Section 3.4.5, the System ID is generated based on entropies (e.g., Media Access Control (MAC) address) that are generally expected to be unique. However, since there may be limitations to the available entropies, there is still the possibility of System ID duplication. This section defines how IS-IS detects and resolves System ID duplication. A duplicate system ID may occur between neighbors or between routers in the same area that are not neighbors.
各ノードのシステムIDは一意である必要があります。セクション3.4.5で説明されているように、システムIDは、一般的に一意であると予想されるエントロピー（メディアアクセス制御（MAC）アドレスなど）に基づいて生成されます。ただし、使用可能なエントロピーには制限があるため、システムIDが重複する可能性があります。このセクションでは、IS-ISがシステムIDの重複を検出して解決する方法を定義します。重複するシステムIDは、ネイバー間、またはネイバーではない同じエリア内のルータ間で発生する可能性があります。
A duplicate system ID with a neighbor is detected when the System ID received in an IIH is identical to the local System ID and the Router-Fingerprint in the received Router-Fingerprint TLV does NOT match the locally generated Router-Fingerprint.
IIHで受信したシステムIDがローカルシステムIDと同一で、受信したルーターフィンガープリントTLVのルーターフィンガープリントがローカルで生成されたルーターフィンガープリントと一致しない場合、ネイバーとの重複したシステムIDが検出されます。
A duplicate system ID with a non-neighbor is detected when an LSP #0 is received, the System ID of the originator is identical to the local System ID, and the Router-Fingerprint in the Router-Fingerprint TLV does NOT match the locally generated Router-Fingerprint.
LSP＃0を受信すると、ネイバー以外のシステムIDの重複が検出され、発信元のシステムIDがローカルシステムIDと同一であり、ルーターフィンガープリントTLVのルーターフィンガープリントがローカルで生成されたものと一致しないルーターフィンガープリント。
When a duplicate system ID is detected, one of the systems MUST assign itself a different System ID and perform a protocol restart. The resolution procedure attempts to minimize disruption to a running network by choosing, whenever possible, to restart a router that is in startup mode.
重複するシステムIDが検出された場合、システムの1つはそれ自体に異なるシステムIDを割り当て、プロトコルの再起動を実行する必要があります。解決手順では、起動モードになっているルーターを再起動することを可能な限り選択することにより、実行中のネットワークへの影響を最小限に抑えようとします。
The contents of the Router-Fingerprint TLVs for the two routers with duplicate system IDs are compared.
重複するシステムIDを持つ2つのルーターのルーターフィンガープリントTLVの内容が比較されます。
If one TLV has the S flag set (the router is in startup mode) and one TLV has the S flag clear (the router is NOT in startup mode), the router in startup mode MUST generate a new System ID and restart the protocol.
1つのTLVにSフラグが設定されていて（ルーターが起動モードになっている）、1つのTLVにSフラグがクリアされている（ルーターが起動モードではない）場合、起動モードのルーターは新しいシステムIDを生成してプロトコルを再起動する必要があります。
If both TLVs have the S flag set (both routers are in startup mode) or both TLVs have the S flag clear (neither router is in startup mode), then the router with the numerically smaller Router-Fingerprint MUST generate a new System ID and restart the protocol.
両方のTLVにSフラグが設定されている（両方のルーターが起動モードになっている）場合、または両方のTLVにSフラグがクリアされている（どちらのルーターも起動モードになっていない）場合、数値が小さいルーターフィンガープリントを持つルーターは新しいシステムIDを生成する必要があり、プロトコルを再起動します。
Fingerprint comparison is performed octet by octet starting from the first received octet until a difference is detected. If the fingerprints have different lengths and all octets up to the shortest length are identical, then the fingerprint with smaller length is considered smaller on the whole.
指紋の比較は、最初に受信したオクテットから始まり、違いが検出されるまでオクテットごとに実行されます。フィンガープリントの長さが異なり、最短までのすべてのオクテットが同一である場合、長さが短いフィンガープリントは全体的に小さいと見なされます。
If the fingerprints are identical in both content and length (and the state of the S flag is identical), and the duplication is detected in hellos, then both routers MUST generate a new System ID and restart the protocol.
フィンガープリントがコンテンツと長さの両方で同一であり（かつSフラグの状態が同一）、重複がhelloで検出された場合、両方のルーターは新しいシステムIDを生成してプロトコルを再起動する必要があります。
If fingerprints are identical in both content and length, and the duplication is detected in LSP #0, then the procedures defined in Section 3.4.6 MUST be followed.
フィンガープリントが内容と長さの両方で同一であり、LSP＃0で重複が検出された場合、セクション3.4.6で定義された手順に従う必要があります。
As specified in this document, there are two distinguishing items that need to be self-generated: the System ID and Router-Fingerprint. In a network device, normally there are some resources that can provide an extremely high probability of uniqueness (some examples listed below). These resources can be used as seeds to derive identifiers:
このドキュメントで指定されているように、自己生成する必要がある2つの特徴的な項目があります。システムIDとルーターフィンガープリントです。ネットワークデバイスには、通常、非常に高い一意性の確率を提供できるリソースがいくつかあります（いくつかの例を以下にリストします）。これらのリソースは、識別子を導出するためのシードとして使用できます。
o MAC address(es)
o MACアドレス
o Configured IP address(es)
o 構成済みIPアドレス
o Hardware IDs (e.g., CPU ID)
o ハードウェアID（CPU IDなど）
o Device serial number(s)
o デバイスのシリアル番号
o System clock at a certain, specific time
o 特定の特定の時刻のシステムクロック
o Arbitrary received packet(s) on an interface(s) This document recommends the use of an IEEE 802 48-bit MAC address associated with the router as the initial System ID. This document does not specify a specific method to regenerate the System ID when duplication happens.
oインターフェイス上の任意の受信パケットこのドキュメントでは、初期システムIDとして、ルーターに関連付けられたIEEE 802 48ビットMACアドレスの使用を推奨しています。このドキュメントでは、重複が発生したときにシステムIDを再生成する特定の方法を指定していません。
This document also does not specify a method to generate the Router-Fingerprint.
このドキュメントでは、Router-Fingerprintを生成する方法も指定していません。
There is an important concern that the seeds listed above (except MAC address) might not be available in some small devices such as home routers. This is because of hardware/software limitations and the lack of sufficient communication packets at the initial stage in home routers when doing IS-IS autoconfiguration. In this case, this document suggests using the MAC address as the System ID and generating a pseudorandom number based on another seed (such as the memory address of a certain variable in the program) as the Router-Fingerprint. The pseudorandom number might not have a very high probability of uniqueness in this solution but should be sufficient in home network scenarios.
上記のシード（MACアドレスを除く）が、ホームルーターなどの一部の小型デバイスで使用できない場合があるという重要な懸念があります。これは、ハードウェア/ソフトウェアの制限と、IS-IS自動構成を実行するときのホームルーターの初期段階で十分な通信パケットがないためです。この場合、このドキュメントでは、MACアドレスをシステムIDとして使用し、ルーターフィンガープリントとして別のシード（プログラム内の特定の変数のメモリアドレスなど）に基づいて疑似乱数を生成することを提案しています。疑似乱数は、このソリューションでは一意性の確率がそれほど高くない場合がありますが、ホームネットワークシナリオでは十分です。
The considerations surrounding System ID stability described in Section 3.2 also need to be applied.
セクション3.2で説明されているシステムIDの安定性に関する考慮事項も適用する必要があります。
As described above, the resources for generating a System ID / Router-Fingerprint might be very constrained during the initial stages. Hence, the duplication of both System ID and Router-Fingerprint need to be considered. In such a case, it is possible that a router will receive an LSP with a System ID and Router-Fingerprint identical to the local values, but the LSP is NOT identical to the locally generated copy, i.e., the sequence number is newer or the sequence number is the same, but the LSP has a valid checksum that does not match. The term DD-LSP (Duplication Detection LSP) is used to describe such an LSP.
上記のように、システムID /ルーターフィンガープリントを生成するためのリソースは、初期段階で非常に制約を受ける可能性があります。したがって、システムIDとルーターフィンガープリントの両方の重複を考慮する必要があります。このような場合、ルーターはローカル値と同じシステムIDとルーターフィンガープリントのLSPを受信する可能性がありますが、LSPはローカルで生成されたコピーと同じではありません。つまり、シーケンス番号が新しいか、シーケンス番号は同じですが、LSPには一致しない有効なチェックサムがあります。 DD-LSP（重複検出LSP）という用語は、そのようなLSPを説明するために使用されます。
In a benign case, this will occur if a router restarts and it receives copies of its own LSPs from its previous incarnation. This benign case needs to be distinguished from the pathological case where there are two different routers with the same System ID and the same Router-Fingerprint.
良性の場合、これは、ルーターが再起動し、以前のインカネーションから独自のLSPのコピーを受信した場合に発生します。この良性のケースは、同じシステムIDと同じルーターフィンガープリントを持つ2つの異なるルーターが存在する病理的なケースと区別する必要があります。
In the benign case, the restarting router will generate a new version of its own LSP with a higher sequence number and flood the new LSP version. This will cause other routers in the network to update their LSP Database (LSPDB) and synchronization will be achieved.
良性の場合、再起動するルーターは、シーケンス番号の大きい独自のLSPの新しいバージョンを生成し、新しいLSPバージョンをフラッディングします。これにより、ネットワーク内の他のルーターがLSPデータベース（LSPDB）を更新し、同期が行われます。
In the pathological case, the generation of a new version of an LSP by one of the "twins" will cause the other twin to generate the same LSP with a higher sequence number -- and oscillation will continue without achieving LSPDB synchronization.
病理学的なケースでは、「ツイン」の1つによってLSPの新しいバージョンが生成されると、もう一方のツインはより高いシーケンス番号の同じLSPを生成し、LSPDB同期を達成せずに発振が継続します。
Note that a comparison of the S flag in the Router-Fingerprint TLV cannot be performed, as in the benign case it is expected that the S flag will be clear. Also note that the conditions for detecting a duplicate system ID will NOT be satisfied because both the System ID and the Router-Fingerprint will be identical.
良性の場合、Sフラグがクリアされることが予想されるため、Router-Fingerprint TLVのSフラグの比較は実行できないことに注意してください。また、システムIDとルーターフィンガープリントの両方が同一であるため、重複したシステムIDを検出するための条件が満たされないことに注意してください。
The following procedure is defined:
以下の手順が定義されています。
DD-state is a boolean that indicates if a DD-LSP #0 has been received. DD-count is the count of the number of occurrences of reception of a DD-LSP. DD-timer is a timer associated with reception of DD-LSPs; the recommended value is 60 seconds. DD-max is the maximum number of DD-LSPs allowed to be received in DD-timer interval; the recommended value is 3.
DD-stateは、DD-LSP＃0が受信されたかどうかを示すブール値です。 DD-countは、DD-LSPの受信の発生回数のカウントです。 DDタイマーは、DD-LSPの受信に関連付けられたタイマーです。推奨値は60秒です。 DD-maxは、DDタイマー間隔で受信できるDD-LSPの最大数です。推奨値は3です。
When a DD-LSP is received:
DD-LSPを受信した場合：
If DD-state is FALSE: DD-state is set to TRUE. DD-timer is started. DD-count is initialized to 1.
DD-stateがFALSEの場合：DD-stateはTRUEに設定されます。 DDタイマーが開始されます。 DDカウントは1に初期化されます。
If DD-state is TRUE: DD-count is incremented. If DD-count is >= DD-max: The local system MUST generate a new System ID and Router-Fingerprint and restart the protocol. DD-state is (re)initialized to FALSE and DD-timer is canceled.
DD状態がTRUEの場合：DDカウントが増分されます。 DDカウントが> = DD-maxの場合：ローカルシステムは、新しいシステムIDとルーターフィンガープリントを生成し、プロトコルを再起動する必要があります。 DD状態は（再）初期化されてFALSEになり、DDタイマーはキャンセルされます。
If DD-timer expires: DD-state is set to FALSE.
DDタイマーの期限が切れた場合：DD状態はFALSEに設定されます。
Note that to minimize the likelihood of duplication of both System ID and Router-Fingerprint reoccurring, routers SHOULD have more entropies available. One simple way to achieve this is to add the LSP sequence number of the next LSP it will send to the Router-Fingerprint.
システムIDとルーターフィンガープリントの両方が重複する可能性を最小限に抑えるために、ルーターはより多くのエントロピーを利用できる必要があることに注意してください。これを実現する簡単な方法の1つは、ルーターフィンガープリントに送信する次のLSPのLSPシーケンス番号を追加することです。
This section describes the behavior of selected TLVs when used by a router supporting IS-IS autoconfiguration.
このセクションでは、IS-IS自動構成をサポートするルーターが使用する場合の、選択したTLVの動作について説明します。
It is RECOMMENDED that IS-IS routers supporting this specification offer an option to explicitly configure a single password for HMAC-MD5 authentication as specified in [RFC5304].
この仕様をサポートするIS-ISルーターは、[RFC5304]で指定されているように、HMAC-MD5認証用に単一のパスワードを明示的に構成するオプションを提供することをお勧めします。
It is RECOMMENDED that IS-IS autoconfiguration routers use a high metric value (e.g., 100000) as default in order to allow manually configured adjacencies to be preferred over autoconfigured.
IS-IS自動構成ルーターは、手動で構成された隣接関係を自動構成よりも優先できるようにするために、デフォルトで高いメトリック値（たとえば、100000）を使用することをお勧めします。
IS-IS autoconfiguration routers MAY advertise their Dynamic Name TLV (TLV 137 [RFC5301]). The hostname could be provisioned by an IT system or just use the name of vendor, device type, or serial number, etc.
IS-IS自動構成ルーターは、動的名TLV（TLV 137 [RFC5301]）を通知できます（MAY）。ホスト名は、ITシステムによってプロビジョニングされるか、ベンダーの名前、デバイスタイプ、シリアル番号などを使用することができます。
To guarantee the uniqueness of the hostname, the System ID SHOULD be appended as a suffix in the names.
ホスト名の一意性を保証するために、システムIDは名前のサフィックスとして追加する必要があります（SHOULD）。
In the absence of cryptographic authentication, it is possible for an attacker to inject a PDU falsely indicating there is a duplicate system ID. This may trigger automatic restart of the protocol using the duplicate-id resolution procedures defined in this document.
暗号化認証がない場合、攻撃者が重複したシステムIDがあることを示すPDUを誤って挿入する可能性があります。これにより、このドキュメントで定義されている重複ID解決手順を使用して、プロトコルの自動再起動がトリガーされる場合があります。
Note that the use of authentication is incompatible with autoconfiguration as it requires some manual configuration.
認証の使用は、手動構成が必要なため、自動構成と互換性がないことに注意してください。
For wired deployment, the wired connection itself could be considered as an implicit authentication in that unwanted routers are usually not able to connect (i.e., there is some kind of physical security in place preventing the connection of rogue devices); for wireless deployment, the authentication could be achieved at the lower wireless link layer.
有線展開の場合、有線接続自体は、不要なルーターが通常は接続できないという点で、暗黙の認証と見なすことができます（つまり、不正なデバイスの接続を妨げる何らかの物理的なセキュリティがあります）。ワイヤレス展開の場合、認証は下位のワイヤレスリンク層で実現できます。
This document details a new IS-IS TLV reflected in the "IS-IS TLV Codepoints" registry:
このドキュメントでは、「IS-IS TLVコードポイント」レジストリに反映された新しいIS-IS TLVについて詳しく説明します。
Value Name IIH LSP SNP Purge
---- ------------ --- --- --- -----
15 Router-Fingerprint Y Y N Y
[ISO_IEC10589] International Organization for Standardization, "Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, November 2002.
[ISO_IEC10589]国際標準化機構、「情報技術-システム間のテレコミュニケーションおよび情報交換-コネクションレスモードのネットワークサービス（ISOを提供するためのプロトコルと組み合わせて使用するための中間システムから中間システムのドメイン内ルーティング情報交換プロトコル8473） "、ISO / IEC 10589：2002、Second Edition、2002年11月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, <http://www.rfc-editor.org/info/rfc1195>.
[RFC1195] Callon、R。、「TCP / IPおよびデュアル環境でのルーティングのためのOSI IS-ISの使用」、RFC 1195、DOI 10.17487 / RFC1195、1990年12月、<http://www.rfc-editor.org/ info / rfc1195>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, October 2008, <http://www.rfc-editor.org/info/rfc5301>.
[RFC5301]マクファーソン、D。およびN.シェン、「IS-ISのダイナミックホスト名交換メカニズム」、RFC 5301、DOI 10.17487 / RFC5301、2008年10月、<http://www.rfc-editor.org/info/rfc5301 >。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, <http://www.rfc-editor.org/info/rfc5304>.
[RFC5304] Li、T。およびR. Atkinson、「IS-IS Cryptographic Authentication」、RFC 5304、DOI 10.17487 / RFC5304、2008年10月、<http://www.rfc-editor.org/info/rfc5304>。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5305] Li、T。およびH. Smit、「IS-IS Extensions for Traffic Engineering」、RFC 5305、DOI 10.17487 / RFC5305、2008年10月、<http://www.rfc-editor.org/info/rfc5305> 。
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, DOI 10.17487/RFC5308, October 2008, <http://www.rfc-editor.org/info/rfc5308>.
[RFC5308] Hopps、C。、「Routing IPv6 with IS-IS」、RFC 5308、DOI 10.17487 / RFC5308、2008年10月、<http://www.rfc-editor.org/info/rfc5308>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「あいまいな大文字と小文字のRFC 2119キーワード」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<http://www.rfc-editor.org/info/ rfc8174>。
[RFC7503] Lindem, A. and J. Arkko, "OSPFv3 Autoconfiguration", RFC 7503, DOI 10.17487/RFC7503, April 2015, <http://www.rfc-editor.org/info/rfc7503>.
[RFC7503] Lindem、A。およびJ. Arkko、「OSPFv3 Autoconfiguration」、RFC 7503、DOI 10.17487 / RFC7503、2015年4月、<http://www.rfc-editor.org/info/rfc7503>。
Acknowledgements
謝辞
This document was heavily inspired by [RFC7503].
このドキュメントは[RFC7503]に強く触発されました。
Martin Winter, Christian Franke, and David Lamparter gave essential feedback to improve the technical design based on their implementation experience.
Martin Winter、Christian Franke、David Lamparterは、実装経験に基づいて技術設計を改善するために不可欠なフィードバックを提供しました。
Many useful comments were made by Acee Lindem, Karsten Thomann, Hannes Gredler, Peter Lothberg, Uma Chundury, Qin Wu, Sheng Jiang, and Nan Wu, etc.
多くの有用なコメントが、Acee Lindem、Karsten Thomann、Hannes Gredler、Peter Lothberg、Uma Chundury、Qin Wu、Sheng Jiang、Nan Wuなどから寄せられました。
Authors' Addresses
著者のアドレス
Bing Liu (editor) Huawei Technologies Q10, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China
Bing l IU（編集者）hu AはテクノロジーQ10、hu Aはキャンパス、No.156 be i青路H艾-Dイアン地区、北京、中国
Email: leo.liubing@huawei.com
Les Ginsberg Cisco Systems 821 Alder Drive Milpitas CA 95035 United States of America
Les Ginsberg Cisco Systems 821 Alder Drive Milpitas CA 95035アメリカ合衆国
Email: ginsberg@cisco.com
Bruno Decraene Orange France
Bruno Decraene Orange France
Email: bruno.decraene@orange.com
Ian Farrer Deutsche Telekom AG Bonn Germany
Ian Farrer Deutsche Telekom AGボンドイツ
Email: ian.farrer@telekom.de
Mikael Abrahamsson T-Systems Stockholm Sweden
Mikael Abrahamsson T-Systemsストックホルムスウェーデン
Email: mikael.abrahamsson@t-systems.se