[要約] RFC 6992は、IPv4-Embedded IPv6パケットのルーティングに関するガイドラインです。このRFCの目的は、IPv6ネットワークでIPv4トラフィックを効果的にルーティングする方法を提供することです。
Internet Engineering Task Force (IETF) D. Cheng
Request for Comments: 6992 Huawei Technologies
Category: Informational M. Boucadair
ISSN: 2070-1721 France Telecom
A. Retana
Cisco Systems
July 2013
Routing for IPv4-Embedded IPv6 Packets
IPv4組み込みIPv6パケットのルーティング
Abstract
概要
This document describes a routing scenario where IPv4 packets are transported over an IPv6 network, based on the methods described in RFCs 6145 and 6052, along with a separate OSPFv3 routing table for IPv4-embedded IPv6 routes in the IPv6 network.
このドキュメントでは、RFC 6145および6052で説明されている方法に基づいて、IPv4パケットがIPv6ネットワークを介して転送されるルーティングシナリオと、IPv6ネットワーク内のIPv4組み込みIPv6ルート用の別のOSPFv3ルーティングテーブルについて説明します。
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/rfc6992.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6992で入手できます。
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
1.1. The Scenario ...............................................3
1.2. Routing Solution per RFC 5565 ..............................4
1.3. An Alternative Routing Solution with OSPFv3 ................4
1.4. OSPFv3 Routing with a Specific Topology ....................6
2. Requirements Language ...........................................7
3. Provisioning ....................................................7
3.1. Deciding on the IPv4-Embedded IPv6 Topology ................7
3.2. Maintaining a Dedicated IPv4-Embedded IPv6 Routing Table ...7
4. Translation of IP Packets .......................................8
4.1. Address Translation ........................................8
5. Advertising IPv4-Embedded IPv6 Routes ...........................9
5.1. Advertising IPv4-Embedded IPv6 Routes through an
IPv6 Transit Network .......................................9
5.1.1. Routing Metrics .....................................9
5.1.2. Forwarding Address .................................10
5.2. Advertising IPv4 Addresses into Client Networks ...........10
6. Aggregation on IPv4 Addresses and Prefixes .....................10
7. Forwarding .....................................................10
8. Backdoor Connections ...........................................11
9. Prevention of Loops ............................................11
10. MTU Issues ....................................................11
11. Security Considerations .......................................12
12. Operational Considerations ....................................13
13. Acknowledgements ..............................................14
14. References ....................................................14
14.1. Normative References .....................................14
14.2. Informative References ...................................14
This document describes a routing scenario where IPv4 packets are transported over an IPv6 network, based on [RFC6145] and [RFC6052], along with a separate OSPFv3 routing table for IPv4-embedded IPv6 routes in the IPv6 network. This document does not introduce any new IPv6 transition mechanism.
このドキュメントでは、[RFC6145]と[RFC6052]に基づいて、IPv4パケットがIPv6ネットワークを介して転送されるルーティングシナリオと、IPv6ネットワーク内のIPv4組み込みIPv6ルートの個別のOSPFv3ルーティングテーブルについて説明します。このドキュメントでは、新しいIPv6移行メカニズムを紹介していません。
In this document, the following terminology is used:
このドキュメントでは、次の用語が使用されています。
o An IPv4-embedded IPv6 address denotes an IPv6 address that contains an embedded 32-bit IPv4 address constructed according to the rules defined in [RFC6052].
o IPv4埋め込みIPv6アドレスは、[RFC6052]で定義された規則に従って構築された埋め込み32ビットIPv4アドレスを含むIPv6アドレスを示します。
o IPv4-embedded IPv6 packets are packets of which destination addresses are IPv4-embedded IPv6 addresses.
o IPv4埋め込みIPv6パケットは、宛先アドレスがIPv4埋め込みIPv6アドレスであるパケットです。
o AFBR (Address Family Border Router) [RFC5565] refers to an edge router that supports both IPv4 and IPv6 address families, but the backbone network it connects to only supports either the IPv4 or IPv6 address family.
o AFBR（アドレスファミリーボーダールーター）[RFC5565]は、IPv4とIPv6の両方のアドレスファミリーをサポートするエッジルーターを指しますが、接続するバックボーンネットワークはIPv4またはIPv6アドレスファミリーのいずれかのみをサポートします。
o AFXLBR (Address Family Translation Border Router) is defined in this document. It refers to a border router that supports both IPv4 and IPv6 address families located on the boundary of an IPv4- only network and an IPv6-only network and that is capable of performing IP header translation between IPv4 and IPv6 [RFC6145].
o AFXLBR（Address Family Translation Border Router）は、このドキュメントで定義されています。 IPv4のみのネットワークとIPv6のみのネットワークの境界にあるIPv4とIPv6の両方のアドレスファミリをサポートし、IPv4とIPv6の間のIPヘッダー変換を実行できる境界ルーターを指します[RFC6145]。
Due to exhaustion of public IPv4 addresses, there has been a continuing effort within the IETF to investigate and specify IPv6 transitional techniques. In the course of the transition, it is certain that networks based on IPv4 and IPv6 technologies, respectively, will coexist at least for some time. One such scenario is the interconnection of IPv4-only and IPv6-only networks, and in particular, when an IPv6-only network serves as an interconnection between several segregated IPv4-only networks. In this scenario, IPv4 packets are transported over the IPv6 network between IPv4 networks. In order to forward an IPv4 packet from a source IPv4 network to the destination IPv4 network, IPv4 reachability information must be exchanged between the IPv4 networks via some mechanism.
パブリックIPv4アドレスが枯渇したため、IETF内ではIPv6移行技術を調査および指定するための継続的な取り組みが行われてきました。移行の過程で、IPv4テクノロジーとIPv6テクノロジーに基づくネットワークがそれぞれ少なくともしばらくは共存することは確かです。そのようなシナリオの1つは、IPv4のみのネットワークとIPv6のみのネットワークの相互接続です。特に、IPv6のみのネットワークが、分離された複数のIPv4のみのネットワーク間の相互接続として機能する場合です。このシナリオでは、IPv4パケットはIPv4ネットワーク間のIPv6ネットワークを介して転送されます。ソースIPv4ネットワークから宛先IPv4ネットワークにIPv4パケットを転送するには、何らかのメカニズムを介してIPv4ネットワーク間でIPv4到達可能性情報を交換する必要があります。
In general, running an IPv6-only network would reduce operational expenditures and optimize operations as compared to an IPv4-IPv6 dual-stack environment. Some proposed solutions allow the delivery of IPv4 services over an IPv6-only network. This document specifies an engineering technique that separates the routing table dedicated to IPv4-embedded IPv6 destinations from the routing table used for native IPv6 destinations.
一般に、IPv6のみのネットワークを実行すると、IPv4とIPv6のデュアルスタック環境と比較して、運用コストが削減され、運用が最適化されます。いくつかの提案されたソリューションでは、IPv6のみのネットワークを介してIPv4サービスを提供できます。このドキュメントでは、IPv4埋め込みIPv6宛先専用のルーティングテーブルを、ネイティブIPv6宛先に使用されるルーティングテーブルから分離するエンジニアリング手法を指定します。
OSPFv3 is designed to support multiple instances. Maintaining a separate routing table for IPv4-embedded IPv6 routes would simplify implementation, troubleshooting, and operation; it would also prevent overload of the native IPv6 routing table. A separate routing table can be generated from a separate routing instance.
OSPFv3は、複数のインスタンスをサポートするように設計されています。 IPv4組み込みIPv6ルートの個別のルーティングテーブルを維持すると、実装、トラブルシューティング、および操作が簡素化されます。また、ネイティブIPv6ルーティングテーブルの過負荷を防ぎます。別のルーティングテーブルは、別のルーティングインスタンスから生成できます。
The aforementioned scenario is described in [RFC5565], i.e., the IPv4-over-IPv6 scenario, where the network core is IPv6-only and the interconnected IPv4 networks are called IPv4 client networks. The P Routers (Provider Routers) in the core only support IPv6, but the AFBRs support IPv4 on interfaces facing IPv4 client networks and IPv6 on interfaces facing the core. The routing solution defined in [RFC5565] for this scenario is to run IBGP among AFBRs to exchange IPv4 routing information in the core, and the IPv4 packets are forwarded from one IPv4 client network to the other through a softwire using tunneling technology, such as MPLS, LSP, GRE, L2TPv3, etc.
前述のシナリオは[RFC5565]で説明されています。つまり、ネットワークコアがIPv6のみであり、相互接続されたIPv4ネットワークはIPv4クライアントネットワークと呼ばれるIPv4-over-IPv6シナリオです。コアのPルーター（プロバイダールーター）はIPv6のみをサポートしますが、AFBRはIPv4クライアントネットワークに面するインターフェイスでIPv4をサポートし、コアに面するインターフェイスでIPv6をサポートします。このシナリオの[RFC5565]で定義されているルーティングソリューションは、AFBR間でIBGPを実行してコアのIPv4ルーティング情報を交換し、IPv4パケットは、MPLSなどのトンネリングテクノロジーを使用して、ソフトワイヤを介して1つのIPv4クライアントネットワークから他のネットワークに転送されます。 、LSP、GRE、L2TPv3など
In this document, we propose an alternative routing solution for the scenario described in Section 1.1 where several segregated IPv4 networks, called IPv4 client networks, are interconnected by an IPv6 network. The IPv6 network and the interconnected IPv4 networks may or may not belong to the same Autonomous System (AS). We refer to the border node on the boundary of an IPv4 client network and the IPv6 network as an Address Family Translation Border Router (AFXLBR), which supports both the IPv4 and IPv6 address families and is capable of translating an IPv4 packet to an IPv6 packet, and vice versa, according to [RFC6145]. The described scenario is illustrated in Figure 1.
このドキュメントでは、IPv4クライアントネットワークと呼ばれるいくつかの分離されたIPv4ネットワークがIPv6ネットワークによって相互接続されているセクション1.1で説明されているシナリオの代替ルーティングソリューションを提案します。 IPv6ネットワークと相互接続されたIPv4ネットワークは、同じ自律システム（AS）に属している場合と属していない場合があります。 IPv4クライアントネットワークとIPv6ネットワークの境界にある境界ノードをアドレスファミリ変換ボーダールーター（AFXLBR）と呼びます。これは、IPv4とIPv6の両方のアドレスファミリをサポートし、IPv4パケットをIPv6パケットに変換できます。 [RFC6145]によると、その逆も同様です。説明したシナリオを図1に示します。
+--------+ +--------+
| IPv4 | | IPv4 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| AFXLBR | | AFXLBR |
+--| IPv4/6 |---| IPv4/6 |--+
| +--------+ +--------+ |
+--------+ | | +--------+
| IPv6 | | | | IPv6 |
| Client |----| |----| Client |
| Network| | IPv6 | | Network|
+--------+ | only | +--------+
| |
| +--------+ +--------+ |
+--| AFXLBR |---| AFXLBR |--+
| IPv4/6 | | IPv4/6 |
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| IPv4 | | IPv4 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
Figure 1: Segregated IPv4 Networks Interconnected by an IPv6 Network
図1：IPv6ネットワークによって相互接続された分離されたIPv4ネットワーク
Since the scenario occurs most commonly within an organization, an IPv6 prefix can be locally allocated and used by AFXLBRs to construct IPv4-embedded IPv6 addresses [RFC6052]. The embedded IPv4 address or prefix belongs to an IPv4 client network that is connected to the AFXLBR. An AFXLBR injects IPv4-embedded IPv6 addresses and prefixes into the IPv6 network using OSPFv3, and it also installs IPv4-embedded IPv6 routes advertised by other AFXLBRs.
シナリオは組織内で最も一般的に発生するため、IPv6プレフィックスをローカルに割り当て、AFXLBRで使用してIPv4埋め込みIPv6アドレスを構築できます[RFC6052]。埋め込まれたIPv4アドレスまたはプレフィックスは、AFXLBRに接続されているIPv4クライアントネットワークに属しています。 AFXLBRは、OSPFv3を使用してIPv4埋め込みIPv6アドレスとプレフィックスをIPv6ネットワークに挿入し、他のAFXLBRによってアドバタイズされたIPv4埋め込みIPv6ルートもインストールします。
When an AFXLBR receives an IPv4 packet from a locally connected IPv4 client network destined to a remote IPv4 client network, it translates the IPv4 header to the relevant IPv6 header [RFC6145], and in that process, the source and destination IPv4 addresses are translated into IPv4-embedded IPv6 addresses, respectively [RFC6052]. The resulting IPv6 packet is then forwarded to the AFXLBR that connects to the destination IPv4 client network. The remote AFXLBR derives the IPv4 source and destination addresses from the IPv4- embedded IPv6 addresses, respectively [RFC6052], and translates the header of the received IPv6 packet to the relevant IPv4 header [RFC6145]. The resulting IPv4 packet is then forwarded according to the IPv4 routing table maintained on the AFXLBR.
AFXLBRは、ローカルに接続されたIPv4クライアントネットワークからリモートIPv4クライアントネットワーク宛てのIPv4パケットを受信すると、IPv4ヘッダーを関連するIPv6ヘッダー[RFC6145]に変換し、そのプロセスで、送信元と宛先のIPv4アドレスが次のように変換されます。 IPv4埋め込みIPv6アドレス、それぞれ[RFC6052]。結果のIPv6パケットは、宛先IPv4クライアントネットワークに接続するAFXLBRに転送されます。リモートAFXLBRは、IPv4埋め込みIPv6アドレス[RFC6052]からそれぞれIPv4送信元アドレスと宛先アドレスを取得し、受信したIPv6パケットのヘッダーを関連するIPv4ヘッダー[RFC6145]に変換します。結果のIPv4パケットは、AFXLBRで維持されているIPv4ルーティングテーブルに従って転送されます。
There are use cases where the proposed routing solution is useful. One case is that some border nodes do not participate in IBGP for the exchange of routes, or IBGP is not used at all. Another case is when tunnels are not deployed in the IPv6 network, or native IPv6 forwarding is preferred. Note that with this routing solution, the IPv4 and IPv6 header translation performed in both directions by the AFXLBR is stateless.
提案されたルーティングソリューションが役立つユースケースがあります。 1つのケースは、一部の境界ノードがルートの交換のためにIBGPに参加していないか、IBGPがまったく使用されていないことです。別のケースは、トンネルがIPv6ネットワークに展開されていない場合、またはネイティブIPv6転送が優先される場合です。このルーティングソリューションでは、AFXLBRによって両方向で実行されるIPv4およびIPv6ヘッダー変換はステートレスであることに注意してください。
In general, IPv4-embedded IPv6 packets can be forwarded just like native IPv6 packets with OSPFv3 running in the IPv6 network. However, this would require that IPv4-embedded IPv6 routes be flooded throughout the entire IPv6 network and stored on every router. This is not desirable from a scaling perspective. Moreover, since all IPv6 routes are stored in the same routing table, it would be inconvenient to manage the resource required for routing and forwarding based on traffic category, if so desired.
一般に、IPv4埋め込みIPv6パケットは、IPv6ネットワークでOSPFv3が実行されているネイティブIPv6パケットと同じように転送できます。ただし、これにはIPv4埋め込みIPv6ルートがIPv6ネットワーク全体にフラッディングされ、すべてのルーターに格納される必要があります。これは、スケーリングの観点からは望ましくありません。さらに、すべてのIPv6ルートが同じルーティングテーブルに格納されるため、必要に応じて、トラフィックカテゴリに基づいてルーティングと転送に必要なリソースを管理するのは不便です。
To improve the situation, a separate OSPFv3 routing table dedicated to the IPv4-embedded IPv6 topology can be constructed; that table would be solely used for routing IPv4-embedded IPv6 packets in the IPv6 network. The IPv4-embedded IPv6 topology includes all the participating AFXLBRs and a set of P Routers providing redundant connectivity with alternate routing paths.
状況を改善するために、IPv4組み込みIPv6トポロジ専用の別のOSPFv3ルーティングテーブルを構築できます。このテーブルは、IPv4ネットワークにIPv4埋め込みIPv6パケットをルーティングするためにのみ使用されます。 IPv4組み込みIPv6トポロジには、参加しているすべてのAFXLBRと、代替ルーティングパスとの冗長接続を提供する一連のPルーターが含まれています。
To realize this, a separate OSPFv3 instance is configured in the IPv6 network [RFC5838]. This instance operates on all participating AFXLBRs and a set of P routers that interconnect them. As a result, there would be a dedicated IPv4-embedded IPv6 topology that is maintained on all these routers, along with a dedicated IPv4-embedded IPv6 routing table. This routing table in the IPv6 network is solely for forwarding IPv4-embedded IPv6 packets.
これを実現するために、IPv6ネットワーク[RFC5838]で別のOSPFv3インスタンスが構成されます。このインスタンスは、参加しているすべてのAFXLBRと、それらを相互接続する一連のPルーターで動作します。その結果、専用のIPv4組み込みIPv6ルーティングテーブルと共に、これらすべてのルーターで維持される専用のIPv4組み込みIPv6トポロジが存在します。 IPv6ネットワークのこのルーティングテーブルは、IPv4埋め込みIPv6パケットを転送するためだけのものです。
This document elaborates on how configuration is done with this method and on related routing issues.
このドキュメントでは、この方法で構成を行う方法と、関連するルーティングの問題について詳しく説明します。
This document only focuses on unicast routing for IPv4-embedded IPv6 packets using OSPFv3.
このドキュメントでは、OSPFv3を使用したIPv4埋め込みIPv6パケットのユニキャストルーティングのみに焦点を当てています。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Before deploying configurations that use a separate OSPFv3 routing table for IPv4-embedded IPv6 addresses and prefixes, a decision must be made regarding the set of routers and their interfaces in the IPv6 network that should be part of the IPv4-embedded IPv6 topology.
IPv4埋め込みIPv6アドレスとプレフィックスに個別のOSPFv3ルーティングテーブルを使用する構成を展開する前に、IPv4埋め込みIPv6トポロジの一部であるIPv6ネットワーク内のルーターとそのインターフェイスのセットについて決定する必要があります。
For the purpose of this IPv4-embedded IPv6 topology, all AFXLBRs that connect to IPv4 client networks MUST be members of this topology. An AFXLBR MUST have at least one connection with a P Router in the IPv6 network or another AFXLBR.
このIPv4組み込みIPv6トポロジーの目的のために、IPv4クライアントネットワークに接続するすべてのAFXLBRは、このトポロジーのメンバーでなければなりません。 AFXLBRは、IPv6ネットワークのPルーターまたは別のAFXLBRと少なくとも1つの接続を持っている必要があります。
The IPv4-embedded IPv6 topology is a subtopology of the entire IPv6 network, and if all routers (including AFXLBRs and P routers) and all their interfaces are included, the two topologies converge. Generally speaking, when this subtopology contains more interconnected P Routers, there would be more routing paths across the IPv6 network from one IPv4 client network to the other; however, this requires more routers in the IPv6 network to participate in IPv4-embedded IPv6 routing. In any case, the IPv4-embedded IPv6 topology MUST be continuous with no partitions.
IPv4組み込みIPv6トポロジはIPv6ネットワーク全体のサブトポロジであり、すべてのルーター（AFXLBRとPルーターを含む）とそのすべてのインターフェイスが含まれている場合、2つのトポロジは収束します。一般的に言って、このサブトポロジーに相互接続されたPルーターがより多く含まれている場合、IPv6ネットワーク全体で1つのIPv4クライアントネットワークから他のネットワークへのルーティングパスが多くなります。ただし、IPv4埋め込みIPv6ルーティングに参加するには、IPv6ネットワーク内のルーターがさらに必要です。いずれの場合でも、IPv4組み込みIPv6トポロジは、パーティションなしで連続している必要があります。
In an IPv6 network, in order to maintain a separate IPv6 routing table that contains routes for IPv4-embedded IPv6 destinations only, OSPFv3 needs to use the mechanism defined in [RFC5838].
IPv6ネットワークでは、IPv4埋め込みIPv6宛先のみのルートを含む個別のIPv6ルーティングテーブルを維持するために、OSPFv3は[RFC5838]で定義されたメカニズムを使用する必要があります。
It is assumed that the IPv6 network that is interconnected with IPv4 networks as described in this document is under one administration, and as such an OSPFv3 Instance ID (IID) is allocated locally and used for OSPFv3 operation dedicated to unicast IPv4-embedded IPv6 routing in an IPv6 network. This IID is configured on OSPFv3 router interfaces that participate in the IPv4-embedded IPv6 topology.
このドキュメントで説明されているIPv4ネットワークと相互接続されているIPv6ネットワークは1つの管理下にあると想定されているため、OSPFv3インスタンスID（IID）はローカルに割り当てられ、ユニキャストIPv4組み込みIPv6ルーティング専用のOSPFv3操作に使用されますIPv6ネットワーク。このIIDは、IPv4組み込みIPv6トポロジに参加するOSPFv3ルーターインターフェイスで構成されます。
A locally configured OSPFv3 IID is allocated in the range 192 to 255, inclusive, in the "OSPFv3 Instance ID Address Family Values" registry; this range is reserved for "Private Use" [RFC6969]. This IID must be used to encode the "Instance ID" field in the packet header of OSPFv3 packets associated with the OSPFv3 instance.
ローカルに構成されたOSPFv3 IIDは、「OSPFv3インスタンスIDアドレスファミリ値」レジストリで、192〜255の範囲で割り当てられます。この範囲は「個人使用」[RFC6969]のために予約されています。このIIDを使用して、OSPFv3インスタンスに関連付けられたOSPFv3パケットのパケットヘッダーの「インスタンスID」フィールドをエンコードする必要があります。
In addition, the AF-bit in the OSPFv3 Option field MUST be set.
さらに、OSPFv3オプションフィールドのAFビットを設定する必要があります。
During Hello packet processing, an adjacency may only be established when the received Hello packet contains the same Instance ID as the Instance ID configured on the receiving OSPFv3 interface. This insures that only interfaces configured as part of the OSPFv3 unicast IPv4-embedded IPv6 topology are used for IPv4-embedded IPv6 unicast routing.
Helloパケットの処理中、隣接関係は、受信したHelloパケットに、受信するOSPFv3インターフェイスで構成されているインスタンスIDと同じインスタンスIDが含まれている場合にのみ確立できます。これにより、OSPFv3ユニキャストIPv4組み込みIPv6トポロジの一部として構成されたインターフェイスのみがIPv4組み込みIPv6ユニキャストルーティングに使用されることが保証されます。
For more details, the reader is referred to [RFC5838].
詳細については、[RFC5838]を参照してください。
When transporting IPv4 packets across an IPv6 network via the mechanism described above (Section 3.2), an IPv4 packet is translated to an IPv6 packet at the ingress AFXLBR, and the IPv6 packet is translated back to an IPv4 packet at the egress AFXLBR. IP packet header translation is accomplished in a stateless manner according to rules specified in [RFC6145]; the details of address translation are explained in the next subsection.
前述のメカニズム（セクション3.2）を介してIPv6ネットワークを介してIPv4パケットを転送する場合、IPv4パケットは入力AFXLBRでIPv6パケットに変換され、IPv6パケットは出力AFXLBRでIPv4パケットに変換されます。 IPパケットヘッダーの変換は、[RFC6145]で指定された規則に従って、ステートレスな方法で行われます。アドレス変換の詳細については、次のサブセクションで説明します。
Prior to address translation, an IPv6 prefix is allocated by the operator, and it is used to form IPv4-embedded IPv6 addresses.
アドレス変換の前に、IPv6プレフィックスがオペレーターによって割り当てられ、IPv4埋め込みIPv6アドレスを形成するために使用されます。
The IPv6 prefix can either be the IPv6 well-known prefix (WKP) 64: ff9b::/96 or a network-specific prefix that is unique to the organization; for the latter case, the IPv6 prefix length may be 32, 40, 48, 56, or 64. In either case, this IPv6 prefix is used during the address translation between an IPv4 address and an IPv4-embedded IPv6 address, as described in [RFC6052].
IPv6プレフィックスは、IPv6ウェルノウンプレフィックス（WKP）64：ff9b :: / 96、または組織に固有のネットワーク固有のプレフィックスのいずれかです。後者の場合、IPv6プレフィックス長は32、40、48、56、または64になります。どちらの場合も、このIPv6プレフィックスは、IPv4アドレスとIPv4埋め込みIPv6アドレス間のアドレス変換中に使用されます。 [RFC6052]。
During translation from an IPv4 header to an IPv6 header at an ingress AFXLBR, the source IPv4 address and destination IPv4 address are translated into the corresponding source IPv6 address and destination IPv6 address, respectively. During translation from an IPv6 header to an IPv4 header at an egress AFXLBR, the source IPv6 address and destination IPv6 address are translated into the corresponding source IPv4 address and destination IPv4 address, respectively. Note that address translation is accomplished in a stateless manner.
入力AFXLBRでIPv4ヘッダーからIPv6ヘッダーに変換中に、ソースIPv4アドレスと宛先IPv4アドレスは、それぞれ対応するソースIPv6アドレスと宛先IPv6アドレスに変換されます。出力AFXLBRでIPv6ヘッダーからIPv4ヘッダーへの変換中に、ソースIPv6アドレスと宛先IPv6アドレスは、それぞれ対応するソースIPv4アドレスと宛先IPv4アドレスに変換されます。アドレス変換はステートレスな方法で行われることに注意してください。
When an IPv6 WKP is used, [RFC6052] allows only global IPv4 addresses to be embedded in the IPv6 address. An IPv6 address composed of a WKP and a non-global IPv4 address is hence invalid, and packets that contain such an address received by an AFXLBR are dropped.
IPv6 WKPを使用する場合、[RFC6052]では、IPv6アドレスに埋め込むことができるのはグローバルIPv4アドレスのみです。したがって、WKPと非グローバルIPv4アドレスで構成されるIPv6アドレスは無効であり、AFXLBRが受信したそのようなアドレスを含むパケットはドロップされます。
In the case where both the IPv4 client networks and the IPv6 transit network belong to the same organization, non-global IPv4 addresses may be used with a network-specific prefix [RFC6052].
IPv4クライアントネットワークとIPv6トランジットネットワークの両方が同じ組織に属している場合は、非グローバルIPv4アドレスをネットワーク固有のプレフィックス[RFC6052]で使用できます。
In order to forward IPv4 packets to the proper destination across an IPv6 network, IPv4 reachability information needs to be disseminated throughout the IPv6 network. This is performed by AFXLBRs that connect to IPv4 client networks using OSPFv3.
IPv4パケットをIPv6ネットワークを介して適切な宛先に転送するには、IPv4到達可能性情報をIPv6ネットワーク全体に配布する必要があります。これは、OSPFv3を使用してIPv4クライアントネットワークに接続するAFXLBRによって実行されます。
With the scenario described in this document, i.e., a set of AFXLBRs that interconnect multiple IPv4 client networks with an IPv6 network, the IPv4 networks and IPv6 networks belong to the same or separate Autonomous Systems (ASs), and as such, these AFXLBRs behave as AS Boundary Routers (ASBRs).
このドキュメントで説明されているシナリオ、つまり、複数のIPv4クライアントネットワークをIPv6ネットワークと相互接続するAFXLBRのセットでは、IPv4ネットワークとIPv6ネットワークは同じまたは別個の自律システム（AS）に属しているため、これらのAFXLBRは動作しますAS境界ルーター（ASBR）として。
5.1. Advertising IPv4-Embedded IPv6 Routes through an IPv6 Transit Network
5.1. IPv6トランジットネットワークを介したIPv4組み込みIPv6ルートのアドバタイズ
IPv4 addresses and prefixes in an IPv4 client network are translated into IPv4-embedded IPv6 addresses and prefixes, respectively, using the IPv6 prefix allocated by the operator and the method specified in [RFC6052]. These routes are then advertised by one or more attached ASBRs into the IPv6 transit network using AS-External-LSAs [RFC5340], i.e., with advertising scope comprising the entire Autonomous System.
IPv4クライアントネットワークのIPv4アドレスとプレフィックスは、オペレーターによって割り当てられたIPv6プレフィックスと[RFC6052]で指定された方法を使用して、それぞれIPv4埋め込みIPv6アドレスとプレフィックスに変換されます。これらのルートは、AS-External-LSAs [RFC5340]を使用して、つまり自律システム全体を含むアドバタイズスコープを使用して、1つ以上の接続されたASBRによってIPv6トランジットネットワークにアドバタイズされます。
By default, the metric in an AS-External-LSA that carries an IPv4- embedded IPv6 address or prefixes is a Type 1 external metric, which is comparable to the link state metric, and we assume that in most cases OSPFv2 is used in client IPv4 networks. This metric is added to the metric of the intra-AS path to the ASBR during the OSPFv3 route calculation. Through ASBR configuration, the metric can be set to a Type 2 external metric, which is considered much larger than the metric for any intra-AS path. Refer to the OSPFv3 specification [RFC5340] for more details. In either case, an external metric may take the same value as in an IPv4 network (using OSPFv2 or another routing protocol) but may also be specified based on some routing policy, the details of which are beyond the scope of this document.
デフォルトでは、IPv4埋め込みIPv6アドレスまたはプレフィックスを伝送するAS-External-LSAのメトリックはタイプ1外部メトリックであり、リンク状態メトリックに相当します。ほとんどの場合、OSPFv2がクライアントで使用されると想定していますIPv4ネットワーク。このメトリックは、OSPFv3ルート計算中にASBRへのAS内パスのメトリックに追加されます。 ASBR構成により、メトリックをタイプ2の外部メトリックに設定できます。これは、AS内パスのメトリックよりもはるかに大きいと見なされます。詳細については、OSPFv3仕様[RFC5340]を参照してください。どちらの場合も、外部メトリックはIPv4ネットワークと同じ値（OSPFv2または別のルーティングプロトコルを使用）を取る可能性がありますが、ルーティングポリシーに基づいて指定することもできますが、その詳細はこのドキュメントの範囲外です。
If the "Forwarding Address" field of an OSPFv3 AS-External-LSA is used to carry an IPv6 address, that address must also be an IPv4-embedded IPv6 address where the embedded IPv4 address is the destination address in an IPv4 client network. However, since an AFXLBR sits on the border of an IPv4 network and an IPv6 network, it is RECOMMENDED that the "Forwarding Address" field not be used, so that the AFXLBR can make the forwarding decision based on its own IPv4 routing table.
OSPFv3 AS-External-LSAの「Forwarding Address」フィールドを使用してIPv6アドレスを伝送する場合、そのアドレスもIPv4埋め込みIPv6アドレスである必要があります。ここで、埋め込みIPv4アドレスはIPv4クライアントネットワークの宛先アドレスです。ただし、AFXLBRはIPv4ネットワークとIPv6ネットワークの境界にあるため、「転送アドレス」フィールドを使用しないことをお勧めします。これにより、AFXLBRは独自のIPv4ルーティングテーブルに基づいて転送を決定できます。
IPv4-embedded IPv6 routes injected into the IPv6 network from one IPv4 client network MAY be advertised into another IPv4 client network after the associated destination addresses and prefixes are translated back to IPv4 addresses and prefixes, respectively. This operation is similar to normal OSPFv3 operation, wherein an AS-External-LSA can be advertised in a non-backbone area by default.
1つのIPv4クライアントネットワークからIPv6ネットワークに注入されたIPv4埋め込みIPv6ルートは、関連する宛先アドレスとプレフィックスがそれぞれIPv4アドレスとプレフィックスに変換された後、別のIPv4クライアントネットワークにアドバタイズされる場合があります。この操作は通常のOSPFv3操作に似ており、AS-External-LSAはデフォルトで非バックボーンエリアでアドバタイズできます。
An IPv4 client network can limit which advertisements it receives through configuration.
IPv4クライアントネットワークは、構成を通じて受信する広告を制限できます。
For the purpose of this document, IPv4-embedded IPv6 routes MUST NOT be advertised into any IPv6 client networks that are also connected to the IPv6 transit network.
このドキュメントの目的のために、IPv4埋め込みIPv6ルートは、IPv6トランジットネットワークにも接続されているIPv6クライアントネットワークにアドバタイズしてはなりません。
In order to reduce the amount of Link State Advertisements (LSAs) that are injected into the IPv6 network, an implementation should provide mechanisms to aggregate IPv4 addresses and prefixes at an AFXLBR prior to advertisement as IPv4-embedded IPv6 addresses and prefixes. In general, the aggregation practice should be based on routing policy, which is beyond the scope of this document.
IPv6ネットワークに注入されるリンク状態アドバタイズ（LSA）の量を減らすために、実装は、IPv4埋め込みIPv6アドレスおよびプレフィックスとしてアドバタイズする前に、AFXLBRでIPv4アドレスおよびプレフィックスを集約するメカニズムを提供する必要があります。一般に、集約の実践はルーティングポリシーに基づいている必要がありますが、これはこのドキュメントの範囲を超えています。
There are three cases applicable to forwarding IP packets in the scenario described in this document:
このドキュメントで説明されているシナリオでは、IPパケットの転送に適用できる3つのケースがあります。
1. On an AFXLBR, if an IPv4 packet is received on an interface connecting to an IPv4 segregated client network with a destination IPv4 address belonging to another IPv4 client network, the header of the packet is translated to the corresponding IPv6 header as described in Section 4, and the packet is then forwarded to the destination AFXLBR that advertised the IPv4-embedded IPv6 address into the IPv6 network.
1. AFXLBRでは、IPv4パケットが別のIPv4クライアントネットワークに属する宛先IPv4アドレスを持つIPv4分離クライアントネットワークに接続するインターフェースで受信された場合、パケットのヘッダーは、セクション4で説明されているように、対応するIPv6ヘッダーに変換されます。次に、パケットは、IPv4埋め込みIPv6アドレスをIPv6ネットワークにアドバタイズした宛先AFXLBRに転送されます。
2. On an AFXLBR, if an IPv4-embedded IPv6 packet is received and the embedded destination IPv4 address is in its IPv4 routing table, the header of the packet is translated to the corresponding IPv4 header as described in Section 4, and the packet is then forwarded accordingly.
2. AFXLBRでは、IPv4埋め込みIPv6パケットが受信され、埋め込み宛先IPv4アドレスがそのIPv4ルーティングテーブルにある場合、セクション4で説明されているように、パケットのヘッダーが対応するIPv4ヘッダーに変換され、パケットが転送されます。それに応じて。
3. On any router that is within the IPv4-embedded IPv6 topology subset of the IPv6 network, if an IPv4-embedded IPv6 packet is received and a route is found in the IPv4-embedded IPv6 routing table, the packet is forwarded to the IPv6 next hop, just like the handling for a normal IPv6 packet, without any translation.
3. IPv6ネットワークのIPv4埋め込みIPv6トポロジサブセット内にあるルーターで、IPv4埋め込みIPv6パケットが受信され、ルートがIPv4埋め込みIPv6ルーティングテーブルで見つかった場合、パケットはIPv6ネクストホップに転送されます、通常のIPv6パケットの処理と同様に、変換なし。
The classification of an IPv4-embedded IPv6 packet is done according to the IPv6 prefix of the destination address, which is either the WKP (i.e., 64:ff9b::/96) or locally allocated as defined in [RFC6052].
IPv4埋め込みIPv6パケットの分類は、宛先アドレスのIPv6プレフィックスに従って行われます。これは、WKP（つまり、64：ff9b :: / 96）または[RFC6052]で定義されているようにローカルに割り当てられたものです。
In some deployments, IPv4 client networks are interconnected across the IPv6 network but are also directly connected to each other. The direct connections between IPv4 client networks, sometimes called "backdoor" connections, can certainly be used to transport IPv4 packets between IPv4 client networks. In general, backdoor connections are preferred over the IPv6 network, since no address family translation is required.
一部の展開では、IPv4クライアントネットワークはIPv6ネットワークを介して相互接続されていますが、互いに直接接続されています。 IPv4クライアントネットワーク間の直接接続は、「バックドア」接続とも呼ばれ、IPv4クライアントネットワーク間でIPv4パケットを転送するために使用できます。一般に、アドレスファミリーの変換が必要ないため、IPv6ネットワークよりもバックドア接続が推奨されます。
If an LSA sent from an AFXLBR into a client network could then be received by another AFXLBR, it would be possible for routing loops to occur. To prevent loops, an AFXLBR MUST set the DN bit [RFC4576] in any LSA that it sends to a client network. The AFXLBR MUST also ignore any LSA received from a client network that already has the DN bit set.
AFXLBRからクライアントネットワークに送信されたLSAが別のAFXLBRで受信される可能性がある場合、ルーティングループが発生する可能性があります。ループを防止するために、AFXLBRはクライアントネットワークに送信するすべてのLSAにDNビット[RFC4576]を設定する必要があります。 AFXLBRは、すでにDNビットが設定されているクライアントネットワークから受信したLSAも無視する必要があります。
In the IPv6 network, there are no new MTU issues introduced by this document. If a separate OSPFv3 instance (per [RFC5838]) is used for IPv4-embedded IPv6 routing, the MTU handling in the IPv6 network is the same as that of the default OSPFv3 instance.
IPv6ネットワークでは、このドキュメントで紹介されている新しいMTUの問題はありません。 IPv4埋め込みIPv6ルーティングに別のOSPFv3インスタンス（[RFC5838]による）が使用されている場合、IPv6ネットワークでのMTU処理は、デフォルトのOSPFv3インスタンスのMTU処理と同じです。
However, the MTU in the IPv6 network may be different than that of IPv4 client networks. Since an IPv6 router will never fragment a packet, the packet size of any IPv4-embedded IPv6 packet entering the IPv6 network must be equal to or less than the MTU of the IPv6 network. In order to achieve this requirement, it is recommended that AFXLBRs perform IPv6 path discovery among themselves. The resulting MTU, after taking into account the difference between the IPv4 header length and the IPv6 header length, must be "propagated" into IPv4 client networks, e.g., included in the OSPFv2 Database Description packet.
ただし、IPv6ネットワークのMTUはIPv4クライアントネットワークのMTUとは異なる場合があります。 IPv6ルーターはパケットを断片化しないため、IPv6ネットワークに入るIPv4埋め込みIPv6パケットのパケットサイズは、IPv6ネットワークのMTU以下でなければなりません。この要件を達成するには、AFXLBRがIPv6パスディスカバリを実行することをお勧めします。結果のMTUは、IPv4ヘッダー長とIPv6ヘッダー長の違いを考慮した後、たとえばOSPFv2データベース記述パケットに含まれるように、IPv4クライアントネットワークに「伝播」する必要があります。
The details of passing the proper MTU into IPv4 client networks are beyond the scope of this document.
適切なMTUをIPv4クライアントネットワークに渡す方法の詳細は、このドキュメントの範囲を超えています。
There are several security aspects that require attention in the deployment practices described in this document.
このドキュメントで説明されている展開方法では、注意が必要なセキュリティの側面がいくつかあります。
In the OSPFv3 transit network, the security considerations for OSPFv3 are handled as usual, and in particular, authentication mechanisms described in [RFC6506] can be deployed.
OSPFv3トランジットネットワークでは、OSPFv3のセキュリティに関する考慮事項は通常どおり処理され、特に、[RFC6506]で説明されている認証メカニズムを展開できます。
When a separate OSPFv3 instance is used to support IPv4-embedded IPv6 routing, the same Security Association (SA) [RFC4552] MUST be used by the embedded IPv4 address instance as other instances utilizing the same link, as specified in [RFC5838].
別のOSPFv3インスタンスを使用してIPv4埋め込みIPv6ルーティングをサポートする場合、[RFC5838]で指定されているように、同じリンクを利用する他のインスタンスと同じセキュリティアソシエーション（SA）[RFC4552]を埋め込みIPv4アドレスインスタンスで使用する必要があります。
Security considerations as documented in [RFC6052] must also be thought through and properly implemented, including the following:
[RFC6052]に文書化されているセキュリティの考慮事項も、以下を含めて熟考し、適切に実装する必要があります。
o The IPv6 prefix that is used to carry an embedded IPv4 address (refer to Section 4.1) must be configured by the authorized operator on all participating AFXLBRs in a secure manner. This is to help prevent a malicious attack resulting in network disruption, denial of service, and possible information disclosure.
o 埋め込みIPv4アドレス（セクション4.1を参照）を運ぶために使用されるIPv6プレフィックスは、安全な方法で、参加するすべてのAFXLBRの許可されたオペレーターによって設定される必要があります。これは、ネットワークの混乱、サービス拒否、および情報漏洩の可能性をもたらす悪意のある攻撃を防ぐのに役立ちます。
o Effective mechanisms (such as reverse path checking) must be implemented in the IPv6 transit network (including AFXLBRs) to prevent spoofing of embedded IPv4 addresses, which otherwise might be used as source addresses of malicious packets.
o IPv6トランジットネットワーク（AFXLBRを含む）に効果的なメカニズム（リバースパスチェックなど）を実装して、悪意のあるパケットの送信元アドレスとして使用される可能性がある埋め込みIPv4アドレスのスプーフィングを防止する必要があります。
o If firewalls are used in IPv4 and/or IPv6 networks, configuration of the routers must be consistent, so that there are no holes in IPv4 address filtering.
o ファイアウォールがIPv4またはIPv6ネットワーク、あるいはその両方で使用されている場合、ルーターの構成は一貫している必要があります。これにより、IPv4アドレスフィルタリングに穴ができなくなります。
The details of security handling are beyond the scope of this document.
セキュリティ処理の詳細は、このドキュメントの範囲を超えています。
This document puts together some mechanisms based on existing technologies developed by the IETF as an integrated solution to transport IPv4 packets over an IPv6 network using a separate OSPFv3 routing table. There are several aspects of these mechanisms that require attention for deployment and operation.
このドキュメントでは、個別のOSPFv3ルーティングテーブルを使用してIPv6ネットワーク経由でIPv4パケットを転送する統合ソリューションとして、IETFによって開発された既存のテクノロジーに基づくいくつかのメカニズムをまとめています。これらのメカニズムには、展開と操作のために注意が必要ないくつかの側面があります。
The tunnel-based solution documented in [RFC5565] and the solution proposed in this document are both used for transporting IPv4 packets over an IPv6 network, using different mechanisms. The two methods are not related to each other, and they can coexist in the same network if so deployed, without any conflict.
[RFC5565]で文書化されているトンネルベースのソリューションとこの文書で提案されているソリューションは、どちらも異なるメカニズムを使用して、IPv6ネットワーク経由でIPv4パケットを転送するために使用されます。 2つの方法は互いに関連しておらず、展開されていれば、競合することなく、同じネットワーク内で共存できます。
If one approach is to be deployed, the operator will decide which approach to use. Note that each approach has its own characteristics and requirements. For example, the tunnel-based solution requires a mesh of inter-AFBR softwires (tunnels) spanning the IPv6 network, as well as IBGP to exchange routes between AFBRs [RFC5565]; the approach in this document requires AFXLBRs that are capable of performing IPv4-IPv6 packet header translation per [RFC6145].
1つのアプローチを展開する場合、オペレーターはどのアプローチを使用するかを決定します。それぞれのアプローチには独自の特性と要件があることに注意してください。たとえば、トンネルベースのソリューションでは、IPv6ネットワークにまたがるAFBR間ソフトワイヤー（トンネル）のメッシュと、AFBR間でルートを交換するIBGPが必要です[RFC5565]。このドキュメントのアプローチでは、[RFC6145]に従ってIPv4-IPv6パケットヘッダー変換を実行できるAFXLBRが必要です。
To deploy the solution as documented here, some configurations are required. An IPv6 prefix must first be chosen that is used to form all the IPv4-embedded IPv6 addresses and prefixes advertised by AFXLBRs in the IPv6 network; refer to Section 4.1 for details. The IPv4-embedded IPv6 routing table is created by using a separate OSPFv3 instance in the IPv6 network. As described in Section 3.2, this configuration is accomplished according to the mechanism described in [RFC5838].
ここに記載されているようにソリューションを展開するには、いくつかの構成が必要です。 IPv6ネットワークでAFXLBRによってアドバタイズされるすべてのIPv4埋め込みIPv6アドレスとプレフィックスを形成するために使用されるIPv6プレフィックスを最初に選択する必要があります。詳細については、セクション4.1を参照してください。 IPv4組み込みIPv6ルーティングテーブルは、IPv6ネットワークで別のOSPFv3インスタンスを使用して作成されます。セクション3.2で説明されているように、この構成は[RFC5838]で説明されているメカニズムに従って行われます。
Note that this document does not change any behavior of OSPFv3, and the existing or common practice should apply in the context of scalability. For example, the amount of routes that are advertised by OSPFv3 is one key concern. With the solution as described in this document, IPv4-embedded IPv6 addresses and prefixes will be injected by AFXLBRs into some part of the IPv6 network (see Section 3.1 for details), and a separate routing table will be used for IPv4-embedded IPv6 routing. Care must be taken during network design such that 1) aggregations are performed on IPv4 addresses and prefixes before being advertised in the IPv6 network as described in Section 6, and 2) estimates are made as to the amount of IPv4-embedded IPv6 routes that would be disseminated in the IPv6 network and to the size of the separate OSPFv3 routing table.
このドキュメントはOSPFv3の動作を変更しないことに注意してください。既存または一般的な方法がスケーラビリティのコンテキストで適用される必要があります。たとえば、OSPFv3によってアドバタイズされるルートの量は、重要な問題の1つです。このドキュメントで説明されているソリューションを使用すると、IPv4埋め込みIPv6アドレスとプレフィックスがAFXLBRによってIPv6ネットワークの一部に挿入され（詳細はセクション3.1を参照）、IPv4埋め込みIPv6ルーティングには別のルーティングテーブルが使用されます。ネットワーク設計では、1）セクション6で説明されているようにIPv6ネットワークでアドバタイズされる前にIPv4アドレスとプレフィックスで集計が実行され、2）IPv4に埋め込まれたIPv6ルートの量が見積もられるように注意する必要があります。 IPv6ネットワークで、個別のOSPFv3ルーティングテーブルのサイズまで広めることができます。
Many thanks to Acee Lindem, Dan Wing, Joel Halpern, Mike Shand, and Brian Carpenter for their comments.
コメントを提供してくれたAcee Lindem、Dan Wing、Joel Halpern、Mike Shand、Brian Carpenterに感謝します。
[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月。
[RFC4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4576, June 2006.
[RFC4576] Rosen、E.、Psenak、P。、およびP. Pillay-Esnault、「Link State Advertisement（LSA）オプションビットを使用してBGP / MPLS IP仮想プライベートネットワーク（VPN）でのループを防ぐ」、RFC 4576、 2006年6月。
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", RFC 5565, June 2009.
[RFC5565] Wu、J.、Cui、Y.、Metz、C。、およびE. Rosen、「Softwire Mesh Framework」、RFC 5565、2009年6月。
[RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, April 2010.
[RFC5838] Lindem、A.、Mirtorabi、S.、Roy、A.、Barnes、M。、およびR. Aggarwal、「Support of Address Families in OSPFv3」、RFC 5838、2010年4月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145] Li、X.、Bao、C。、およびF. Baker、「IP / ICMP変換アルゴリズム」、RFC 6145、2011年4月。
[RFC6969] Retana, A. and D. Cheng, "OSPFv3 Instance ID Registry Update", RFC 6969, July 2013.
[RFC6969] Retana、A。およびD. Cheng、「OSPFv3 Instance ID Registry Update」、RFC 6969、2013年7月。
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006.
[RFC4552] Gupta、M。およびN. Melam、「Authentication / Confidentiality for OSPFv3」、RFC 4552、2006年6月。
[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月。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.
[RFC6052] Bao、C.、Huitema、C.、Bagnulo、M.、Boucadair、M。、およびX. Li、「IPv4 / IPv6トランスレータのIPv6アドレッシング」、RFC 6052、2010年10月。
[RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 6506, February 2012.
[RFC6506] Bhatia、M.、Manral、V。、およびA. Lindem、「Supporting Authentication Trailer for OSPFv3」、RFC 6506、2012年2月。
Authors' Addresses
著者のアドレス
Dean Cheng Huawei Technologies 2330 Central Expressway Santa Clara, California 95050 USA
Dean Cheng hu Aはテクノロジー2330中央高速道路、サンタクララ、カリフォルニア95050米国
EMail: dean.cheng@huawei.com
Mohamed Boucadair France Telecom Rennes, 35000 France
Mohamed Boucadair France Telecom Rennes、35000 France
EMail: mohamed.boucadair@orange.com
Alvaro Retana Cisco Systems 7025 Kit Creek Rd. Research Triangle Park, North Carolina 27709 USA
Alvaro Retana Cisco Systems 7025 Kit Creek Rd。 Research Triangle Park、North Carolina 27709 USA
EMail: aretana@cisco.com