[要約] RFC 5303は、IS-ISポイントツーポイント隣接のための三方向ハンドシェイクに関する規格です。このRFCの目的は、IS-ISプロトコルのポイントツーポイント隣接の確立と維持を効率的に行うための手順を定義することです。
Network Working Group D. Katz
Request for Comments: 5303 Juniper Networks
Obsoletes: 3373 R. Saluja
Category: Standards Track Tenet Technologies
D. Eastlake 3rd
Eastlake Enterprises
October 2008
Three-Way Handshake for IS-IS Point-to-Point Adjacencies
IS-ISポイントツーポイントの隣接のための3方向の握手
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
The IS-IS routing protocol (Intermediate System to Intermediate System, ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to-point media. This paper defines a backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension.
IS-ISルーティングプロトコル（中間システムから中間システム、ISO 10589）には、ポイントツーポイントリンクのリンクレイヤーで信頼できるプロトコルが必要です。その結果、ポイントツーポイントメディアで隣接を確立する際には、3方向の握手を使用しません。このペーパーでは、3方向の握手を提供するプロトコルの後方互換拡張機能を定義します。拡張機能をサポートしていないシステムと完全に相互運用可能です。
Additionally, the extension allows the robust operation of more than 256 point-to-point links on a single router.
さらに、拡張により、単一のルーター上の256以上のポイントツーポイントリンクの堅牢な操作が可能になります。
This extension has been implemented by multiple router vendors; this paper is provided to the Internet community in order to allow interoperable implementations to be built by other vendors.
この拡張機能は、複数のルーターベンダーによって実装されています。このペーパーは、相互運用可能な実装を他のベンダーによって構築できるようにするために、インターネットコミュニティに提供されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Overview of Extensions ..........................................3
2.1. Handshaking ................................................3
2.2. More than 256 Interfaces ...................................4
3. Details .........................................................5
3.1. Syntax .....................................................5
3.2. Elements of Procedure ......................................6
4. IANA Considerations .............................................8
5. Security Considerations .........................................9
6. Changes from RFC 3373 ...........................................9
7. Acknowledgements ................................................9
8. Normative References ............................................9
9. Informative References ..........................................9
The IS-IS protocol [ISIS] assumes certain requirements stated in ISO 10589 (section 6.7.2) for the operation of IS-IS over point-to-point links and hence provides only a two-way handshake when establishing adjacencies on point-to-point links. The protocol does not operate correctly if these subnetwork requirements for point-to-point links are not met. The basic mechanism defined in the standard is that each side declares the other side to be reachable if a Hello packet is heard from it. Once this occurs, each side then sends a Complete Sequence Number PDU (CSNP) to trigger database synchronization.
IS-ISプロトコル[ISIS]は、ポイントツーポイントリンクを超えるIS-I-ISの操作のためにISO 10589（セクション6.7.2）に記載されている特定の要件を想定しているため、ポイントに隣接を確立するときに双方向の握手のみを提供します。トゥポイントリンク。ポイントツーポイントリンクのこれらのサブネットワーク要件が満たされていない場合、プロトコルは正しく動作しません。標準で定義されている基本的なメカニズムは、ハローパケットがそこから聞かれると、両側が反対側に到達可能であると宣言することです。これが発生すると、各側は完全なシーケンス番号PDU（CSNP）を送信して、データベースの同期をトリガーします。
Three failure modes are known. First, if the link goes down and then comes back up, or one of the systems restarts, and the CSNP packet is lost, and the network has a cut set of one through the link, the link state databases on either side of the link will not synchronize for a full Link State Protocol Data Unit (LSP) refresh period (up to 18 hours).
3つの障害モードが既知です。まず、リンクが下がってから戻ってきた場合、またはシステムの1つが再起動し、CSNPパケットが失われ、ネットワークにリンクを介して1つのカットセットがあり、リンクの両側にリンク状態データベースがあります。完全なリンク状態プロトコルデータユニット（LSP）の更新期間（最大18時間）の場合は同期しません。
A second, more serious failure is that if the link fails in only one direction, the failure will only be detected by one of the systems. Normally only one of the two systems will announce the adjacency in its link state packets, and the SPF algorithm will thus ignore the link. However, if there are two parallel links between systems and one of them fails in one direction, SPF will still calculate paths between the two systems, and the system that does not notice the failure will attempt to pass traffic down the failed link (in the direction that does not work).
2番目のより深刻な障害は、リンクが1つの方向のみで故障した場合、障害はシステムの1つによってのみ検出されることです。通常、2つのシステムのうち1つだけがリンク状態パケットの隣接性を発表し、SPFアルゴリズムはリンクを無視します。ただし、システムの間に2つの並列リンクがある場合、およびそのうちの1つが一方向に失敗した場合、SPFは2つのシステム間のパスを計算し、障害に気付かないシステムはトラフィックを故障したリンクに渡そうとします（機能しない方向）。
The third issue is that on some physical layers, the interconnectivity between endpoints can change without causing a link-layer-down condition. In this case, a system may receive packets that are actually destined for a different system (or a different link on the same system). The receiving system may end up thinking that it has an adjacency with the remote system when in fact the remote system is adjacent with a third system.
3番目の問題は、一部の物理層では、エンドポイント間の相互接続性がリンク層ダウン条件を引き起こすことなく変化する可能性があることです。この場合、システムは、実際には別のシステム（または同じシステム上の異なるリンク）に運命づけられているパケットを受信する場合があります。レシーブシステムは、リモートシステムが3番目のシステムに隣接している場合、リモートシステムに隣接すると考えることになる可能性があります。
The solution proposed here ensures correct operation of the protocol over unreliable point-to-point links. As part of the solution to the three-way handshaking issue, a method is defined to remove the limitation of 255 point-to-point interfaces imposed by IS-IS [ISIS]. This method is more robust than the ad hoc methods currently in use.
ここで提案されているソリューションは、信頼できないポイントツーポイントリンクに対するプロトコルの正しい動作を保証します。3方向のハンドシェイクの問題の解決策の一部として、IS-IS [ISIS]によって課される255ポイントツーポイントインターフェイスの制限を削除する方法が定義されています。この方法は、現在使用されているアドホックメソッドよりも堅牢です。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
This section provides a general overview of the three-way handshaking provided and how more than 256 interfaces are handled.
このセクションでは、提供された3方向のハンドシェーキングの一般的な概要と、256を超えるインターフェイスがどのように処理されるかを示します。
The intent is to provide a three-way handshake for point-to-point adjacency establishment in a backward-compatible fashion. This is done by providing an optional mechanism that allows each system to report its adjacency three-way state, thus allowing a system to only declare an adjacency to be up if it knows that the other system is receiving its IS-IS Hello (IIH) packets.
意図は、後方互換性のある方法で、ポイントツーポイント隣接施設の施設に3方向の握手を提供することです。これは、各システムが隣接する3方向状態を報告できるオプションのメカニズムを提供することによって行われます。したがって、他のシステムがIS-IS Hello（IIH）を受信していることを知っている場合、システムは隣接することを宣言できるようになります。パケット。
The adjacency three-way state can be one of the following types:
隣接する三者状態は、次のタイプのいずれかになります。
Down This is the initial point-to-point adjacency three-way state. The system has not received any IIH packet containing the three-way handshake option on this point-to-point circuit.
ダウンこれは、最初のポイントツーポイント隣接3方向の状態です。このシステムは、このポイントツーポイントサーキットに3方向の握手オプションを含むIIHパケットを受信していません。
Initializing The system has received an IIH packet containing the three-way handshake option from a neighbor but does not know whether the neighbor is receiving its IIH packet.
システムの初期化は、隣人からの3方向のハンドシェイクオプションを含むIIHパケットを受信しましたが、隣人がIIHパケットを受け取っているかどうかはわかりません。
Up The system knows that the neighbor is receiving its IIH packets.
UPシステムは、隣人がIIHパケットを受け取っていることを知っています。
The adjacency three-way state that is reported by this mechanism is not equal or equivalent to the adjacency state that is described in ISO 10589 [ISIS]. If this mechanism is supported, then an adjacency may have two states, its state as defined in ISO 10589 [ISIS], and its three-way state. For example, according to ISO 10589, receipt of an Intermediate System Hello (ISH) will cause an adjacency to go to Initializing state; however, receipt of an ISH will have no effect on the three-way state of an adjacency, which remains firmly Down until it receives an IIH from a neighbor that contains the three-way handshaking option.
このメカニズムによって報告されている隣接する三者状態は、ISO 10589 [ISIS]に記載されている隣接国と同等または同等ではありません。このメカニズムがサポートされている場合、隣接は2つの状態を持ち、ISO 10589 [ISIS]で定義されている状態とその3方向の状態です。たとえば、ISO 10589によると、中間システムの受領Hello（ISH）は、隣接を初期化状態にします。ただし、ISHの受領は、隣接の3方向の状態に影響を与えません。これは、3方向のハンドシェーキングオプションを含む隣人からIIHを受け取るまでしっかりと下がっています。
In addition, the neighbor's system ID and (newly defined) extended circuit ID are reported in order to detect the case where the same stream is being received by multiple systems (only one of which can talk back).
さらに、同じストリームが複数のシステムで受信されている場合（そのうちの1つのみが話し合うことができる）を検出するために、NeighborのシステムIDおよび（新しく定義された）拡張回路IDが報告されます。
The mechanism is quite similar to the one defined in the Netware Link Services Protocol (NLSP) [NetLink], a variant of IS-IS used for routing Internetwork Packet Exchange (IPX) traffic. The difference between this mechanism and the one used in NLSP is the location where the information is carried (NLSP uses two of the reserved bits in the IIH header, whereas this solution adds a separate option to the IIH), and the presence of the neighbor's system ID and circuit ID. In theory, using the reserved header bits should be backward compatible, since systems are supposed to ignore them. However, it was felt that this was risky, as the use of untested mechanisms such as this have led to problems in the past in other protocols. New option codes, on the other hand, have been demonstrated to work properly, as the deployment of Integrated IS-IS for IP [RFC1195] has done exactly this.
このメカニズムは、IS-I-ISのバリアントであるNetware Link Services Protocol（NLSP）[NetLink]で定義されているメカニズムと非常によく似ています。このメカニズムの違いとNLSPで使用されるメカニズムの違いは、情報が伝達される場所です（NLSPはIIHヘッダーの2つの予約ビットを使用しますが、このソリューションはIIHに別のオプションを追加します）、および隣人の存在はシステムIDと回路ID。理論的には、システムはそれらを無視することになっているため、予約されたヘッダービットを使用することは後方互換である必要があります。しかし、このようなテストされていないメカニズムの使用が他のプロトコルで過去に問題をもたらしたため、これは危険であると感じられました。一方、新しいオプションコードは、IP [RFC1195]の統合IS-I-ISの展開がまさにこれを行ったため、適切に機能することが実証されています。
The new mechanism only comes into play when the remote system includes the new option in its IIH packet; if the option is not present, it is assumed that the system does not support the new mechanism, and so the old procedures are used.
新しいメカニズムは、リモートシステムにIIHパケットに新しいオプションが含まれている場合にのみ機能します。オプションが存在しない場合、システムが新しいメカニズムをサポートしていないため、古い手順が使用されると想定されています。
The IS-IS specification has an implicit limit of 256 interfaces, as constrained by the eight-bit Circuit ID field carried in various packets. Moderately clever implementers have realized that the only true constraint is that of 256 LAN interfaces, and for that matter only 256 LAN interfaces for which a system is the Designated IS. This is because the only place that the circuit ID is advertised in LSPs is in the pseudo-node LSP ID.
IS-IS仕様には、さまざまなパケットで運ばれる8ビット回路IDフィールドによって制約されるように、256インターフェイスの暗黙的な制限があります。適度に賢い実装者は、唯一の真の制約は256 LANインターフェイスの唯一の制約であることを認識しており、そのため、システムが指定されている256 LANインターフェイスのみです。これは、LSPで回路IDが宣伝されている唯一の場所が擬似ノードLSP IDにあるためです。
Implementers have treated the point-to-point circuit ID number space as being independent from that of the LAN interfaces, since these circuit IDs appear only in IIH PDUs and are only used for detection of a change in identity at the other end of a link. More than 256 point-to-point interfaces have been supported by sending the same circuit ID on multiple interfaces. This reduces the robustness of the ID change detection algorithm, since it would then be possible to switch links between interfaces on a system without detecting the change.
これらの回路IDはIIH PDUにのみ表示され、リンクの反対側のアイデンティティの変化の検出にのみ使用されるため、実装者はポイントツーポイント回路ID番号スペースをLANインターフェイスから独立していると扱いました。。複数のインターフェイスで同じ回路IDを送信することにより、256以上のポイントツーポイントインターフェイスがサポートされています。これにより、ID変更検出アルゴリズムの堅牢性が低下します。これは、変更を検出せずにシステム上のインターフェイス間のリンクを切り替えることができるためです。
Since the circuit ID is an integral part of the new handshaking mechanism, a backward-compatible mechanism for expanding the circuit ID number space is included in this specification.
回路IDは新しいハンドシェイクメカニズムの不可欠な部分であるため、回路ID番号スペースを拡張するための後方互換のメカニズムがこの仕様に含まれています。
The detailed syntax and procedures for this IS-IS option are given below.
このIS-ISオプションの詳細な構文と手順を以下に示します。
A new IS-IS Option type, "Point-to-Point Three-Way Adjacency", is defined:
新しいIS-ISオプションタイプ「ポイントツーポイント3ウェイ隣接」が定義されています。
Type - 0xF0 (decimal 240)
タイプ-0xf0（10進240）
Length - total length of the value field (1 to 17 octets)
長さ - 値フィールドの全長（1〜17オクテット）
Value -
No. of Octets
+-----------------------------------+
| Adjacency Three-Way State | 1
+-----------------------------------+
| Extended Local Circuit ID | 4
+-----------------------------------+
| Neighbor System ID | ID Length
+-----------------------------------+
| Neighbor Extended Local Circuit ID| 4
+-----------------------------------+
Adjacency Three-Way State The adjacency three-way state of the point-to-point adjacency. The following values are defined:
隣接する三者状態隣接するポイントツーポイント隣接の3方向状態。次の値が定義されています。
0 - Up 1 - Initializing 2 - Down
0 -UP 1-初期化2-ダウン
Extended Local Circuit ID Unique ID assigned to this circuit when it is created by this Intermediate system.
この中間システムによって作成されたときに、この回路に割り当てられた拡張ローカル回路ID一意のID。
Neighbor System ID System ID of neighboring Intermediate system if known. The length of this field is equal to "ID Length" of the IIH PDU described in "Point-to-point IS to IS hello PDU" (section 9.7 of [ISIS]).
既知の場合、隣接する中間システムの隣接システムIDシステムID。このフィールドの長さは、「ポイントツーポイントはIS Hello PDU」（[ISIS]のセクション9.7）に記載されているIIH PDUの「ID長」に等しくなります。
Neighbor Extended Local Circuit ID Extended Local Circuit ID of the other end of the point-to-point adjacency if known.
近隣のローカル回路IDは、既知の場合、ポイントツーポイント隣接の反対側のローカル回路IDを拡張しました。
Any system that supports this mechanism SHALL include this option in its Point-to-Point IIH packets.
このメカニズムをサポートするシステムは、このオプションをポイントツーポイントIIHパケットに含めるものとします。
Any system that does not understand this option SHALL ignore it, and (of course) SHALL NOT include it in its own IIH packets.
このオプションを理解していないシステムは、それを無視するものとし、（もちろん）独自のIIHパケットにそれを含めてはなりません。
Any system that supports this mechanism MUST include the Adjacency Three-Way State field in this option. The other fields in this option SHOULD be included as explained below in section 3.2.
このメカニズムをサポートするシステムには、このオプションに隣接する3方向状態フィールドを含める必要があります。このオプションの他のフィールドは、セクション3.2で以下に説明するように含める必要があります。
Any system that is able to process this option SHALL follow the procedures below.
このオプションを処理できるシステムは、以下の手順に従う必要があります。
The new handshake procedure is added to the IS-IS point-to-point IIH state machine after the PDU acceptance tests have been performed.
PDU受け入れテストが実行された後、新しい握手手順がIS-ISポイントツーポイントIIH状態マシンに追加されます。
Although the extended circuit ID is only used in the context of the three-way handshake, it is worth noting that it effectively protects against the unlikely event where a link is moved to another interface on a system that has the same local circuit ID, because the received PDUs will be ignored (via the checks defined below) and the existing adjacency will fail.
拡張回路IDは3方向の握手のコンテキストでのみ使用されますが、同じローカル回路IDを持つシステム上の別のインターフェイスにリンクが移動される可能性の低いイベントから効果的に保護することは注目に値します。受信したPDUは（以下に定義されているチェックを介して）無視され、既存の隣接は失敗します。
Add a clause e) to the end of "Receiving ISH PDUs by an intermediate system" (section 8.2.2 of [ISIS]):
「中間システムによるISH PDUを受信する」（[ISIS]のセクション8.2.2）の最後に、条項e）を追加します。
Set the state to be reported in the Adjacency Three-Way State field of the Point-to-Point Three-Way Adjacency option to Down.
状態を設定して、ポイントツーポイント3ウェイ隣接隣接オプションの隣接する3方向状態フィールドでダウンします。
Add a clause e) to the end of "Sending point-to-point IIH PDUs" (section 8.2.3 of [ISIS]):
「ポイントツーポイントIIH PDUを送信する」（[ISIS]のセクション8.2.3）の終わりまで節eを追加する）：
The IS SHALL include the Point-to-Point Three-Way Adjacency option in the transmitted Point-to-Point IIH PDU. The current three-way state of the adjacency with its neighbor on the link (as defined in new section 8.2.4.1.1 introduced later in the document) SHALL be reported in the Adjacency Three-Way State field. If no adjacency exists, the state SHALL be reported as Down.
ISには、送信されたポイントツーポイントIIH PDUにポイントツーポイント3ウェイ隣接オプションが含まれます。リンク上の隣人との隣接の現在の3方向状態（ドキュメントで後半に導入された新しいセクション8.2.4.1.1で定義されている）は、隣接する3方向の状態フィールドで報告されるものとします。隣接が存在しない場合、状態はダウンとして報告されます。
The Extended Local Circuit ID field SHALL contain a value assigned by this IS when the circuit is created. This value SHALL be unique among all the circuits of this Intermediate System. The value is not necessarily related to that carried in the Local Circuit ID field of the IIH PDU.
拡張されたローカル回路IDフィールドには、回路が作成された場合に割り当てられた値が含まれます。この値は、この中間システムのすべての回路の中で一意でなければなりません。値は、IIH PDUのローカル回路IDフィールドにあるものに必ずしも関連しているわけではありません。
If the system ID and Extended Local Circuit ID of the neighboring system are known (in adjacency three-way state Initializing or Up), the neighbor's system ID SHALL be reported in the Neighbor System ID field, and the neighbor's Extended Local Circuit ID SHALL be reported in the Neighbor Extended Local Circuit ID field.
隣接システムのシステムIDと拡張されたローカル回路IDが既知である場合（隣接する3方向状態の初期化またはアップ）、近隣のシステムIDが近隣システムIDフィールドで報告され、隣接するローカル回路IDは近隣の拡張ローカル回路IDフィールドで報告されています。
Add a section 8.2.4.1.1, "Three-Way Handshake", immediately prior to "IIH PDU Processing" (section 8.2.4.2 of [ISIS]):
「IIH PDU処理」（[ISIS]のセクション8.2.4.2）の直前に、セクション8.2.4.1.1「3方向の握手」を追加します。
A received Point-to-Point IIH PDU may or may not contain the Point-to-Point Three-Way Adjacency option. If it does not, the link is assumed to be functional in both directions, and the procedures described in section 8.2.4.2 are followed.
受け取ったポイントツーポイントIIH PDUには、ポイントツーポイントの3方向隣接オプションが含まれる場合と含まない場合があります。そうでない場合、リンクは両方方向に機能していると想定され、セクション8.2.4.2で説明されている手順に従います。
If the option is present and contains invalid Adjacency Three-Way State, the PDU SHALL be discarded and no further action is taken.
オプションが存在し、無効な隣接する3者制度が含まれている場合、PDUは廃棄され、さらなる措置は取られません。
If the option with a valid Adjacency Three-Way State is present, the Neighbor System ID and Neighbor Extended Local Circuit ID fields, if present, SHALL be examined. If they are present, and the Neighbor System ID contained therein does not match the local system's ID, or the Neighbor Extended Local Circuit ID does not match the local system's extended circuit ID, the PDU SHALL be discarded and no further action is taken.
有効な隣接隣接の3方向状態を持つオプションが存在する場合、neighbor System IDと隣人は、存在する場合はローカル回路IDフィールドを拡張しました。それらが存在し、そこに含まれる隣接システムIDがローカルシステムのIDと一致しない場合、または近隣の拡張ローカル回路IDがローカルシステムの拡張回路IDと一致しない場合、PDUは破棄され、それ以上のアクションは実行されません。
If the Neighbor System ID and Neighbor Extended Local Circuit ID fields match those of the local system, or are not present, the procedures described in section 8.2.4.2 are followed with the following changes: a) In section 8.2.4.2 a and b, the action "Up" from state tables 5, 6, 7, and 8 may create a new adjacency but the three-way state of the adjacency SHALL be Down.
隣接システムIDと隣接拡張されたローカル回路IDフィールドがローカルシステムのものと一致する場合、または存在しない場合、セクション8.2.4.2で説明されている手順に次の変更が続きます。a）セクション8.2.4.2 aおよびb、状態表5、6、7、8からのアクションは、新しい隣接を生み出す可能性がありますが、隣接の3方向の状態は減少するものとします。
b) If the action taken from section 8.2.4.2 a or b is "Up" or "Accept", the IS SHALL perform the action indicated by the new adjacency three-way state table below, based on the current adjacency three-way state and the received Adjacency Three-Way State value from the option. (Note that the procedure works properly if neither field is ever included. This provides backward compatibility to an earlier version of this option.)
b) セクション8.2.4.2 AまたはBから取得したアクションが「UP」または「Accept」である場合、ISは、現在の隣接3方向状態と次の3方向の新しい隣接3方向表面表で示されているアクションを実行するものとします。オプションから隣接する3階建ての状態価値を受け取りました。（どちらのフィールドも含まれていない場合、手順は適切に機能することに注意してください。これにより、このオプションの以前のバージョンへの後方互換性が提供されます。）
Received Adjacency Three-Way State
Down Initializing Up
--------------------------------------
Down | Initialize Up Down
|
Adj. Initializing | Initialize Up Up
Three- |
Way Up | Initialize Accept Accept
State |
|
Adjacency Three-Way State Table
隣接する3方向の状態テーブル
If the new action is "Down", an adjacencyStateChange(Down) event is generated with the reason "Neighbor restarted" and the adjacency SHALL be deleted.
新しいアクションが「ダウン」の場合、隣接するStateChange（ダウン）イベントが「Neighborが再起動」され、隣接が削除される理由とともに生成されます。
If the new action is "Initialize", no event is generated and the adjacency three-way state SHALL be set to "Initializing".
新しいアクションが「初期化」されている場合、イベントは生成されず、隣接する三者状態が「初期化」に設定されます。
If the new action is "Up", an adjacencyStateChange(Up) event is generated.
新しいアクションが「UP」の場合、隣接するStateChange（UP）イベントが生成されます。
c) Skip section 8.2.4.2 c and d.
c) セクション8.2.4.2 CおよびDをスキップします。
d) If the new action is "Initialize", "Up", or "Accept", follow section 8.2.4.2 e.
d) 新しいアクションが「初期化」、「アップ」、または「受け入れる」の場合、セクション8.2.4.2 eに従ってください。
This document specifies IS-IS Option 240 (0xF0), which has already been allocated. See [RFC3359].
このドキュメントは、すでに割り当てられているIS-ISオプション240（0xF0）を指定しています。[RFC3359]を参照してください。
This document raises no new security issues for IS-IS. IS-IS security may be used to secure the IS-IS messages discussed here. See [RFC5304].
このドキュメントは、IS-ISの新しいセキュリティの問題を提起しません。IS-ISセキュリティは、ここで説明するIS-ISメッセージを保護するために使用できます。[RFC5304]を参照してください。
This document is a minor edit of [RFC3373] with the intent of advancing it from Informational to Standards Track. It also updates the ISP 10589 reference to refer to the current "2002" version.
このドキュメントは、[RFC3373]のマイナーな編集であり、情報を情報化から標準トラックに進めることを目的としています。また、ISP 10589リファレンスを更新して、現在の「2002」バージョンを参照します。
Thanks to Tony Li, Henk Smit, Naiming Shen, Dave Ward, Jeff Learman, Les Ginsberg, and Philip Christian for their contributions to the document.
Tony Li、Henk Smit、Naiming Shen、Dave Ward、Jeff Learman、Les Ginsberg、およびPhilip Christianの文書への貢献に感謝します。
[ISIS] ISO, "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)", International Standard 10589:2002, Second Edition, 2002.
[ISIS] ISO、「Connectionless-Mode Network Service（ISO 8473）を提供するためのプロトコルと組み合わせて使用するための情報交換プロトコル（ISO 8473）を使用するための中間システムへの中間システムへの中間システムへの中間システムからの情報交換プロトコル」、International Standard 10589：2002、第2版、2002。
[NetLink] "Netware Link Services Protocol Specification, Version 1.0", Novell, Inc., February 1994.
[NetLink] "Netware Link Services Protocol Specification、バージョン1.0"、Novell、Inc。、1994年2月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R。、「TCP/IPおよびデュアル環境でのルーティングのためのOSI IS-I-ISの使用」、RFC 1195、1990年12月。
[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月。
[RFC3373] Katz, D. and R. Saluja, "Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies", RFC 3373, September 2002.
[RFC3373] Katz、D。およびR. Saluja、「中間システム（IS-IS）ポイントツーポイント隣接への3方向の握手」、RFC 3373、2002年9月。
[RFC3359] Przygienda, T., "Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System", RFC 3359, August 2002.
[RFC3359] Przygienda、T。、「中間システムから中間システムへの予約型タイプ、長さ、値（TLV）コードポイント」、RFC 3359、2002年8月。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.
[RFC5304] Li、T。およびR. Atkinson、「IS-IS暗号認証」、RFC 5304、2008年10月。
Authors' Addresses
著者のアドレス
Dave Katz Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA
Dave Katz Juniper Networks 1194 N. Mathilda Ave. Sunnyvale、CA 94089 USA
Phone: +1-408-745-2073
EMail: dkatz@juniper.net
Rajesh Saluja Tenet Technologies 30/31, 100 Feet Road, Madiwala Bangalore - 560 068 INDIA
Rajesh Saluja Tenet Technologies 30/31、100フィートロード、マディワラバンガロール-560 068インド
Phone: +91 80 552 2215
EMail: rajesh.saluja@tenetindia.com
Donald E. Eastlake 3rd Eastlake Enterprises 155 Beaver Street Milford, MA 01757 USA
ドナルドE.イーストレイク第3イーストレイクエンタープライズ155ビーバーストリートミルフォード、マサチューセッツ州01757 USA
Phone: +1-508-634-2066
EMail: d3e3e3@gmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。