[要約] RFC 6860は、OSPFにおけるトランジット専用ネットワークの非表示化に関する要件を定義しています。その目的は、ネットワークの可視性を制御し、ネットワークのセキュリティと効率を向上させることです。
Internet Engineering Task Force (IETF) Y. Yang
Request for Comments: 6860 A. Retana
Updates: 2328, 5340 A. Roy
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 January 2013
Hiding Transit-Only Networks in OSPF
OSPFでの通過専用ネットワークの非表示
Abstract
概要
A transit-only network is defined as a network connecting routers only. In OSPF, transit-only networks are usually configured with routable IP addresses, which are advertised in Link State Advertisements (LSAs) but are not needed for data traffic. In addition, remote attacks can be launched against routers by sending packets to these transit-only networks. This document presents a mechanism to hide transit-only networks to speed up network convergence and reduce vulnerability to remote attacks.
トランジット専用ネットワークは、ルーターのみを接続するネットワークとして定義されます。 OSPFでは、通常、中継専用ネットワークはルーティング可能なIPアドレスで構成されます。これは、リンク状態アドバタイズ（LSA）でアドバタイズされますが、データトラフィックには必要ありません。さらに、これらのトランジット専用ネットワークにパケットを送信することにより、ルーターに対してリモート攻撃を仕掛けることができます。このドキュメントでは、トランジット専用ネットワークを非表示にして、ネットワークの収束を高速化し、リモート攻撃に対する脆弱性を軽減するメカニズムを紹介します。
In the context of this document, 'hiding' implies that the prefixes are not installed in the routing tables on OSPF routers. In some cases, IP addresses may still be visible when using OSPFv2.
このドキュメントのコンテキストでは、「非表示」とは、OSPFルーターのルーティングテーブルにプレフィックスがインストールされていないことを意味します。場合によっては、OSPFv2を使用しているときにIPアドレスが引き続き表示されることがあります。
This document updates RFCs 2328 and 5340.
このドキュメントは、RFC 2328および5340を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6860.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6860で入手できます。
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 ....................................................3
1.1. Requirements Notation ......................................3
2. Hiding IPv4 Transit-Only Networks in OSPFv2 .....................3
2.1. Point-to-Point Networks ....................................3
2.1.1. Advertising Point-to-Point Networks .................4
2.1.2. Hiding Point-to-Point Networks ......................4
2.2. Broadcast Networks .........................................5
2.2.1. Advertising Broadcast Networks ......................5
2.2.2. Hiding Broadcast Networks ...........................5
2.2.2.1. Sending Network-LSA ........................5
2.2.2.2. Receiving Network-LSA ......................6
2.2.2.2.1. Backward Compatibility ..........6
2.3. Non-Broadcast Networks .....................................7
2.3.1. NBMA ................................................7
2.3.2. Point-to-Multipoint .................................7
2.3.2.1. Advertising Point-to-Multipoint Networks ...7
2.3.2.2. Hiding Point-to-Multipoint Networks ........8
3. Hiding IPv6 Transit-Only Networks in OSPFv3 .....................9
3.1. Hiding AF-Enabled Transit-Only Networks in OSPFv3 ..........9
4. Operational Considerations ......................................9
4.1. Forwarding Address ........................................10
4.2. Virtual Links .............................................10
4.3. Unnumbered Interfaces .....................................10
5. Security Considerations ........................................11
6. Acknowledgments ................................................11
7. References .....................................................12
7.1. Normative References ......................................12
7.2. Informative References ....................................12
A transit-only network is defined as a network connecting routers only. In OSPF, transit-only networks are usually configured with routable IP addresses, which are advertised in LSAs but not needed for data traffic. In addition, remote attacks can be launched against routers by sending packets to these transit-only networks. This document presents a mechanism to hide transit-only networks to speed up network convergence and reduce vulnerability to remote attacks.
トランジット専用ネットワークは、ルーターのみを接続するネットワークとして定義されます。 OSPFでは、通常、トランジット専用ネットワークはルーティング可能なIPアドレスで構成され、LSAでアドバタイズされますが、データトラフィックには必要ありません。さらに、これらのトランジット専用ネットワークにパケットを送信することにより、ルーターに対してリモート攻撃を仕掛けることができます。このドキュメントでは、トランジット専用ネットワークを非表示にして、ネットワークの収束を高速化し、リモート攻撃に対する脆弱性を軽減するメカニズムを紹介します。
Hiding transit-only networks will not impact reachability to the end hosts.
トランジット専用ネットワークを非表示にしても、エンドホストへの到達可能性には影響しません。
In the context of this document, 'hiding' implies that the prefixes are not installed in the routing tables on OSPF routers. In [OSPFv2], the IPv4 interface addresses are still visible in the Router-LSA links and the network-LSA Link-State ID (LSID). In [OSPFv3], the router-LSAs and network-LSAs do not contain IPv6 addresses and are not visible.
このドキュメントのコンテキストでは、「非表示」とは、OSPFルーターのルーティングテーブルにプレフィックスがインストールされていないことを意味します。 [OSPFv2]では、IPv4インターフェースアドレスは引き続きルーターLSAリンクとネットワークLSAリンク状態ID（LSID）に表示されます。 [OSPFv3]では、ルーターLSAとネットワークLSAはIPv6アドレスを含まず、表示されません。
This document updates [OSPFv2] and [OSPFv3] by specifying a mechanism that can be used to hide transit-only networks.
このドキュメントは、[OSPFv2]および[OSPFv3]を更新して、トランジット専用ネットワークを非表示にするために使用できるメカニズムを指定します。
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 [KEYWORD].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [キーワード]で説明されているように解釈されます。
In [OSPFv2], networks are classified as point-to-point, broadcast, or non-broadcast. In the following sections, we will review how these OSPF networks are being advertised and discuss how to hide them.
[OSPFv2]では、ネットワークはポイントツーポイント、ブロードキャスト、または非ブロードキャストに分類されます。次のセクションでは、これらのOSPFネットワークがどのようにアドバタイズされているかを確認し、それらを非表示にする方法について説明します。
A point-to-point network joins a single pair of routers. Figure 1 shows a point-to-point network connecting routers RT1 and RT2.
ポイントツーポイントネットワークは、ルーターの単一ペアに参加します。図1は、ルーターRT1とRT2を接続するポイントツーポイントネットワークを示しています。
+---+.1 198.51.100.0/30 .2+---+
|RT1|---------------------------|RT2|
+---+ +---+
Figure 1. Physical Point-to-Point Network
図1.物理的なポイントツーポイントネットワーク
For each numbered point-to-point network, a router has two link descriptions in its router-LSA: one Type 1 link (point-to-point) describing the neighboring router, and one Type 3 link (stub) describing the assigned IPv4 subnet.
番号付きポイントツーポイントネットワークごとに、ルーターのルーターLSAには2つのリンク記述があります。1つはタイプ1リンク（ポイントツーポイント）で隣接ルーターを記述し、もう1つはタイプ3リンク（スタブ）で割り当てられたIPv4を記述します。サブネット。
An example of a router-LSA originated by RT1 would look like the following:
RT1から発信されたルーターLSAの例は次のようになります。
LS age = 0 ;newly (re-)originated
LS type = 1 ;router-LSA
Link State ID = 192.0.2.1 ;RT1's Router ID
Advertising Router = 192.0.2.1 ;RT1's Router ID
#links = 2
Link ID = 192.0.2.2 ;RT2's Router ID
Link Data = 198.51.100.1 ;Interface IP address
Type = 1 ;connects to RT2
Metric = 10
Link ID= 198.51.100.0 ;IP network/subnet number
Link Data = 255.255.255.252 ;Subnet's mask
Type = 3 ;Connects to stub network
Metric = 10
The Type 1 link will be used for SPF calculation, while the Type 3 link will be used to install a route to the corresponding subnet in the Routing Information Base (RIB).
タイプ1リンクはSPF計算に使用され、タイプ3リンクはルーティング情報ベース（RIB）内の対応するサブネットへのルートをインストールするために使用されます。
To hide a transit-only point-to-point network, the Type 3 link is omitted from the router-LSA.
トランジット専用のポイントツーポイントネットワークを非表示にするために、タイプ3リンクはルーターLSAから省略されています。
An example of a router-LSA originated by RT1, hiding the point-to-point network depicted in Figure 1, would look like the following:
RT1が発信したルーターLSAの例は、図1に示されているポイントツーポイントネットワークを隠し、次のようになります。
LS age = 0 ;newly (re-)originated
LS type = 1 ;router-LSA
Link State ID = 192.0.2.1 ;RT1's Router ID
Advertising Router = 192.0.2.1 ;RT1's Router ID
#links = 1
Link ID = 192.0.2.2 ;RT2's Router ID
Link Data = 198.51.100.1 ;Interface IP address
Type = 1 ;connects to RT2
Metric = 10
A broadcast network joins many (more than two) routers and supports the capability to address a single physical message to all of the attached routers. Figure 2 shows a broadcast network connecting routers RT3, RT4, and RT5.
ブロードキャストネットワークは多くの（3つ以上の）ルーターに参加し、接続されているすべてのルーターに単一の物理メッセージを送信する機能をサポートします。図2は、ルーターRT3、RT4、およびRT5を接続するブロードキャストネットワークを示しています。
+---+ +---+
|RT3| |RT4|
+---+ +---+
|.3 198.51.100.0/24 .4|
+-----------------------------+
|.5
+---+
|RT5|
+---+
Figure 2. Broadcast Network
図2.ブロードキャストネットワーク
A Designated Router (DR) describes a broadcast network in a network-LSA. Assuming that RT3 is elected as the DR in Figure 2, an example of the network-LSA originated by RT3 would look like
指定ルーター（DR）は、ネットワークLSA内のブロードキャストネットワークを表します。図2でRT3がDRとして選出されていると仮定すると、RT3から発信されたネットワークLSAの例は次のようになります。
LS age = 0 ;newly (re)originated
LS type = 2 ;network-LSA
Link State ID = 198.51.100.3 ;IP address of the DR (RT3)
Advertising Router = 192.0.2.3 ;RT3's Router ID
Network Mask = 255.255.255.0
Attached Router = 192.0.2.3 ;RT3's Router ID
Attached Router = 192.0.2.4 ;RT4's Router ID
Attached Router = 192.0.2.5 ;RT5's Router ID
OSPF obtains the IP network number from the combination of the Link State ID and the network mask. In addition, the Link State ID is also being used for the two-way connectivity check.
OSPFは、リンク状態IDとネットワークマスクの組み合わせからIPネットワーク番号を取得します。さらに、リンク状態IDは、双方向接続チェックにも使用されています。
A special subnet mask value of 255.255.255.255 MUST be used in the network-LSA to hide a transit-only broadcast network. While a broadcast network connects more than routers, using 255.255.255.255 will not hide an access broadcast network accidentally.
通過のみのブロードキャストネットワークを非表示にするには、ネットワークLSAで特別なサブネットマスク値255.255.255.255を使用する必要があります。ブロードキャストネットワークはルーター以外にも接続しますが、255.255.255.255を使用しても、アクセスブロードキャストネットワークが誤って隠されることはありません。
As there is no change of the Link State ID, the two-way connectivity check would proceed normally.
リンク状態IDの変更がないため、双方向接続チェックは正常に進行します。
An example of a network-LSA originated by RT3, hiding the broadcast network depicted in Figure 2, would look like the following:
RT2が発信し、図2に示したブロードキャストネットワークを非表示にするネットワークLSAの例は、次のようになります。
LS age = 0 ;newly (re-)originated
LS type = 2 ;network-LSA
Link State ID = 198.51.100.3 ;IP address of the DR (RT3)
Advertising Router = 192.0.2.3 ;RT3's Router ID
Network Mask = 255.255.255.255 ;special subnet mask
Attached Router = 192.0.2.3 ;RT3's Router ID
Attached Router = 192.0.2.4 ;RT4's Router ID
Attached Router = 192.0.2.5 ;RT5's Router ID
It is RECOMMENDED that all routers in an area be upgraded at the same time to process the modified network-LSA correctly and consistently.
変更されたネットワークLSAを正しく一貫して処理するために、エリア内のすべてのルーターを同時にアップグレードすることをお勧めします。
When a router receives a network-LSA, it MUST calculate the routing table normally [OSPFv2]. However, if the network mask in the network-LSA is 255.255.255.255, the router MUST NOT install the route in the RIB.
ルーターがネットワークLSAを受信すると、通常はルーティングテーブルを計算する必要があります[OSPFv2]。ただし、ネットワークLSAのネットワークマスクが255.255.255.255の場合、ルーターはRIBにルートをインストールしてはなりません（MUST NOT）。
When a router that has not yet been upgraded receives a modified network-LSA, as specified in Section 2.2.2.1, a host route to the originating DR will be installed. This is not ideal, but it is better than the current result, which exposes the whole subnet.
まだアップグレードされていないルーターが、セクション2.2.2.1で指定されている変更されたネットワークLSAを受信すると、元のDRへのホストルートがインストールされます。これは理想的ではありませんが、サブネット全体を公開する現在の結果よりも優れています。
In a partial-deployment scenario, upgraded routers and routers that have not yet been upgraded may coexist. The former do not install the host route to the DR's interface, while the latter install it. Such inconsistencies create routing black holes, which should normally be avoided. In this case, however, as packets destined for the transit-only networks are dropped somewhere in the network, the black holes actually help the DRs defend themselves from remote attacks.
部分展開シナリオでは、アップグレードされたルーターと、まだアップグレードされていないルーターが共存する場合があります。前者はDRのインターフェースにホストルートをインストールしませんが、後者はインストールします。このような不整合はルーティングブラックホールを作成しますが、通常は回避する必要があります。ただし、この場合、中継専用ネットワーク宛てのパケットはネットワークのどこかでドロップされるため、ブラックホールは実際にはDRがリモート攻撃から身を守るのに役立ちます。
In summary, the modification of the network-LSA, as specified in Section 2.2.2.1, is backward compatible with the current specification of [OSPFv2], even in a partial-deployment scenario.
要約すると、セクション2.2.2.1で指定されているネットワークLSAの変更は、部分展開シナリオであっても、[OSPFv2]の現在の仕様と下位互換性があります。
A non-broadcast network joins many (more than two) routers but does NOT support the capability to address a single physical message to all of the attached routers. As mentioned in [OSPFv2], OSPF runs in one of two modes over non-broadcast networks: Non-Broadcast Multi-Access (NBMA) or point-to-multipoint.
非ブロードキャストネットワークは多くの（3つ以上の）ルーターに参加しますが、接続されているすべてのルーターに単一の物理メッセージを送信する機能はサポートしていません。 [OSPFv2]で述べたように、OSPFは非ブロードキャストネットワーク上の2つのモードのいずれかで実行されます：非ブロードキャストマルチアクセス（NBMA）またはポイントツーマルチポイント。
In NBMA mode, OSPF emulates operation over a broadcast network: a Designated Router is elected for the NBMA network, and the Designated Router originates an LSA for the network.
NBMAモードでは、OSPFはブロードキャストネットワーク上で動作をエミュレートします。指定ルーターがNBMAネットワーク用に選択され、指定ルーターがネットワークのLSAを発信します。
To hide an NBMA transit-only network, OSPF adopts the same modification as that used over the broadcast transit-only network (see Section 2.2.2).
NBMAトランジット専用ネットワークを非表示にするために、OSPFは、ブロードキャストトランジット専用ネットワークで使用されるものと同じ変更を採用します（セクション2.2.2を参照）。
In point-to-multipoint mode, OSPF treats the non-broadcast network as a collection of point-to-point links.
ポイントツーマルチポイントモードでは、OSPFは非ブロードキャストネットワークをポイントツーポイントリンクの集まりとして扱います。
Figure 3 shows a non-broadcast network connecting routers RT6, RT7, RT8, and RT9. In this network, all routers can communicate directly, except for routers RT7 and RT8.
図3は、ルーターRT6、RT7、RT8、およびRT9を接続する非ブロードキャストネットワークを示しています。このネットワークでは、ルーターRT7とRT8を除いて、すべてのルーターが直接通信できます。
+---+ +---+
|RT6| |RT7|
+---+ +---+
|.6 198.51.100.0/24 .7|
+----------------------------+
|.8 .9|
+---+ +---+
|RT8| |RT9|
+---+ +---+
Figure 3. Non-Broadcast Network
図3.非ブロードキャストネットワーク
For a point-to-multipoint network, a router has multiple link descriptions in its router-LSA, one Type 1 link (point-to-point) for EACH directly communicable router, and one Type 3 link (stub) advertising its interface IPv4 address with a subnet mask of 255.255.255.255.
ポイントツーマルチポイントネットワークの場合、ルーターのルーターLSAには複数のリンク記述があり、直接通信可能なEACHルーターごとに1つのタイプ1リンク（ポイントツーポイント）があり、インターフェースIPv4をアドバタイズする1つのタイプ3リンク（スタブ）があります。サブネットマスクが255.255.255.255のアドレス。
An example of a router-LSA originated by RT7 would look like the following:
RT7から発信されたルーターLSAの例は次のようになります。
LS age = 0 ;newly (re-)originated
LS type = 1 ;router-LSA
Link State ID = 192.0.2.7 ;RT7's Router ID
Advertising Router = 192.0.2.7 ;RT7's Router ID
#links = 3
Link ID = 192.0.2.6 ;RT6's Router ID
Link Data = 198.51.100.7 ;Interface IP address
Type = 1 ;connects to RT6
Metric = 10
Link ID = 192.0.2.9 ;RT9's Router ID
Link Data = 198.51.100.7 ;Interface IP address
Type = 1 ;connects to RT9
Metric = 10
Link ID= 198.51.100.7 ;Interface IP address
Link Data = 255.255.255.255 ;Subnet's mask
Type = 3 ;Connects to stub network
Metric = 0
To hide a transit-only point-to-multipoint network, the Type 3 link is omitted from the router-LSA.
トランジット専用のポイントツーマルチポイントネットワークを非表示にするために、タイプ3リンクはルーターLSAから省略されています。
An example of a router-LSA originated by RT7, hiding the point-to-point network depicted in Figure 3, would look like the following:
RT3が発信し、図3に示したポイントツーポイントネットワークを非表示にしたルーターLSAの例は、次のようになります。
LS age = 0 ;newly (re-)originated
LS type = 1 ;router-LSA
Link State ID = 192.0.2.7 ;RT7's Router ID
Advertising Router = 192.0.2.7 ;RT7's Router ID
#links = 2
Link ID = 192.0.2.6 ;RT6's Router ID
Link Data = 198.51.100.7 ;Interface IP address
Type = 1 ;connects to RT6
Metric = 10
Link ID = 192.0.2.9 ;RT9's Router ID
Link Data = 198.51.100.7 ;Interface IP address
Type = 1 ;connects to RT9
Metric = 10
In [OSPFv3], addressing semantics have been removed from the OSPF protocol packets and the main LSA types, leaving a network-protocol-independent core.
[OSPFv3]では、OSPFプロトコルパケットと主要なLSAタイプからアドレッシングセマンティクスが削除され、ネットワークプロトコルに依存しないコアが残っています。
More specifically, router-LSAs and network-LSAs no longer contain network addresses but simply express topology information. Instead, two new LSA types, link-LSA and intra-area-prefix-LSA, have been introduced. A link-LSA associates a list of IPv6 addresses to a link and has local-link flooding scope, and an intra-area-prefix-LSA either associates a list of IPv6 addresses with a router by referencing a router-LSA or associates a list of IPv6 addresses with a broadcast/NBMA network by referencing a network-LSA. In the latter case, the prefixes in the link-LSAs from adjacent neighbors are copied into the intra-area-prefix-LSA by the Designated Router.
より具体的には、ルーターLSAとネットワークLSAにはネットワークアドレスが含まれなくなり、単にトポロジ情報が表現されます。代わりに、2つの新しいLSAタイプ、link-LSAとintra-area-prefix-LSAが導入されました。リンクLSAはIPv6アドレスのリストをリンクに関連付け、ローカルリンクフラッディングスコープを持ちます。また、intra-area-prefix-LSAは、ルーターLSAを参照してIPv6アドレスのリストをルーターに関連付けるか、リストを関連付けます。ネットワークLSAを参照することによるブロードキャスト/ NBMAネットワークでのIPv6アドレスの使用。後者の場合、隣接ネイバーからのリンクLSAのプレフィックスは、代表ルータによってintra-area-prefix-LSAにコピーされます。
To hide a transit-only network in [OSPFv3], the IPv6 address prefixes are omitted from the router-LSA. Consequently, when a Designated Router builds an intra-area-prefix-LSA referencing a network-LSA, these IPv6 address prefixes will be omitted.
[OSPFv3]でトランジット専用ネットワークを非表示にするために、ルーターLSAからIPv6アドレスプレフィックスが省略されています。したがって、指定ルーターがネットワークLSAを参照するエリア内プレフィックスLSAを構築する場合、これらのIPv6アドレスプレフィックスは省略されます。
In addition, when a router builds an intra-area-prefix-LSA that is referencing a router-LSA, the associated IPv6 address prefixes from the transit-only network MUST also be omitted from the intra-area-prefix-LSA.
さらに、ルーターがルーターLSAを参照するintra-area-prefix-LSAを構築する場合、通過専用ネットワークからの関連するIPv6アドレスプレフィックスもintra-area-prefix-LSAから省略しなければなりません（MUST）。
[OSPF-AF] supports multiple Address Families (AFs) by mapping each AF to a separate Instance ID and OSPFv3 instance.
[OSPF-AF]は、各AFを個別のインスタンスIDおよびOSPFv3インスタンスにマッピングすることにより、複数のアドレスファミリ（AF）をサポートします。
In the meantime, each prefix advertised in OSPFv3 has a prefix length field [OSPFv3], which facilitates advertising prefixes of different lengths in different AFs. The existing LSAs defined in [OSPFv3] are used for prefix advertising, and there is no need to define new LSAs.
その間、OSPFv3でアドバタイズされる各プレフィックスには、プレフィックス長フィールド[OSPFv3]があり、異なるAFで異なる長さのプレフィックスのアドバタイズを容易にします。 [OSPFv3]で定義されている既存のLSAはプレフィックスアドバタイズに使用され、新しいLSAを定義する必要はありません。
In other words, as link-LSAs and intra-area-prefix-LSAs are still being used, the same mechanism explained in Section 3 can be used to hide those AF-enabled transit-only networks as well.
つまり、リンクLSAとイントラエリアプレフィックスLSAが引き続き使用されているため、セクション3で説明した同じメカニズムを使用して、AF対応の通過専用ネットワークを非表示にすることもできます。
By eliminating the ability to reach transit-only networks, the ability to manage these interfaces may be reduced. In order not to reduce the functionality and capability of the overall network, it is recommended that extensions such as [UNNUMBERED] also be implemented.
トランジット専用ネットワークに到達する機能を排除することにより、これらのインターフェースを管理する機能が低下する可能性があります。ネットワーク全体の機能と能力を低下させないために、[UNNUMBERED]などの拡張機能も実装することをお勧めします。
Note that the extension defined in [UNNUMBERED] may provide the user with the IP address of an interface. If that address was hidden, as specified in this document, then even though the address is assigned to the interface, it will not be reachable.
[UNNUMBERED]で定義された拡張子は、ユーザーにインターフェースのIPアドレスを提供する場合があることに注意してください。このドキュメントで指定されているように、そのアドレスが非表示になっている場合、アドレスがインターフェイスに割り当てられていても、到達できません。
A non-zero forwarding address can be advertised in AS-external-LSAs and Not-So-Stubby Area LSAs (NSSA-LSAs) [NSSA] to achieve optimal routing to Autonomous System (AS) external routes. The matching routing table entry for the forwarding address must exist to facilitate the SPF calculation.
AS-external-LSAおよびNot-So-Stubby Area LSA（NSSA-LSA）[NSSA]でゼロ以外の転送アドレスをアドバタイズして、自律システム（AS）外部ルートへの最適なルーティングを実現できます。 SPF計算を容易にするために、転送アドレスに一致するルーティングテーブルエントリが存在する必要があります。
In other words, when prefix-hiding is configured on the next-hop interface, the next-hop address MUST NOT be advertised as a forwarding address.
言い換えると、プレフィックス隠蔽がネクストホップインターフェイスで設定されている場合、ネクストホップアドレスは転送アドレスとしてアドバタイズされてはなりません。
Consequently, sub-optimal routing to these AS external routes may exist when prefix-hiding is configured.
その結果、これらのAS外部ルートへの準最適なルーティングは、プレフィックス非表示が設定されている場合に存在する可能性があります。
Virtual links are used to connect physically separate components of the backbone. The virtual link's viability is determined by the existence of an intra-area path between two endpoints. The matching routing table entries of the endpoints must exist to ensure the virtual link's operation.
仮想リンクは、バックボーンの物理的に分離されたコンポーネントを接続するために使用されます。仮想リンクの実行可能性は、2つのエンドポイント間のエリア内パスの存在によって決まります。仮想リンクの動作を保証するには、エンドポイントの一致するルーティングテーブルエントリが存在する必要があります。
In other words, if prefix-hiding is configured on an interface, the virtual link endpoint MUST NOT use that interface's IP address as the virtual interface's IP address.
つまり、プレフィックス非表示がインターフェイスで構成されている場合、仮想リンクエンドポイントは、そのインターフェイスのIPアドレスを仮想インターフェイスのIPアドレスとして使用してはなりません（MUST NOT）。
Note that no host route is generated for, and no IP packets can be addressed to, interfaces to unnumbered point-to-point networks [OSPFv2]. In other words, these addresses are already hidden.
アンナンバードポイントツーポイントネットワークへのインターフェイス[OSPFv2]のホストルートは生成されず、IPパケットの宛先も指定できないことに注意してください。つまり、これらのアドレスはすでに非表示になっています。
However, for manageability purposes, it may be common practice to manually include the numbered interface (for example, a loopback interface to which the unnumbered interface points) in routing updates. If needed, the numbered interface's address can be hidden by using the mechanisms described in this document or by simply not advertising it.
ただし、管理を容易にするために、ルーティング更新に番号付きインターフェイス（たとえば、番号なしインターフェイスが指すループバックインターフェイス）を手動で含めることは一般的な方法です。必要に応じて、このドキュメントで説明されているメカニズムを使用するか、単にアドバタイズしないことで、番号付きインターフェイスのアドレスを非表示にすることができます。
Before deciding to hide (or suppress the advertisement of) a numbered interface, it is very important to consider other uses that interface may have. Examples of common uses may include virtual link endpoint, inter-domain routing peering point, etc. In other words, it may not be possible to hide the address associated to an unnumbered interface due to other applications in the network.
番号付きインターフェイスを非表示にする（またはその通知を抑制する）ことを決定する前に、インターフェイスが持つ可能性のある他の用途を検討することが非常に重要です。一般的な使用例には、仮想リンクエンドポイント、ドメイン間ルーティングピアリングポイントなどがあります。つまり、ネットワーク内の他のアプリケーションが原因で、番号付けされていないインターフェイスに関連付けられたアドレスを非表示にできない場合があります。
One motivation for this document is to reduce vulnerability to remote attacks by hiding transit-only networks. The result should then be that fewer OSPF core networks will be exposed.
このドキュメントの1つの動機は、トランジット専用ネットワークを非表示にすることにより、リモート攻撃に対する脆弱性を減らすことです。その結果、公開されるOSPFコアネットワークが少なくなります。
The mechanisms described above result in reachability information from transit-only networks not being installed in the routers' forwarding tables. The effect is that even if the address of a transit-only network is known, the forwarding information is not present in the routers to reach the destination. Also, in some cases, the address information is completely omitted from the LSA.
上記のメカニズムにより、中継専用ネットワークからの到達可能性情報がルーターの転送テーブルにインストールされなくなります。その結果、トランジット専用ネットワークのアドレスがわかっていても、宛先に到達するための転送情報がルーターに存在しません。また、アドレス情報がLSAから完全に省略される場合もあります。
Some information in the LSA (such as the OSPF Router ID) cannot be omitted. Even though the Router ID may be taken from an IPv4 address on the router, the configuration can be easily changed. Note again that having an address doesn't guarantee reachability if the information is hidden from the forwarding tables.
LSAの一部の情報（OSPFルーターIDなど）は省略できません。ルーターIDはルーターのIPv4アドレスから取得される場合がありますが、構成は簡単に変更できます。情報が転送テーブルから隠されている場合、アドレスがあることは到達可能性を保証しないことに再度注意してください。
While the steps described in this document are meant to be applied only to transit-only networks, they could be used to hide other networks as well. It is expected that the same care that users put into the configuration of other routing protocol parameters is used in the configuration of this extension.
このドキュメントで説明されている手順は、通過のみのネットワークにのみ適用されることを意図していますが、他のネットワークを非表示にするためにも使用できます。この拡張機能の構成では、ユーザーが他のルーティングプロトコルパラメータの構成と同じ注意を払うことが期待されます。
The idea of using a special subnet mask to hide broadcast networks in OSPF was originally introduced in the US patent "Apparatus and method to hide transit only multi-access networks in OSPF" (patent number: 7,929,524), by Yi Yang, Alvaro Retana, James Ng, Abhay Roy, Alfred Lindem, Sina Mirtorabi, Timothy Gage, and Khalid Raza.
特別なサブネットマスクを使用してOSPFでブロードキャストネットワークを非表示にするアイデアは、Yi Yang、Alvaro Retanaによる米国特許「OSPFでトランジット専用マルチアクセスネットワークを非表示にする装置および方法」（特許番号：7,929,524）で最初に導入されました。 James Ng、Abhay Roy、Alfred Lindem、Sina Mirtorabi、Timothy Gage、Khalid Raza。
The authors would like to thank Acee Lindem, Shraddha Hegde, Rajesh Shetty, Marek Karasek, Michael Barnes, Paul Wells, Adrian Farrel, and Stephen Farrell for their feedback on the document.
この文書に関するフィードバックを提供してくれたAcee Lindem、Shraddha Hegde、Rajesh Shetty、Marek Karasek、Michael Barnes、Paul Wells、Adrian Farrel、Stephen Farrellに感謝します。
[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, January 2003.
[NSSA]マーフィー、P。、「OSPF Not-So-Stubby Area（NSSA）オプション」、RFC 3101、2003年1月。
[OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPFv2] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[OSPFv3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[OSPFv3] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、2008年7月。
[OSPF-AF] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, April 2010.
[OSPF-AF] Lindem、A.、Ed。、Mirtorabi、S.、Roy、A.、Barnes、M。、およびR. Aggarwal、「Support of Address Families in OSPFv3」、RFC 5838、2010年4月。
[UNNUMBERED] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen, N., and JR. Rivers, "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, April 2010.
[番号なし] Atlas、A.、Ed。、Bonica、R.、Ed。、Pignataro、C.、Ed。、Shen、N.、JR。 Rivers、「Interface and Next-Hop IdentificationのためのICMPの拡張」、RFC 5837、2010年4月。
Authors' Addresses
著者のアドレス
Yi Yang Cisco Systems, Inc. 7025 Kit Creek Road RTP, NC 27709 USA
Yi Yang Cisco Systems、Inc. 7025 Kit Creek Road RTP、NC 27709 USA
EMail: yiya@cisco.com
Alvaro Retana Cisco Systems, Inc. 7025 Kit Creek Road RTP, NC 27709 USA
Alvaro Retana Cisco Systems、Inc. 7025 Kit Creek Road RTP、NC 27709 USA
EMail: aretana@cisco.com
Abhay Roy Cisco Systems, Inc. 225 West Tasman Drive San Jose, CA 95134 USA
Abhay Roy Cisco Systems、Inc.225 West Tasman Drive San Jose、CA 95134 USA
EMail: akr@cisco.com