[要約] RFC 6987は、OSPF Stub Router Advertisementの仕様を定義しており、スタブルーターがOSPFネットワークに参加するための手順を提供しています。このRFCの目的は、スタブルーターがOSPFネットワークに効果的に統合されることを確保することです。
Internet Engineering Task Force (IETF) A. Retana
Request for Comments: 6987 L. Nguyen
Obsoletes: 3137 Cisco Systems, Inc.
Category: Informational A. Zinin
ISSN: 2070-1721 Cinarra Systems
R. White
D. McPherson Verisign, Inc. September 2013
D.マクファーソンベリサイン社2013年9月
OSPF Stub Router Advertisement
OSPFスタブルータアドバタイズメント
Abstract
概要
This document describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise a router's unavailability to forward transit traffic or to lower the preference level for the paths through such a router.
このドキュメントでは、OSPF（Open Shortest Path First）の実装で使用される下位互換性のある手法について説明します。これにより、ルーターを使用できないことを通知して、通過トラフィックを転送したり、ルーター経由のパスの優先レベルを下げたりできます。
This document obsoletes RFC 3137.
このドキュメントはRFC 3137を廃止します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6987.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6987で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. OSPFv3-Only Solution . . . . . . . . . . . . . . . . . . 3
3. Maximum Link Metric . . . . . . . . . . . . . . . . . . . . . 4
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Appendix A. Changes from RFC 3137 . . . . . . . . . . . . . . . 6
In some situations, it may be advantageous to inform routers in a network not to use a specific router as a transit point but to still route to it. Possible situations include the following:
状況によっては、ネットワーク内のルーターに、特定のルーターを中継点として使用せず、引き続きルーターにルーティングするように通知する方が有利な場合があります。考えられる状況は次のとおりです。
o The router is in a critical condition (for example, has a very high CPU load or does not have enough memory to store all Link State Advertisements (LSAs) or build the routing table).
o ルーターがクリティカルな状態にある（たとえば、CPUの負荷が非常に高い、またはすべてのリンク状態アドバタイズ（LSA）を格納したり、ルーティングテーブルを作成するのに十分なメモリがない）
o Graceful introduction and removal of the router to/from the network.
o ネットワークへの/からのルーターの優雅な導入と削除。
o Other (administrative or traffic engineering) reasons.
o その他の（管理またはトラフィックエンジニアリング）理由。
Note that the solution introduced in this document does not remove the router from the topology view of the network (as could be done by just flushing that router's router-LSA) but discourages other routers from using it for transit routing, while still routing packets to the router's own IP addresses, i.e., the router is announced as a stub.
このドキュメントで紹介されているソリューションは、ネットワークのトポロジービューからルーターを削除するわけではありません（そのルーターのルーターLSAをフラッシュするだけで可能です）が、パケットをルーティングしながら、他のルーターが中継ルーティングにそれを使用するのを防ぎます。ルーター自身のIPアドレス、つまりルーターはスタブとしてアナウンスされます。
It must be emphasized that the solution provides real benefits in networks designed with at least some level of redundancy, so that traffic can be routed around the stub router. Otherwise, traffic destined for the networks and reachable through such a stub router may still be routed through it.
ソリューションが少なくともある程度の冗長性を備えて設計されたネットワークに真の利点を提供することを強調しなければならないので、トラフィックはスタブルーターの周りにルーティングすることができます。そうしないと、ネットワークに宛てられ、そのようなスタブルーターを介して到達可能なトラフィックは、それを介してルーティングされる可能性があります。
The solution introduced in this document solves two challenges associated with the outlined problem. In the description below, router X is the router announcing itself as a stub. The challenges are
このドキュメントで紹介するソリューションは、概説した問題に関連する2つの課題を解決します。以下の説明では、ルーターXは自身をスタブとしてアナウンスするルーターです。課題は
1) Making other routers prefer routes around router X while performing the Dijkstra calculation.
1）ダイクストラ計算を実行している間、他のルーターにルーターXの周りのルートを優先させる。
2) Allowing other routers to reach IP prefixes directly connected to router X.
2）他のルーターがルーターXに直接接続されているIPプレフィックスに到達できるようにする。
Note that it would be easy to address issue 1) alone by just flushing router X's router-LSA from the domain. However, it does not solve problem 2), since other routers will not be able to use links to router X in Dijkstra (no back link), and because router X will not have links to its neighbors.
ドメインからルーターXのルーターLSAをフラッシュするだけで、問題1）を簡単に解決できることに注意してください。ただし、他のルーターはダイクストラのルーターXへのリンクを使用できないため（バックリンクなし）、ルーターXはその近隣へのリンクを持たないため、問題2）は解決しません。
To address both problems, router X announces its router-LSA to the neighbors with the cost of all non-stub links (links of the types other than 3) being set to MaxLinkMetric (defined in Section 3).
両方の問題に対処するため、ルーターXはルーターLSAをネイバーにアナウンスし、すべての非スタブリンク（3以外のタイプのリンク）のコストをMaxLinkMetric（セクション3で定義）に設定します。
The solution above applies to both OSPFv2 [RFC2328] and OSPFv3 [RFC5340].
上記のソリューションは、OSPFv2 [RFC2328]とOSPFv3 [RFC5340]の両方に適用されます。
OSPFv3 [RFC5340] introduces additional options to provide similar control of the forwarding topology; the R-bit provides an indication of whether a router is active and should be used for transit traffic.
OSPFv3 [RFC5340]には、転送トポロジの同様の制御を提供する追加オプションが導入されています。 Rビットは、ルーターがアクティブであり、トランジットトラフィックに使用する必要があるかどうかを示します。
It is left to network operators to decide which technique to use in their network. See Section 4 for more details.
ネットワークで使用する手法を決定するのは、ネットワークオペレーターに任されています。詳細については、セクション4を参照してください。
Section 2 refers to the cost of all non-stub links as MaxLinkMetric, which is a new fixed architectural value introduced in this document.
セクション2では、すべての非スタブリンクのコストをMaxLinkMetricと呼びます。これは、このドキュメントで導入された新しい固定アーキテクチャ値です。
MaxLinkMetric The metric value indicating that a router-LSA link (see Section 2) should not be used for transit traffic. It is defined to be the 16-bit binary value of all ones: 0xffff.
MaxLinkMetricルーター-LSAリンク（セクション2を参照）を通過トラフィックに使用しないことを示すメトリック値。これは、すべて1の16ビットのバイナリ値0xffffとして定義されています。
When using MaxLinkMetric, some inconsistency may be seen if the network is constructed of routers that perform an intra-area Dijkstra calculation as specified in [RFC1247] (discarding link records in router-LSAs that have a MaxLinkMetric cost value) and routers that perform it as specified in [RFC1583] and higher (do not treat links with MaxLinkMetric cost as unreachable). Note that this inconsistency will not lead to routing loops, because if there are some alternate paths in the network, both types of routers will agree on using them rather than the path through the stub router. If the path through the stub router is the only one, the routers of the first type will not use the stub router for transit (which is the desired behavior), while the routers of the second type will still use this path.
MaxLinkMetricを使用する場合、[RFC1247]で指定されているエリア内ダイクストラ計算を実行するルーター（MaxLinkMetricコスト値を持つルーターLSAのリンクレコードを破棄する）とそれを実行するルーターでネットワークを構築すると、不整合が見られる場合があります[RFC1583]以降で指定されているとおり（MaxLinkMetricコストのリンクを到達不能として扱わないでください）。ネットワークにいくつかの代替パスがある場合、両方のタイプのルーターがスタブルーターを経由するパスではなく、それらを使用することに同意するため、この不整合がルーティングループにつながることはありません。スタブルーターを経由するパスが唯一のパスである場合、最初のタイプのルーターはトランジットにスタブルーターを使用しませんが（これは望ましい動作です）、2番目のタイプのルーターは引き続きこのパスを使用します。
On the other hand, clearing the R-bit will consistently result in the router not being used for transit.
一方、Rビットをクリアすると、ルータは常に転送に使用されなくなります。
The use of MaxLinkMetric or the R-bit in a network depends on the objectives of the operator. One of the possible considerations for selecting one or the other is in the desired behavior if the path through the stub router is the only one available. Using MaxLinkMetric allows for that path to be used while the R-bit doesn't.
ネットワークでのMaxLinkMetricまたはRビットの使用は、オペレーターの目的によって異なります。どちらか一方を選択するために考えられる考慮事項の1つは、スタブルータを経由するパスが使用可能な唯一のパスである場合の望ましい動作です。 MaxLinkMetricを使用すると、そのパスを使用できますが、Rビットは使用できません。
The technique described in this document does not introduce any new security issues into the OSPF protocol.
このドキュメントで説明されている手法では、OSPFプロトコルに新しいセキュリティ問題は導入されていません。
The authors of this document do not make any claims on the originality of the ideas described. Among other people, we would like to acknowledge Henk Smit for being part of one of the initial discussions around this topic.
このドキュメントの作成者は、説明されているアイデアの独創性についていかなる主張もしません。とりわけ、このトピックに関する最初のディスカッションの1つにHenk Smitが参加したことを認めたいと思います。
We would like to thank Shishio Tsuchiya, Gunter Van de Velde, Tomohiro Yamagata, Faraz Shamim, and Acee Lindem who provided significant input for the latest draft version of this document. Dave Cridland and Tom Yu also provided valuable comments.
このドキュメントの最新のドラフトバージョンに重要な情報を提供してくれた土屋史夫、Gunter Van de Velde、山形智宏、Faraz Shamim、Acee Lindemに感謝します。 Dave CridlandとTom Yuも貴重なコメントを提供しました。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、2008年7月。
[RFC1247] Moy, J., "OSPF Version 2", RFC 1247, July 1991.
[RFC1247] Moy、J。、「OSPFバージョン2」、RFC 1247、1991年7月。
[RFC1583] Moy, J., "OSPF Version 2", RFC 1583, March 1994.
[RFC1583] Moy、J。、「OSPFバージョン2」、RFC 1583、1994年3月。
[RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. McPherson, "OSPF Stub Router Advertisement", RFC 3137, June 2001.
[RFC3137] Retana、A.、Nguyen、L.、White、R.、Zinin、A。、およびD. McPherson、「OSPF Stub Router Advertisement」、RFC 3137、2001年6月。
This document obsoletes [RFC3137].
このドキュメントは廃止されました[RFC3137]。
In addition to editorial updates, this document defines a new architectural constant (MaxLinkMetric in Section 3) to eliminate any confusion about the interpretation of LSInfinity. It also incorporates and explains the use of the R-bit [RFC5340] as a solution to the problem addressed in the text.
編集上の更新に加えて、このドキュメントでは新しいアーキテクチャ定数（セクション3のMaxLinkMetric）を定義して、LSInfinityの解釈に関する混乱を排除しています。また、本文で扱われている問題の解決策として、Rビット[RFC5340]の使用を組み込んで説明しています。
Authors' Addresses
著者のアドレス
Alvaro Retana Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 USA
Alvaro Retana Cisco Systems、Inc. 7025 Kit Creek Rd。 Research Triangle Park、NC 27709 USA
EMail: aretana@cisco.com
Liem Nguyen Cisco Systems, Inc. 3750 Cisco Way San Jose, CA 95134 USA
Liem Nguyen Cisco Systems、Inc. 3750 Cisco Way San Jose、CA 95134 USA
EMail: lhnguyen@cisco.com
Alex Zinin Cinarra Systems Menlo Park, CA USA
Alex Zinin Cinarra Systems米国カリフォルニア州メンロパーク
EMail: alex.zinin@gmail.com
Russ White 1500 N. Greenville Avenue Suite 1100 Richardson, TX 75081 USA
Russ White 1500 N. Greenville Avenue Suite 1100 Richardson、TX 75081 USA
EMail: Russ.White@vce.com
Danny McPherson Verisign, Inc. 12061 Bluemont Way Reston, VA 20190 USA
Danny McPherson Verisign、Inc. 12061 Bluemont Way Reston、VA 20190アメリカ
EMail: dmcpherson@verisign.com