[要約] RFC 3787は、IS-ISを使用した相互運用可能なIPネットワークのための推奨事項を提供しています。このRFCの目的は、IS-ISプロトコルを使用して異なるベンダー間でのネットワークの相互運用性を向上させることです。
Network Working Group J. Parker, Ed.
Request for Comments: 3787 Axiowave Networks
Category: Informational May 2004
Recommendations for Interoperable IP Networks using Intermediate System to Intermediate System (IS-IS)
中間システムから中間システム（IS-IS）を使用した相互運用可能なIPネットワークの推奨
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
Abstract
概要
This document discusses a number of differences between the Intermediate System to Intermediate System (IS-IS) protocol used to route IP traffic as described in RFC 1195 and the protocol as it is deployed today. These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol to route IP traffic. A companion document describes the differences between the protocol described in ISO 10589 and current practice.
このドキュメントでは、RFC 1195で説明されているようにIPトラフィックをルーティングするために使用される中間システム（IS-IS）プロトコルと、今日展開されているプロトコルとの間の多くの違いについて説明します。これらの違いは、IPトラフィックをルーティングするためのIS-ISプロトコルを実装、テスト、および展開する人々へのサービスとして議論されています。コンパニオンドキュメントでは、ISO 10589で説明されているプロトコルと現在の実践の違いについて説明しています。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 2
3. Unused Features . . . . . . . . . . . . . . . . . . . . . . . 2
4. Overload Bit. . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Migration from Narrow Metrics to Wide . . . . . . . . . . . . 4
6. Intermediate System Hello (ISH) PDU . . . . . . . . . . . . . 6
7. Attached Bit. . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Default Route . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Non-homogeneous Protocol Networks . . . . . . . . . . . . . . 8
10. Adjacency Creation and IP Interface Addressing. . . . . . . . 9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 9
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References. . . . . . . . . . . . . . . . . . 10
12.2. Informative References. . . . . . . . . . . . . . . . . 10
13. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 10
14. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 11
Interior Gateway Protocols such as IS-IS are designed to provide timely information about the best routes in a routing domain. The original design of IS-IS, as described in ISO 10589 [1] has proved to be quite durable. However, a number of original design choices have been modified. This document describes some of the differences between the protocol as described in RFC 1195 [2] and the protocol that can be observed on the wire today. A companion document describes the differences between the protocol described in ISO 10589 and current practice [8].
IS-ISなどのインテリアゲートウェイプロトコルは、ルーティングドメインの最適なルートに関するタイムリーな情報を提供するように設計されています。ISO 10589 [1]に記載されているように、IS-ISの元の設計は非常に耐久性があることが証明されています。ただし、多くのオリジナルの設計の選択肢が変更されています。このドキュメントでは、RFC 1195 [2]で説明されているプロトコルと、今日のワイヤで観察できるプロトコルの違いのいくつかについて説明します。コンパニオンドキュメントでは、ISO 10589で説明されているプロトコルと現在の実践[8]に記載されているプロトコルの違いについて説明しています。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in this document are to be interpreted as described in RFC 2119 [3].
このドキュメントの「必須」、「そうでなければならない」、「そうでなければ」、「すべきではない」、「すべきではない」、「必要」は、RFC 2119 [3]に記載されているように解釈されるべきです。
This document is the work of many people, and is the distillation of over a thousand mail messages. Thanks to Vishwas Manral, who pushed to create such a document. Thanks to Danny McPherson, the original editor, for kicking things off. Thanks to Mike Shand, for his work in creating the protocol, and his uncanny ability to remember what everything is for. Thanks to Micah Bartell and Philip Christian, who showed us how to document difference without displaying discord. Thanks to Les Ginsberg, Neal Castagnoli, Jeff Learman, and Dave Katz, who spent many hours educating the editor. Thanks to Radia Perlman, who is always ready to explain anything. Thanks to Satish Dattatri, who was tenacious in seeing things written up correctly, and to Bryan Boulton for his work on the IP adjacency issue. Thanks to Russ White, whose writing improved the treatment of every topic he touched. Thanks to Shankar Vemulapalli, who read several drafts with close attention. Thanks to Don Goodspeed, for his close reading of the text. Thanks to Michael Coyle for identifying the quotation from Jan L.A. van de Snepscheut. Thanks for Alex Zinin's ministrations behind the scenes. Thanks to Tony Li and Tony Przygienda, who kept us on track as the discussions veered into the weeds. And thanks to all those who have contributed, but whose names I have carelessly left from this list.
このドキュメントは多くの人々の仕事であり、1000件以上のメールメッセージの蒸留です。そのようなドキュメントの作成を推し進めたVishwas Manralに感謝します。元の編集者であるDanny McPhersonに感謝します。マイク・シャンドのおかげで、プロトコルの作成において彼の仕事と、すべてが何のために何なのかを思い出す彼の不気味な能力です。ミカ・バルテルとフィリップ・クリスチャンに感謝します。フィリップ・クリスチャンは、不和を表示せずに違いを記録する方法を教えてくれました。Les Ginsberg、Neal Castagnoli、Jeff Learman、およびDave Katzに感謝します。常に何かを説明する準備ができているRadia Perlmanに感謝します。Satish Dattatriのおかげで、IPの隣接問題に関する彼の作業について、物事が正しく書かれているのを粘り強く、Bryan Boultonに感謝します。ラス・ホワイトのおかげで、その執筆は彼が触れたすべてのトピックの扱いを改善しました。Shankar Vemulapalliに感謝します。ShankarVemulapalliは、いくつかのドラフトを読んだことがあります。テキストをよく読んでくれたドングッドスピードに感謝します。Jan L.A. van de Snepscheutからの引用を特定してくれたMichael Coyleに感謝します。舞台裏でアレックス・ジニンのミニストレーションをありがとう。Tony LiとTony Przygiendaに感謝します。トニー・プリギエンダは、議論が雑草に向かっていたので、私たちを順調に進めています。そして、貢献したが、その名前がこのリストから不注意に残したすべての人に感謝します。
Some features defined in RFC 1195 are not in current use.
RFC 1195で定義されているいくつかの機能は、現在使用されていません。
RFC 1195 defines an Inter-Domain Routing Protocol Information TLV, with code 131, designed to convey information transparently between boundary routers. TLV 131 is not used, and MUST be ignored if received.
RFC 1195は、境界ルーター間で情報を透過的に伝えるように設計されたコード131を使用して、ドメイン間ルーティングプロトコル情報TLVを定義します。TLV 131は使用されておらず、受け取った場合は無視する必要があります。
RFC 1195 defines an authentication TLV, code 133, which contains information used to authenticate the PDU. This TLV has been replaced by TLV 10, described in "IS-IS Cryptographic Authentication" [4]. TLV 133 is not used, and MUST be ignored.
RFC 1195は、PDUの認証に使用される情報を含む認証TLV、コード133を定義します。このTLVは、「IS-IS暗号認証」に記載されているTLV 10に置き換えられています[4]。TLV 133は使用されておらず、無視する必要があります。
To deal with transient problems that prevent an IS from storing all the LSPs it receives, ISO 10589 defines an LSP Database Overload condition in section 7.3.19. When an IS is in Database Overload condition, it sets a flag called the Overload Bit in the non-pseudonode LSP number Zero that it generates. Section 7.2.8.1 of ISO 10589 instructs other systems not to use the overloaded IS as a transit router. Since the overloaded IS does not have complete information, it may not be able to compute the right routes, and routing loops could develop. However, an overloaded router may be used to reach End Systems directly attached to the router, as it may provide the only path to an End System.
ANが受信するすべてのLSPを保存するのを防ぐ一時的な問題に対処するために、ISO 10589はセクション7.3.19のLSPデータベース過負荷条件を定義します。ISがデータベースの過負荷状態にある場合、生成する非視中LSP番号ゼロにオーバーロードビットと呼ばれるフラグを設定します。ISO 10589のセクション7.2.8.1は、過負荷を使用しない他のシステムがトランジットルーターとして使用するよう指示しています。オーバーロードされたISには完全な情報がないため、適切なルートを計算できず、ルーティングループが発生する可能性があります。ただし、過負荷のルーターを使用して、エンドシステムへの唯一のパスを提供する可能性があるため、ルーターに直接接続されたエンドシステムに到達することができます。
The ability to signal reduced knowledge is so useful that the meaning of this flag has been overloaded. In a Service Provider's network, when a router running BGP and IS-IS reboots, BGP might take more time to converge than IS-IS. Thus the router may drop traffic for destinations not yet learned via BGP. It is convenient to set the Overload Bit until BGP has converged, as described in "Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance" [6].
知識を削減する能力は非常に有用であるため、このフラグの意味が過負荷になります。サービスプロバイダーのネットワークでは、ルーターがBGPとISの再起動を実行する場合、BGPはIS-ISよりも収束するのに時間がかかる場合があります。したがって、ルーターは、BGPを介してまだ学習されていない目的地のトラフィックを落とす可能性があります。「中間システム（IS-IS）一時的なブラックホール回避」に記載されているように、BGPが収束するまで過負荷ビットを設定すると便利です[6]。
An implementation SHOULD use the Overload Bit to signal that it is not ready to accept transit traffic.
実装では、過負荷ビットを使用して、輸送トラフィックを受け入れる準備ができていないことを示す必要があります。
An implementation SHOULD not set the Overload bit in PseudoNode LSPs that it generates, and Overload bits seen in PseudoNode LSPs SHOULD be ignored. This is also discussed in the companion document on ISO interoperability [8].
実装では、生成する擬似ノードLSPで過負荷ビットを設定しないでください。また、Pseudonode LSPで見られる過負荷ビットは無視する必要があります。これは、ISOの相互運用性に関するコンパニオンドキュメントでも説明されています[8]。
RFC 1195 makes clear when describing the SPF algorithm for IP routers in section C.1.4 that directly connected IP subnetworks are reachable when an IS is overloaded.
RFC 1195は、セクションC.1.4のIPルーターのSPFアルゴリズムを記述する際に、直接接続されたIPサブネットワークがASが過負荷になったときに到達可能であることを明らかにしています。
Note that the End Systems neighbors of the system P includes IP reachable address entries included in the LSPs from system P.
システムPの最終システムの近隣には、システムPのLSPに含まれるIPリーチ可能なアドレスエントリが含まれていることに注意してください。
When processing LSPs received from a router which has the Overload bit set in LSP number Zero, the receiving router SHOULD treat all IP reachability advertisements as directly connected and use them in its SPF computation.
LSP番号ゼロにオーバーロードビットが設定されているルーターから受信したLSPを処理する場合、受信ルーターはすべてのIPリーチ可能性広告を直接接続されているように扱い、SPF計算でそれらを使用する必要があります。
Since the IP prefixes that an overloaded router announces will be treated as directly attached, an overloaded router SHOULD take care in selecting which routes to advertise in the LSPs it generates.
オーバーロードされたルーターが発表するIPプレフィックスは、直接接続されていると扱われるため、オーバーロードされたルーターは、生成するLSPで広告するルートを選択することに注意する必要があります。
The IS-Neighbors TLV (TLV 2) as defined in ISO 10589 and the IP Reachability TLV (TLV 128/TLV 130) as defined in RFC 1195 provide a 6 bit metric for the default link metric to the listed neighbor. This metric has proved too limited. The Extended IS-Neighbors TLV (TLV 22) and the Extended IP Reachability TLV (TLV 135) are defined in "IS-IS extensions for Traffic Engineering" [5]. The Extended IS-Neighbors TLV (TLV 22) defines a 24 bit metric, and the Extended IP Reachability TLV (TLV 135) defines a 32 bit metric for IP Networks and Hosts.
RFC 1195で定義されているISO 10589で定義されているIS-neighbors TLV（TLV 2）およびIPリーチビリティTLV（TLV 128/TLV 130）は、デフォルトのリンクメトリックに対してリストされた隣人に6ビットメトリックを提供します。このメトリックはあまりにも制限されていることが証明されています。拡張されたis-neighbors TLV（TLV 22）と拡張されたIPリーチ可能性TLV（TLV 135）は、「トラフィックエンジニアリングのIS-IS拡張機能」で定義されています[5]。拡張されたis-neighbors TLV（TLV 22）は24ビットメトリックを定義し、拡張されたIPリーチビリティTLV（TLV 135）は、IPネットワークとホストの32ビットメトリックを定義します。
If not all devices in the IS-IS domain support wide metrics, narrow metrics MUST continue to be used. Once all devices in the network are able to support the new TLVs containing wide metrics, the network can be migrated to the new metric style, though care must be taken to avoid routing loops.
IS-ISドメインのすべてのデバイスが幅広いメトリックをサポートしている場合は、狭いメトリックを引き続き使用する必要があります。ネットワーク内のすべてのデバイスが幅広いメトリックを含む新しいTLVをサポートできるようになったら、ルーティングループを避けるために注意する必要がありますが、ネットワークを新しいメトリックスタイルに移行できます。
We make the following assumptions about the implementation:
実装について次の仮定を行います。
(1) Each system can generate and understand both narrow and wide metrics.
(1) 各システムは、狭いメトリックと幅の両方のメトリックを生成および理解できます。
(2) The implementation can run the SPF algorithm on an LSP DB with instances of both metric styles.
(2) 実装は、両方のメトリックスタイルのインスタンスを使用して、LSP DBでSPFアルゴリズムを実行できます。
(3) If there are two metric styles for a link or IP prefix, it will pick one of them as the true cost for the link.
(3) リンクまたはIPプレフィックスに2つのメトリックスタイルがある場合、リンクの真のコストとしてそれらの1つを選択します。
To compare the different variants of the narrow metric with wide metrics, we need an algorithm that translates External and Internal narrow metrics into a common integer range. Since we have different computations for the L1 and L2 routes, we only need to map metrics from a single level.
狭いメトリックのさまざまなバリアントを幅広いメトリックと比較するには、外部および内部の狭いメトリックを共通の整数範囲に変換するアルゴリズムが必要です。L1とL2のルートには異なる計算があるため、単一のレベルからメトリックをマッピングするだけが必要です。
In RFC 1195 section 3.10.2, item 2c) states that the IP prefixes located in "IP External Reachability" with internal-metric and IP prefixes located in "IP Internal Reachability" with internal-metric have the same preference. As defined in "Domain-wide Prefix Distribution with Two-Level IS-IS", the Most Significant Bit on an L1 metric tells us if the route has been leaked down, but does not change the distance. Thus we will ignore the MSBit.
RFC 1195セクション3.10.2、項目2c）では、内部計測とIPプレフィックスを備えた「IP外部リーチビリティ」にあるIPプレフィックスは、内部計量の「IP内部リーチビリティ」にあるIPプレフィックスが同じ好みを持っていると述べています。「2レベルのIS-ISを備えたドメイン全体のプレフィックス分布」で定義されているように、L1メトリックで最も重要なビットは、ルートが漏れているが距離を変えないかどうかを示します。したがって、msbitは無視します。
We interpret the default metric as an 7 bit quantity. Metrics with the external bit set are interpreted as metrics in the range [64..127]. Metrics with the external bit clear are interpreted as metrics in the range [0..63].
デフォルトメトリックを7ビット数量として解釈します。外部ビットセットを使用したメトリックは、範囲のメトリックとして解釈されます[64..127]。外部ビットクリアを使用したメトリックは、範囲のメトリックとして解釈されます[0..63]。
To facilitate a smooth transition between the use of narrow metrics exclusively to the use of wide metrics exclusively, the following steps must be taken, in the order below.
幅広いメトリックのみを使用するための狭いメトリックの使用間のスムーズな遷移を容易にするには、以下の順序で次の手順をとる必要があります。
(1) All routers advertise Narrow Metrics as defined in ISO 10589, and consider narrow metrics only in their SPF computation.
(1) すべてのルーターは、ISO 10589で定義されている狭いメトリックを宣伝し、SPF計算でのみ狭いメトリックを検討します。
(2) Each system is configured in turn to send wide metrics as well as narrow metrics. The two metrics for the same link or IP prefix SHOULD agree.
(2) 各システムは、幅広いメトリックと狭いメトリックを送信するために順番に構成されています。同じリンクまたはIPプレフィックスの2つのメトリックは同意する必要があります。
(3) When all systems are advertising wide metrics, make any changes necessary on each system to consider Wide Metrics during the SPF, and change MaxPathMetric to 0xFE000000.
(3) すべてのシステムが幅広いメトリックを宣伝している場合、各システムで必要な変更を行い、SPF中に幅広いメトリックを検討し、最大値を0xfe000000に変更します。
(4) Each system is configured in turn to stop advertising narrow metrics.
(4) 各システムは、狭いメトリックの広告を停止するように構成されています。
(5) When the network is only using wide metrics, metrics on individual links may be rescaled to take advantage of the larger metric.
(5) ネットワークが幅広いメトリックのみを使用している場合、個々のリンクのメトリックを再スケーリングして、より大きなメトリックを活用することができます。
The algorithm above assumes that the metrics are equal, and thus needs to make no assumption about which metric the SPF algorithm uses. This section describes the changes that should be made to the SPF algorithm when both Narrow and Wide metric styles should be considered. Using a common algorithm allows different implementations to compute the same distances independently, even if the wide and narrow metrics do not agree.
上記のアルゴリズムは、メトリックが等しいと想定しているため、SPFアルゴリズムが使用するメトリックについて仮定する必要はありません。このセクションでは、狭いメトリックスタイルとワイドメトリックスタイルの両方を考慮する必要がある場合に、SPFアルゴリズムに行うべき変更について説明します。一般的なアルゴリズムを使用すると、幅が広く狭いメトリックが一致しなくても、異なる実装が独立して同じ距離を計算できるようになります。
The standard SPF algorithm proceeds by comparing sums of link costs to obtain a minimal cost path. During transition, there will be more than one description of the same links. We resolve this by selecting the minimum metric for each link. This may give us a path with some links chosen due to a wide metric and some links chosen due to a narrow metric.
標準のSPFアルゴリズムは、リンクコストの合計を比較して最小限のコストパスを取得することで進行します。移行中、同じリンクの説明が複数あります。各リンクの最小メトリックを選択することにより、これを解決します。これにより、広いメトリックのために選択されたいくつかのリンクと、狭いメトリックのために選択されたいくつかのリンクを備えたパスが得られる場合があります。
The description below is more complex than the implementation needs to be: the implementation may simply select the minimal cost neighbor in TENT, discarding paths to destinations we have already reached, as described in ISO 10589.
以下の説明は、実装が必要なものよりも複雑です。実装は、ISO 10589で説明されているように、既に到達した目的地へのパスを破棄して、テントの最小コストの隣接を選択するだけです。
The variables MaxPathMetric and MaxLinkMetric SHOULD retain the values defined in Table 2 of section 8 of ISO 10589.
maxpathmetricおよびmaxlinkmetric変数は、ISO 10589のセクション8の表2に定義されている値を保持する必要があります。
In C.2.5 Step 0 of the description of the SPF algorithm, section b)
SPFアルゴリズムの説明の2.5ステップ0、セクションB）
d(N) = cost of the parent circuit of the adjacency N
d（n）=隣接する親回路のコストn
If multiple styles of metric for the link are defined, the cost will be the minimum available cost for the circuit.
リンクのメトリックの複数のスタイルが定義されている場合、コストは回路の最低利用可能なコストになります。
In C.2.5 Step 0 of the description of the SPF algorithm, section i)
SPFアルゴリズムの説明の2.5ステップ0、セクションI）
d(N) = metric of the circuit
d（n）=回路のメトリック
If multiple styles of metric for the link are defined, the cost will be the minimum available cost for the circuit.
リンクのメトリックの複数のスタイルが定義されている場合、コストは回路の最低利用可能なコストになります。
In C.2.6 Step 1 of the description of the SPF algorithm, section a)
SPFアルゴリズムの説明の2.6ステップ1、セクションa）
dist(P,N) = d(P) + metric(P,N)
If multiple styles of metric for the neighbor are defined, the cost will be the minimum available cost for the circuit.
近隣の複数のスタイルのメトリックが定義されている場合、コストは回路の最低利用可能なコストになります。
The original intent of RFC 1195 was to provide a routing protocol capable of handling both CLNS and IPv4 reachability information. To allow CLNS Endstations (ES) to know that they are attached to a router, Intermediate Systems are required to send Intermediate System Hello PDUs (ISH) for End Stations when a point-to-point circuit comes up. Furthermore, an IS is not allowed to send Intermediate System to Intermediate System Hello PDUs (IIH) before receiving an ISH from a peer. This reduces routing protocol traffic on links with a single IS.
RFC 1195の当初の意図は、CLNとIPv4の到達可能性情報の両方を処理できるルーティングプロトコルを提供することでした。CLNSエンドステーションがルーターに接続されていることを知るために、ポイントツーポイント回路が登場したときに、中間システムのhello pdus（ish）をエンドステーションに送信するために中間システムが必要です。さらに、ピアからISHを受け取る前に、ISは中間システムの中間システムを中間システムにHello PDUS（IIH）に送信することは許可されていません。これにより、単一のISを使用したリンクのルーティングプロトコルトラフィックが削減されます。
For this reason section 5.1 RFC 1195 states:
このため、セクション5.1 RFC 1195状態：
"On point-to-point links, the exchange of ISO 9542 ISHs (intermediate system Hellos) is used to initialize the link, and to allow each router to know if there is a router on the other end of the link, before IS-IS Hellos are exchanged. All routers implementing IS-IS (whether IP-only, OSI-only, or dual), if they have any interfaces on point-to-point links, must therefore be able to transmit ISO 9542 ISHs on their point-to-point links."
「ポイントツーポイントリンクでは、ISO 9542 ISHS（中間システムHELLOS）の交換を使用して、リンクを初期化し、各ルーターがリンクの反対側にルーターがあるかどうかを知ることができます。Hellosは交換されています。IS-ISを実装するすべてのルーター（IPのみ、OSI-Only、またはDual）がポイントツーポイントリンクにインターフェイスがある場合、ISO 9542 ISHSをポイントに送信できる必要があります。 - ポイントリンク。」
Section 5.1 RFC 1195 reinforces the need to comply with section 8.2.4 of ISO 10589. However, in an IP Only environment, the original need for the ISH PDU is not present.
セクション5.1 RFC 1195は、ISO 10589のセクション8.2.4に準拠する必要性を強化しています。ただし、IPのみの環境では、ISH PDUの元のニーズは存在しません。
A multi-protocol IS that supports the attachment of CLNS ESs over Point to Point circuits must act in accordance with section 8.2.2 ISO 10589 when CLNS functionality is enabled.
マルチプロトコルは、CLNS機能が有効になっている場合、Point to Point回路を超えるCLNS ESSのアタッチメントをサポートすることです。
An IP only implementation SHOULD issue an ISH PDU as described in section 8.2.3 of ISO 10589. This is to inter-operate with implementations which require an ISH to initiate the formation of an IS-IS adjacency.
IPのみの実装では、ISO 10589のセクション8.2.3で説明されているようにISH PDUを発行する必要があります。これは、IS-IS隣接能の形成を開始するためにISHが必要とする実装と相互操作することです。
An IP Only implementation may issue an IIH PDU when a point to point circuit transitions into an "Up" state to initiate the formation of an IS-IS adjacency, without sending an ISH PDU. However, this may not inter-operate with implementations which require an ISH for adjacency formation.
ISH PDUを送信せずに、ポイントツーポイント回路が「UP」状態に「UP」状態に移行して「UP」状態に移行する場合、IIH PDUを発行する場合があります。ただし、これは、隣接する形成のためにISHを必要とする実装と操作しない場合があります。
An IS may issue an IIH PDU in response to the receipt of an IIH PDU in accordance with section 8.2.5.2 ISO 10589, even though it has not received an ISH PDU.
ISH PDUを受け取っていないにもかかわらず、セクション8.2.5.2 ISO 10589に従って、IIH PDUの受領に応じてIIH PDUを発行することができます。
In section 7.2.9.2 of ISO 10589, an algorithm is described to determining when the attachedFlag should be set on an intermediate system. Some implementations also allow the attachedFlag to be set on Intermediate Systems routing IP traffic when there is a default route in the local routing table, or when some other state is reached that implies a connection to the rest of the network.
ISO 10589のセクション7.2.9.2では、接続されたフラグを中間システムでいつ設定するかを決定するアルゴリズムが説明されています。また、一部の実装により、ローカルルーティングテーブルにデフォルトのルートがある場合、またはネットワークの残りの部分への接続を暗示する他の状態に到達したときに、IPトラフィックをルーティングする中間システムに接続されたフラグを設定できます。
RFC 1195 states in section 1.3:
セクション1.3のRFC 1195状態：
Default routes are permitted only at level 2 as external routes (i.e., included in the "IP External Reachability Information" field, as explained in sections 3 and 5). Default routes are not permitted at level 1.
デフォルトルートは、レベル2で外部ルートとしてのみ許可されます（つまり、セクション3および5で説明されているように、「IP外部リーチビリティ情報」フィールドに含まれます）。デフォルトルートはレベル1では許可されていません。
Because of the utility of the default route when dealing with other routing protocols and the ability to influence the exit point from an area, an implementation MAY generate default routes in Level 1.
他のルーティングプロトコルを扱う際のデフォルトルートのユーティリティと、エリアからの出口ポイントに影響を与える機能があるため、実装はレベル1でデフォルトルートを生成する場合があります。
RFC 1195 assumes that every deployment of IS-IS routers will support a homogeneous set of protocols. It anticipates OSI only, IP only, or dual OSI and IP routers. While it allows mixed areas with, for example, both pure IP and Dual IP and OSI routers, it allows only IP traffic in such domains, and OSI traffic only when pure OSI and Dual IP and OSI routers are present. Thus it provides only lowest common denominator routing.
RFC 1195は、IS-ISルーターのすべての展開が均一なプロトコルセットをサポートすると想定しています。OSIのみ、IPのみ、またはデュアルOSIおよびIPルーターが予想されます。たとえば、純粋なIPおよびデュアルIPルーターとOSIルーターの両方を備えた混合領域を許可しますが、そのようなドメインのIPトラフィックのみを許可し、OSIトラフィックは純粋なOSIとデュアルIPおよびOSIルーターが存在する場合にのみ可能です。したがって、最も一般的な分母ルーティングのみを提供します。
RFC 1195 also requires the inclusion of the Protocol Supported TLV with code 129 in IIH and ISH PDUs and in LSP number Zero. IP capable routers MUST generate a Protocol Supported TLV, and MUST include the IP protocol as a supported protocol. A router that does not include the Protocols Supported TLV may be assumed to be a pure OSI router and can be interpreted as implicitly "advertising" support for the OSI protocol.
RFC 1195では、IIHおよびISH PDUSおよびLSP番号ゼロにコード129を備えたプロトコルサポートTLVを含める必要があります。IP有能なルーターは、サポートされているTLVを生成する必要があり、サポートされているプロトコルとしてIPプロトコルを含める必要があります。サポートされているTLVを含まないルーターは、純粋なOSIルーターであると想定され、OSIプロトコルの暗黙的に「広告」サポートと解釈できます。
The requirements of RFC 1195 are ample if networks adhere to this restriction. However, the behavior of mixed networks that do not follow these guidelines is not well defined.
ネットワークがこの制限を順守する場合、RFC 1195の要件は十分です。ただし、これらのガイドラインに従わない混合ネットワークの動作は、十分に定義されていません。
The ITU-T requires that SONET/SDH equipment running the IS-IS protocol must not form an adjacency with a neighbour unless they share at least one network layer protocol in common. Unless this feature is present in every IS in the SONET or SDH DCN network the network may not function correctly. Implementors MAY include this feature if they wish to ensure interoperability with SONET and SDH DCN networks.
ITU-Tでは、IS-ISプロトコルを実行するSONET/SDH機器が、少なくとも1つのネットワークレイヤープロトコルを共有しない限り、隣人と隣接する隣接を形成してはなりません。この機能がすべてに存在しない限り、SONETまたはSDH DCNネットワークにある場合は、ネットワークが正しく機能しない場合があります。SONETおよびSDH DCNネットワークとの相互運用性を確保したい場合、実装者はこの機能を含めることができます。
Definition of an interoperable strategy for resolving the problems that arise in non-homogeneous protocol networks remains incomplete. Members of the ITU are actively working on a proposal: see "Architecture and Specification of Data Communication Network", [7].
不均一なプロトコルネットワークで生じる問題を解決するための相互運用可能な戦略の定義は不完全なままです。ITUのメンバーは、提案に積極的に取り組んでいます。「データ通信ネットワークのアーキテクチャと仕様」、[7]を参照してください。
RFC 1195 states that adjacencies are formed without regard to IP interface addressing. However, many current implementations refuse adjacencies based on interface addresses and related issues.
RFC 1195は、IPインターフェイスアドレス指定に関係なく隣接が形成されると述べています。ただし、多くの現在の実装は、インターフェイスアドレスと関連する問題に基づいて隣接を拒否します。
In section 4.2, RFC 1195 requires routers with IP interface addresses to advertise the addresses in an IP Interface Address TLV (132) carried in IIH PDUs. Some implementations will not interoperate with a neighbor router that does not include the IP Interface Address TLV. Further, some implementations will not form an adjacency on broadcast interfaces with a peer who does not share an interface address in some common IP subnetwork.
セクション4.2では、RFC 1195では、IIH PDUで運ばれるIPインターフェイスアドレスTLV（132）でアドレスを宣伝するために、IPインターフェイスアドレスを備えたルーターが必要です。一部の実装は、IPインターフェイスアドレスTLVを含まないNeighborルーターと相互運用しません。さらに、一部の実装は、いくつかの一般的なIPサブネットワークでインターフェイスアドレスを共有していないピアとのブロードキャストインターフェイスの隣接を形成しません。
If a LAN contains a mixture of implementations, some that form adjacencies with all neighbors and some that do not, care must be taken when assigning IP addresses. If not all routers in a LAN are on the same IP subnet, it is possible that DIS election may fail, leading to the election of multiple DISs on a LAN, or no DIS at all. Even if DIS election succeeds, black holes can result because the IS-IS LAN transitivity requirements of section 6.7.3 ISO 10589 are not met.
LANに実装の混合が含まれている場合、すべての隣人との隣接を形成するものとないものは、IPアドレスを割り当てるときに注意する必要があります。LAN内のすべてのルーターが同じIPサブネット上にあるわけではない場合、DIS選挙が失敗し、LANでの複数のDissの選挙につながる可能性があります。DISの選挙が成功したとしても、IS-IS LANトランジテーションの要件がセクション6.7.3のISO 10589の適合性を満たしていないため、ブラックホールが生じる可能性があります。
Unnumbered point to point links do not have IP interface addresses, though they may have other IP addresses assigned to the routers. The IP address assigned to two routers that are neighbors on an unnumbered point to point link do not need to be related. However, some implementations will not form an adjacency on numbered point to point links if the interface addresses of each endpoint are not in the same IP subnetwork. This means that care must be taken in assigning IP interface addresses in all networks.
リンクの数のないポイントリンクには、IPインターフェイスアドレスがありませんが、ルーターに他のIPアドレスが割り当てられている場合があります。ポイントリンクからリンクの数のないポイントに隣接する2つのルーターに割り当てられたIPアドレスは、関連する必要はありません。ただし、一部の実装では、各エンドポイントのインターフェイスアドレスが同じIPサブネットワークにない場合、番号付きポイントからポイントリンクの隣接を形成しません。これは、すべてのネットワークでIPインターフェイスアドレスを割り当てることに注意する必要があることを意味します。
For an implementation to interoperate in a such mixed environment, it MUST include an IP Interface address (TLV 132) in its IIH PDUs. The network administrator should ensure that there is a common IP subnet assigned to links with numbered interfaces, and that all routers on each link have a IP Interface Addresses belonging to the assigned subnet.
このような混合環境で実装するには、IIH PDUにIPインターフェイスアドレス（TLV 132）を含める必要があります。ネットワーク管理者は、番号付きインターフェイスを持つリンクに割り当てられた共通のIPサブネットがあること、および各リンク上のすべてのルーターが割り当てられたサブネットに属するIPインターフェイスアドレスを持っていることを確認する必要があります。
The clarifications in this document do not raise any new security concerns, as there is no change in the underlying protocol described in ISO 10589 [1] and RFC 1195 [2].
このドキュメントの明確化は、ISO 10589 [1]およびRFC 1195 [2]に記載されている基礎となるプロトコルに変更がないため、新しいセキュリティの懸念を提起しません。
The document does make clear that TLV 133 has been deprecated and replaced with TLV 10.
このドキュメントは、TLV 133が非推奨され、TLV 10に置き換えられていることを明らかにしています。
[1] ISO, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)," ISO/IEC 10589:2002.
[1] ISO、「Connectionless-Mode Network Service（ISO 8473）を提供するためのプロトコルと組み合わせて使用するための情報交換プロトコルをルーティングする中間システム（ISO 8473）」、ISO/IEC 10589：2002。
[2] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, December 1990.
[2] Callon、R。、「OSIはIPおよびデュアル環境のIS-IS」、RFC 1195、1990年12月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 3567, July 2003.
[4] Li、T。およびR. Atkinson、「IS-IS暗号認証」、RFC 3567、2003年7月。
[5] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, May 2004.
[5] Smit、H。およびT. Li、「交通工学のための中間システム（IS-IS）拡張（TE）」、RFC 3784、2004年5月。
[6] McPherson, D., "Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance", RFC 3277, April 2002.
[6] McPherson、D。、「中間システムから中間システム（IS-IS）過渡的なブラックホール回避」、RFC 3277、2002年4月。
[7] ITU, "Architecture and Specification of Data Communication Network", ITU-T Recommendation G.7712/Y.1703, November 2001
[7] ITU、「データ通信ネットワークのアーキテクチャと仕様」、ITU-T推奨G.7712/Y.1703、2001年11月
[8] Parker, J., Ed., "Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS)", RFC 3719, February 2004.
[8] Parker、J.、ed。、「中間システムから中間システム（IS-IS）を使用した相互運用可能なネットワークの推奨」、RFC 3719、2004年2月。
Jeff Parker Axiowave Networks 200 Nickerson Road Marlborough, Mass 01752 USA
ジェフパーカーアシオウェイブネットワーク200ニッカーソンロードマールボロ、マサチューセッツ州01752 USA
EMail: jparker@axiowave.com
Copyright (C) The Internet Society (2004). 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.
著作権（c）The Internet Society（2004）。この文書は、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 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。