[要約] RFC 5747は、IPv6 over IPv4トランジットソリューションを提供するためのIPカプセル化とMP-BGP拡張の使用方法を説明しています。このRFCの目的は、IPv6ネットワークのトランジットをIPv4ネットワーク上で可能にするための技術的なガイドラインを提供することです。
Independent Submission J. Wu
Request for Comments: 5747 Y. Cui
Category: Experimental X. Li
ISSN: 2070-1721 M. Xu
Tsinghua University
C. Metz
Cisco Systems, Inc.
March 2010
4over6 Transit Solution Using IP Encapsulation and MP-BGP Extensions
IPカプセル化とMP-BGP拡張機能を使用した4Over6トランジットソリューション
Abstract
概要
The emerging and growing deployment of IPv6 networks will introduce cases where connectivity with IPv4 networks crossing IPv6 transit backbones is desired. This document describes a mechanism for automatic discovery and creation of IPv4-over-IPv6 tunnels via extensions to multiprotocol BGP. It is targeted at connecting islands of IPv4 networks across an IPv6-only backbone without the need for a manually configured overlay of tunnels. The mechanisms described in this document have been implemented, tested, and deployed on the large research IPv6 network in China.
IPv6ネットワークの新たに成長する展開により、IPv4トランジットバックボーンを横切るIPv4ネットワークとの接続性が望まれるケースが導入されます。このドキュメントでは、拡張機能を介してMultiprotocol BGPを介したIPv4-Over-IPV6トンネルの自動発見と作成のメカニズムについて説明します。これは、手動で構成されたトンネルのオーバーレイを必要とせずに、IPv6のみのバックボーン全体でIPv4ネットワークの島を接続することを目的としています。このドキュメントで説明されているメカニズムは、中国の大規模な研究IPv6ネットワークに実装、テスト、展開されています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開が承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。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/rfc5747.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5747で取得できます。
IESG Note
IESGノート
The mechanisms and techniques described in this document are related to specifications developed by the IETF softwire working group and published as Standards Track documents by the IETF, but the relationship does not prevent publication of this document.
このドキュメントで説明されているメカニズムと手法は、IETF Softwire Working Groupによって開発され、IETFが標準を追跡するために公開された仕様に関連していますが、この関係はこのドキュメントの公開を妨げません。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................3
2. 4over6 Framework Overview .......................................3
3. Prototype Implementation ........................................5
3.1. 4over6 Packet Forwarding ...................................5
3.2. Encapsulation Table ........................................6
3.3. MP-BGP 4over6 Protocol Extensions ..........................7
3.3.1. Receiving Routing Information from Local CE .........8
3.3.2. Receiving 4over6 Routing Information from a
Remote 4over6 PE ....................................8
4. 4over6 Deployment Experience ....................................9
4.1. CNGI-CERNET2 ...............................................9
4.2. 4over6 Testbed on the CNGI-CERNET2 IPv6 Network ............9
4.3. Deployment Experiences ....................................10
5. Ongoing Experiment .............................................11
6. Relationship to Softwire Mesh Effort ...........................12
7. IANA Considerations ............................................12
8. Security Considerations ........................................13
9. Conclusion .....................................................13
10. Acknowledgements ..............................................13
11. Normative References ..........................................14
Due to the lack of IPv4 address space, more and more IPv6 networks have been deployed not only on edge networks but also on backbone networks. However, there are still a large number of legacy IPv4 hosts and applications. As a result, IPv6 networks and IPv4 applications/hosts will have to coexist for a long period of time.
IPv4アドレススペースがないため、ますます多くのIPv6ネットワークがエッジネットワークだけでなく、バックボーンネットワークにも展開されています。ただし、まだ多数のレガシーIPv4ホストとアプリケーションがあります。その結果、IPv6ネットワークとIPv4アプリケーション/ホストは、長期間共存する必要があります。
The emerging and growing deployment of IPv6 networks will introduce cases where connectivity with IPv4 networks is desired. Some IPv6 backbones will need to offer transit services to attached IPv4 access networks. The method to achieve this would be to encapsulate and then transport the IPv4 payloads inside IPv6 tunnels spanning the backbone. There are some IPv6/IPv4-related tunneling protocols and mechanisms defined in the literature. But at the time that the mechanism described in this document was introduced, most of these existing techniques focused on the problem of IPv6 over IPv4, rather than the case of IPv4 over IPv6. Encapsulation methods alone, such as those defined in [RFC2473], require manual configuration in order to operate. When a large number of tunnels are necessary, manual configuration can become burdensome. To the above problem, this document describes an approach, referred to as "4over6".
IPv6ネットワークの新たに成長する展開により、IPv4ネットワークとの接続が望まれるケースが導入されます。一部のIPv6バックボーンは、添付のIPv4アクセスネットワークにトランジットサービスを提供する必要があります。これを達成する方法は、バックボーンにまたがるIPv6トンネル内でIPv4ペイロードをカプセル化し、輸送することです。文献で定義されているIPv6/IPv4関連のトンネルプロトコルとメカニズムがいくつかあります。しかし、このドキュメントで説明されているメカニズムが導入された時点で、これらの既存の手法のほとんどは、IPv4を超えるIPv4の場合ではなく、IPv4を介したIPv6の問題に焦点を当てていました。[RFC2473]で定義されているものなど、カプセル化方法だけで、動作するために手動構成が必要です。多数のトンネルが必要な場合、手動構成は負担になる可能性があります。上記の問題に対して、このドキュメントは「4Over6」と呼ばれるアプローチを説明しています。
The 4over6 mechanism concerns two aspects: the control plane and the data plane. The control plane needs to address the problem of how to set up an IPv4-over-IPv6 tunnel in an automatic and scalable fashion between a large number of edge routers. This document describes experimental extensions to Multiprotocol Extension for BGP (MP-BGP) [RFC4271] [RFC4760] employed to communicate tunnel endpoint information and establish 4over6 tunnels between dual-stack Provider Edge (PE) routers positioned at the edge of the IPv6 backbone network. Once the 4over6 tunnel is in place, the data plane focuses on the packet forwarding processes of encapsulation and decapsulation.
4Over6メカニズムは、コントロールプレーンとデータプレーンの2つの側面に関するものです。コントロールプレーンは、多数のエッジルーター間で自動でスケーラブルな方法でIPv4-over-IPV6トンネルをセットアップする方法の問題に対処する必要があります。このドキュメントでは、トンネルエンドポイント情報を通信し、IPV6バックボーンネットワークのエッジに配置されたデュアルスタックプロバイダーエッジ（PE）ルーター間の4OVER6トンネル間の4OVER6トンネルを確立するために使用されるBGP（MP-BGP）[RFC4271] [RFC4760]のマルチプロトコル拡張への実験的拡張について説明しています。。4Over6トンネルが設置されると、データプレーンは、カプセル化と脱カプセル化のパケット転送プロセスに焦点を当てます。
In the topology shown in Figure 1, a number of IPv6-only P routers compose a native IPv6 backbone. The PE routers are dual stack and referred to as 4over6 PE routers. The IPv6 backbone acts as a transit core to transport IPv4 packets across the IPv6 backbone. This enables each of the IPv4 access islands to communicate with one another via 4over6 tunnels spanning the IPv6 transit core.
図1に示すトポロジーでは、多くのIPv6のみのPルーターがネイティブIPv6バックボーンを構成します。PEルーターはデュアルスタックで、4Over6 PEルーターと呼ばれます。IPv6バックボーンは、IPv6バックボーン全体でIPv4パケットを輸送するためのトランジットコアとして機能します。これにより、IPv6トランジットコアにまたがる4OVOR6トンネルを介して各IPv4アクセス島が互いに通信できるようになります。
_._._._._ _._._._._
| IPv4 | | IPv4 |
| access | | access |
| island | | island |
_._._._._ _._._._._
| |
Dual-Stack Dual-Stack
"4over6 PE" "4over6 PE"
| |
| |
__+____________________+__
4over6 / : : : : \ IPv6 only
Tunnels | : : : : | transit core
between | : [P] : | with multiple
PEs | : : : : | [P routers]
| : : : : |
\_._._._._._._._._._._._._./
| / \ |
| |
Dual-Stack Dual-Stack
"4over6 PE" "4over6 PE"
| | |
_._._._._ _._._._._
| IPv4 | | IPv4 |
| access | | access |
| island | | island |
_._._._._ _._._._._
Figure 1: IPv4 over IPv6 Network Topology
図1：IPv6ネットワークトポロジを超えるIPv4
As shown in Figure 1, there are multiple dual-stack PE routers connected to the IPv6 transit core. In order for the ingress 4over6 PE router to forward an IPv4 packet across the IPv6 backbone to the correct egress 4over6 PE router, the ingress 4over6 PE router must learn which IPv4 destination prefixes are reachable through each egress 4over6 PE router. MP-BGP will be extended to distribute the destination IPv4 prefix information between peering dual-stack PE routers. Section 4 of this document presents the definition of the 4over6 protocol field in MP-BGP, and Section 5 describes MP-BGP's extended behavior in support of this capability.
図1に示すように、IPv6トランジットコアに接続された複数のデュアルスタックPEルーターがあります。Ingress 4Over6 PEルーターがIPv4バックボーンを横切るIPv4パケットを正しい出力4Over6 PEルーターに転送するためには、Ingress 4Over6 PEルーターは、各出口4Over6 PEルーターを介してどのIPv4宛先プレフィックスに到達できるかを学習する必要があります。MP-BGPは、デュアルスタックPEルーターのピアリング間に宛先IPv4プレフィックス情報を配布するために拡張されます。このドキュメントのセクション4では、MP-BGPの4Over6プロトコルフィールドの定義を示し、セクション5では、この機能をサポートするMP-BGPの拡張動作について説明します。
After the ingress 4over6 PE router learns the correct egress 4over6 PE router via MP-BGP, it will forward the packet across the IPv6 backbone using IP encapsulation. The egress 4over6 PE router will receive the encapsulated packet, remove the IPv6 header, and then forward the original IPv4 packet to its final IPv4 destination. Section 6 describes the procedure of packet forwarding.
Ingress 4Over6 PEルーターがMP-BGPを介して正しい出力4Over6 PEルーターを学習した後、IPカプセル化を使用してIPv6バックボーンにパケットを転送します。Egress 4over6 PEルーターは、カプセル化されたパケットを受け取り、IPv6ヘッダーを取り外してから、元のIPv4パケットを最終的なIPv4宛先に転送します。セクション6では、パケット転送の手順について説明します。
An implementation of the 4over6 mechanisms described in this document was developed, tested, and deployed on Linux with kernel version 2.4. The prototype system is composed of three components: packet forwarding, the encapsulation table, and MP-BGP extensions. The packet forwarding and encapsulation table are Linux kernel modules, and the MP-BGP extension was developed by extending Zebra routing software.
このドキュメントで説明されている4OVER6メカニズムの実装は、カーネルバージョン2.4を使用してLinuxに開発、テスト、展開されました。プロトタイプシステムは、パケット転送、カプセル化テーブル、MP-BGP拡張機能の3つのコンポーネントで構成されています。パケット転送とカプセル化テーブルはLinuxカーネルモジュールであり、MP-BGP拡張はZebraルーティングソフトウェアを拡張することで開発されました。
The following sections will discuss these parts in detail.
次のセクションでは、これらの部分について詳しく説明します。
Forwarding an IPv4 packet through the IPv6 transit core includes three parts: encapsulation of the incoming IPv4 packet with the IPv6 tunnel header, transmission of the encapsulated packet over the IPv6 transit backbone, and decapsulation of the IPv6 header and forwarding of the original IPv4 packet. Native IPv6 routing and forwarding are employed in the backbone network since the P routers take the 4over6 tunneled packets as just native IPv6 packets. Therefore, 4over6 packet forwarding involves only the encapsulation process and the decapsulation process, both of which are performed on the 4over6 PE routers.
IPv6トランジットコアを介してIPv4パケットを転送するには、IPv6トンネルヘッダーを使用した着信IPv4パケットのカプセル化、IPv6トランジットバックボーン上のカプセル化パケットの送信、IPv6ヘッダーの脱カプセル化と元のIPv4パケットの転送の3つの部分が含まれます。ネイティブIPv6ルーティングと転送は、バックボーンネットワークで採用されています。これは、Pルーターが4Over6トンネルパケットをネイティブIPv6パケットとして撮影するためです。したがって、4Over6パケット転送には、カプセル化プロセスと脱カプセル化プロセスのみが含まれます。どちらも4Over6 PEルーターで実行されます。
Tunnel from Ingress PE to Egress PE
---------------------------->
Tunnel Tunnel
Entry-Point Exit-Point
Node Node
+-+ IPv4 +--+ IPv6 Transit Core +--+ IPv4 +-+
|S|-->--//-->--|PE|=====>=====//=====>=====|PE|-->--//-->--|D|
+-+ +--+ +--+ +-+
Original Ingress PE Egress PE Original
Packet (Encapsulation) (Decapsulation) Packet
Source Destination
Node Node
Figure 2: Packet Forwarding along 4over6 Tunnel
図2：4Over6トンネルに沿ったパケット転送
As shown in Figure 2, packet encapsulation and decapsulation are both on the dual-stack 4over6 PE routers. Figure 3 shows the format of packet encapsulation and decapsulation.
図2に示すように、パケットのカプセル化と脱カプセル化は両方ともデュアルスタック4Over6 PEルーターにあります。図3は、パケットのカプセル化と脱カプセル化の形式を示しています。
+----------------------------------//-----+
| IPv4 Header | Packet Payload |
+----------------------------------//-----+
< Original IPv4 Packet >
|
|(Encapsulation on ingress PE)
|
v
< Tunnel IPv6 Headers > < Original IPv4 Packet >
+-----------+ - - - - - +-------------+-----------//--------------+
| IPv6 | IPv6 | IPv4 | |
| | Extension | | Packet Payload |
| Header | Headers | Header | |
+-----------+ - - - - - +-------------+-----------//--------------+
< Tunnel IPv6 Packet >
|
|(Decapsulation on egress PE)
|
v
+----------------------------------//-----+
| IPv4 Header | Packet Payload |
+----------------------------------//-----+
< Original IPv4 Packet >
Figure 3: Packet Encapsulation and Decapsulation on Dual-Stack 4over6 PE Router
図3：デュアルスタック4Over6 PEルーターのパケットカプセル化と脱カプセル化
The encapsulation format to apply is IPv4 encapsulated in IPv6, as outlined in [RFC2473].
適用するカプセル化形式は、[RFC2473]で概説されているように、IPv6にカプセル化されたIPv4です。
Each 4over6 PE router maintains an encapsulation table as depicted in Figure 4. Each entry in the encapsulation table consists of an IPv4 prefix and its corresponding IPv6 address. The IPv4 prefix is a particular network located in an IPv4 access island network. The IPv6 address is the 4over6 virtual interface (VIF) address of the 4over6 PE router that the IPv4 prefix is reachable through. The encapsulation table is built and maintained using local configuration information and MP-BGP advertisements received from remote 4over6 PE routers.
各4Over6 PEルーターは、図4に示すようにカプセル化テーブルを維持します。カプセル化テーブルの各エントリは、IPv4プレフィックスとその対応するIPv6アドレスで構成されています。IPv4プレフィックスは、IPv4 Access Islandネットワークにある特定のネットワークです。IPv6アドレスは、IPv4プレフィックスに到達可能な4OVOR6 PEルーターの4OVOR6仮想インターフェイス（VIF）アドレスです。カプセル化テーブルは、リモート4over6 PEルーターから受信したローカル構成情報とMP-BGP広告を使用して構築および維持されます。
The 4over6 VIF is an IPv6 /128 address that is locally configured on each 4over6 router. This address, as an ordinary global IPv6 address, must also be injected into the IPv6 IGP so that it is reachable across the IPv6 backbone.
4Over6 VIFは、各4Over6ルーターでローカルに構成されているIPv6 /128アドレスです。このアドレスは、通常のグローバルIPv6アドレスとして、IPv6バックボーン全体にアクセスできるようにIPv6 IGPに注入する必要があります。
+-------------+------------------------------------------------+
| IPv4 Prefix | IPv6 Advertising Address Family Border Router |
+-------------+------------------------------------------------+
Figure 4: Encapsulation Table
図4：カプセル化テーブル
When an IPv4 packet arrives at the ingress 4over6 PE router, a lookup in the local IPv4 routing table will result in a pointer to the local encapsulation table entry with the matching destination IPv4 prefix. There is a corresponding IPv6 address in the encapsulation table. The IPv4 packet is encapsulated in an IPv6 header. The source address in the IPv6 header is the IPv6 VIF address of the local 4over6 PE router and the destination address is the IPv6 VIF address of the remote 4over6 PE router contained in the local encapsulation table. The packet is then subjected to normal IPv6 forwarding for transport across the IPv6 backbone.
IPv4パケットがIngress 4Over6 PEルーターに到着すると、ローカルIPv4ルーティングテーブルを検索すると、一致する宛先IPv4プレフィックスを備えたローカルカプセル化テーブルエントリへのポインターが得られます。カプセル化テーブルには、対応するIPv6アドレスがあります。IPv4パケットは、IPv6ヘッダーにカプセル化されています。IPv6ヘッダーのソースアドレスは、ローカル4Over6 PEルーターのIPv6 VIFアドレスであり、宛先アドレスはローカルカプセル化テーブルに含まれるリモート4OVOR6 PEルーターのIPv6 VIFアドレスです。パケットは、IPv6バックボーンを横切る輸送のために通常のIPv6転送を受けます。
When the encapsulated packet arrives at the egress 4over6 PE router, the IPv6 header is removed and the original IPv4 packet is forwarded to the destination IPv4 network based on the outcome of the lookup in the IPv4 routing table contained in the egress 4over6 PE router.
カプセル化されたパケットがEgress 4Over6 PEルーターに到着すると、IPv6ヘッダーが削除され、元のIPv4パケットは、Egress 4Over6 PEルーターに含まれるIPv4ルーティングテーブルのルックアップの結果に基づいて、宛先IPv4ネットワークに転送されます。
Each 4over6 PE router possesses an IPv4 interface connected to an IPv4 access network(s). It can peer with other IPv4 routers using IGP or BGP routing protocols to exchange local IPv4 routing information. Routing information can also be installed on the 4over6 PE router using static configuration methods.
各4Over6 PEルーターは、IPv4アクセスネットワークに接続されたIPv4インターフェイスを所有しています。IGPまたはBGPルーティングプロトコルを使用して、ローカルIPv4ルーティング情報を交換する他のIPv4ルーターとピアになります。ルーティング情報は、静的構成方法を使用して4Over6 PEルーターにインストールすることもできます。
Each 4over6 PE also possesses at least one IPv6 interface to connect it into the IPv6 transit backbone. The 4over6 PE typically uses IGP routing protocols to exchange IPv6 backbone routing information with other IPv6 P routers. The 4over6 PE router will also form an MP-iBGP (Internal BGP) peering relationship with other 4over6 PE routers connected to the IPv6 backbone network.
各4Over6PEには、IPv6トランジットバックボーンに接続するために、少なくとも1つのIPv6インターフェイスもあります。4OVER6 PEは通常、IGPルーティングプロトコルを使用して、IPv6バックボーンルーティング情報を他のIPv6 Pルーターと交換します。4Over6 PEルーターは、IPv6バックボーンネットワークに接続された他の4Over6 PEルーターとのMP-IBGP（内部BGP）ピアリング関係も形成します。
The use of MP-iBGP suggests that the participating 4over6 PE routers that share a route reflector or form a full mesh of TCP connections are contained in the same autonomous system (AS). This implementation is in fact only deployed over a single AS. This was not an intentional design constraint but rather reflected the single AS topology of the CNGI-CERNET2 (China Next Generation Internet - China Education and Research Network) national IPv6 backbone used in the testing and deployment of this solution.
MP-IBGPの使用は、ルートリフレクターを共有するか、TCP接続の完全なメッシュを形成する参加している4Over6 PEルーターが同じ自律システム（AS）に含まれていることを示唆しています。この実装は、実際には、単一のASにのみ展開されます。これは意図的な設計の制約ではなく、CNGI -Cernet2（China Next Generation Internet -China Education and Research Network）のトポロジーとしてシングルを反映しています。
When a 4over6 PE router learns routing information from the locally attached IPv4 access networks, the 4over6 MP-iBGP entity should process the information as follows:
4over6 PEルーターがローカルに添付されたIPv4アクセスネットワークからルーティング情報を学習する場合、4OVER6 MP-IBGPエンティティは次のように情報を処理する必要があります。
1. Install and maintain local IPv4 routing information in the IPv4 routing database.
1. IPv4ルーティングデータベースにローカルIPv4ルーティング情報をインストールしてメンテナンスします。
2. Install and maintain new entries in the encapsulation table. Each entry should consist of the IPv4 prefix and the local IPv6 VIF address.
2. カプセル化テーブルに新しいエントリをインストールして維持します。各エントリは、IPv4プレフィックスとローカルIPv6 VIFアドレスで構成する必要があります。
3. Advertise the new contents of the local encapsulation table in the form of MP_REACH_NLRI update information to remote 4over6 PE routers. The format of these updates is as follows:
3. MP_REACH_NLRIの形で、ローカルカプセル化テーブルの新しいコンテンツをremote 4over6 PEルーターに更新します。これらの更新の形式は次のとおりです。
* AFI = 1 (IPv4)
* afi = 1（ipv4）
* SAFI = 67 (4over6)
* safi = 67（4over6）
* NLRI = IPv4 network prefix
* NLRI = IPv4ネットワークプレフィックス
* Network Address of Next Hop = IPv6 address of its 4over6 VIF
* 次のホップのネットワークアドレス=その4Over6vifのIPv6アドレス
4. A new Subsequent Address Family Identifier (SAFI) BGP 4over6 (67) has been assigned by IANA. We call a BGP update with a SAFI of 67 as 4over6 routing information.
4. 新しい後続のアドレスファミリ識別子（SAFI）BGP 4Over6（67）がIANAによって割り当てられています。67のSAFIを4OVER6ルーティング情報でBGPアップデートを呼び出します。
A local 4over6 PE router will receive MP_REACH_NLRI updates from remote 4over6 routers and use that information to populate the local encapsulation table and the BGP routing database. After validating the correctness of the received attribute, the following procedures are used to update the local encapsulation table and redistribute new information to the local IPv4 routing table:
ローカル4OVER6 PEルーターは、リモート4OVER6ルーターからMP_REACH_NLRI更新を受け取り、その情報を使用してローカルカプセル化テーブルとBGPルーティングデータベースを入力します。受信属性の正しさを検証した後、次の手順を使用してローカルカプセル化テーブルを更新し、新しい情報をローカルIPv4ルーティングテーブルに再配布します。
1. Validate the received BGP update packet as 4over6 routing information by AFI = 1 (IPv4) and SAFI = 67 (4over6).
1. 受信したBGPアップデートパケットを、AFI = 1（IPv4）およびSAFI = 67（4OVOR6）による4OVER6ルーティング情報として検証します。
2. Extract the IPv4 network address from the NLRI field and install as the IPv4 network prefix.
2. NLRIフィールドからIPv4ネットワークアドレスを抽出し、IPv4ネットワークプレフィックスとしてインストールします。
3. Extract the IPv6 address from the Network Address of the Next Hop field and place that as an associated entry next to the IPv4 network index. (Note, this describes the update of the local encapsulation table.)
3. 次のホップフィールドのネットワークアドレスからIPv6アドレスを抽出し、IPv4ネットワークインデックスの隣の関連するエントリとして配置します。（注、これはローカルカプセル化テーブルの更新について説明しています。）
4. Install and maintain a new entry in the encapsulation table with the extracted IPv4 prefix and its corresponding IPv6 address.
4. 抽出されたIPv4プレフィックスと対応するIPv6アドレスを使用して、カプセル化テーブルに新しいエントリをインストールして維持します。
5. Redistribute the new 4over6 routing information to the local IPv4 routing table. Set the destination network prefix as the extracted IPv4 prefix, set the Next Hop as Null, and Set the OUTPUT Interface as the 4over6 VIF on the local 4over6 PE router.
5. 新しい4over6ルーティング情報をローカルIPv4ルーティングテーブルに再配布します。宛先ネットワークのプレフィックスを抽出されたIPv4プレフィックスとして設定し、次のホップをNULLとして設定し、ローカル4OVOR6 PEルーターの4OVOR6 VIFとして出力インターフェイスを設定します。
Therefore, when an ingress 4over6 PE router receives an IPv4 packet, the lookup in its IPv4 routing table will have a result of the output interface as the local 4over6 VIF, where the incoming IPv4 packet will be encapsulated with a new IPv6 header, as indicated in the encapsulation table.
したがって、Ingress 4Over6 PEルーターがIPv4パケットを受信すると、IPv4ルーティングテーブルのルックアップは、ローカル4Over6 VIFとしての出力インターフェイスの結果が得られます。カプセル化テーブルで。
A prototype of the 4over6 solution is implemented and deployed on CNGI-CERNET2. CNGI-CERNET2 is one of the China Next Generation Internet (CNGI) backbones, operated by the China Education and Research Network (CERNET). CNGI-CERNET2 connects approximately 25 core nodes distributed in 20 cities in China at speeds of 2.5-10 Gb/s. The CNGI-CERNET2 backbone is IPv6-only with some attached customer premise networks (CPNs) being dual stack. The CNGI-CERNET2 backbone, attached CNGI-CERNET2 CPNs, and CNGI-6IX Exchange all have globally unique AS numbers. This IPv6 backbone is used to provide transit IPv4 services for customer IPv4 networks connected via 4over6 PE routers to the backbone.
4over6ソリューションのプロトタイプが実装され、CNGI-Cernet2に展開されます。CNGI-Cernet2は、China Education and Research Network（Cernet）が運営する中国次世代インターネット（CNGI）バックボーンの1つです。CNGI-Cernet2は、2.5〜10 GB/sの速度で中国の20の都市に分布した約25のコアノードを接続します。CNGI-Cernet2バックボーンはIPv6のみであり、いくつかの添付の顧客前提ネットワーク（CPNS）がデュアルスタックです。CNGI-Cernet2バックボーン、CNGI-Cernet2 CPNS、CNGI-6IX Exchangeはすべて、数字としてグローバルに一意のものです。このIPv6バックボーンは、4Over6PEルーターを介してバックボーンに接続された顧客IPv4ネットワークにTransit IPv4サービスを提供するために使用されます。
Figure 5 shows 4over6 deployment network topology.
図5は、4Over6展開ネットワークトポロジを示しています。
+-----------------------------------------------------+
| IPv6 (CERNET2) |
| |
+-----------------------------------------------------+
| | | |
Tsinghua|Univ. Peking|Univ. SJTU| Southeast|Univ.
+------+ +------+ +------+ +------+
|4over6| ... |4over6| |4over6| ... |4over6|
|router| |router| |router| |router|
+------+ +------+ +------+ +------+
| | | |
| | | |
| | | |
+-----------+ +-----------+ +-----------+ +-----------+
|IPv4 access| ... |IPv4 access| |IPv4 access| ... |IPv4 access|
| network | | network | | network | | network |
+-----------+ +-----------+ +-----------+ +-----------+
|
+----------------------+
| IPv4 (Internet) |
| |
+----------------------+
Figure 5: 4over6 Deployment Network Topology
図5：4Over6展開ネットワークトポロジ
The IPv4-only access networks are equipped with servers and clients running different applications. The 4over6 PE routers are deployed at 8 x IPv6 nodes of CNGI-CERNET2, located in seven universities and five cities across China. As suggested in Figure 5, some of the IPv4 access networks are connected to both IPv6 and IPv4 networks, and others are only connected to the IPv6 backbone. In the deployment, users in different IPv4 networks can communicate with each other through 4over6 tunnels.
IPv4のみのアクセスネットワークには、さまざまなアプリケーションを実行しているサーバーとクライアントが装備されています。4Over6 PEルーターは、中国の7つの大学と5つの都市にあるCNGI-Cernet2の8 x IPv6ノードに展開されています。図5で示唆されているように、IPv4アクセスネットワークの一部はIPv6ネットワークとIPv4ネットワークの両方に接続されており、その他はIPv6バックボーンにのみ接続されています。展開では、さまざまなIPv4ネットワークのユーザーが4Over6トンネルを介して互いに通信できます。
A number of 4over6 PE routers were deployed and configured to support the 4over6 transit solution. MP-BGP peerings were established, and successful distribution of 4over6 SAFI information occurred. Inspection of the BGP routing and encapsulation tables confirmed that the correct entries were sent and received. ICMP ping traffic indicated that IPv4 packets were successfully transiting the IPv6 backbone.
4Over6 PEルーターの多くが展開され、4Over6トランジットソリューションをサポートするように構成されました。MP-BGPピーリングが確立され、4Over6 SAFI情報の成功した分布が発生しました。BGPルーティングとカプセル化表の検査により、正しいエントリが送信されて受信されたことが確認されました。ICMP Pingトラフィックは、IPv4パケットがIPv6バックボーンを正常に通過していることを示しました。
In addition, other application protocols were successfully tested per the following: o HTTP. A client running Internet Explorer in one IPv4 client network was able to access and download multiple objects from an HTTP server located in another IPv4 client network.
さらに、他のアプリケーションプロトコルは、次のように正常にテストされました。OHTTP。あるIPv4クライアントネットワークでインターネットエクスプローラーを実行しているクライアントは、別のIPv4クライアントネットワークにあるHTTPサーバーから複数のオブジェクトにアクセスしてダウンロードできました。
o P2P. BitComet software running on several PCs placed in different IPv4 client networks were able to find each other and share files.
o p2p。異なるIPv4クライアントネットワークに配置された複数のPCで実行されているBitcometソフトウェアは、お互いを見つけてファイルを共有することができました。
Other protocols, including FTP, SSH, IM (e.g., MSN, Google Talk), and Multimedia Streaming, all functioned correctly.
FTP、SSH、IM（MSN、Google Talkなど）、マルチメディアストリーミングを含む他のプロトコルはすべて正しく機能しました。
Based on the above successful experiment, we are going to have further experiments in the following two aspects.
上記の成功した実験に基づいて、次の2つの側面でさらに実験を行う予定です。
1. Inter-AS 4over6
1. 4over6 as inter-as
The above experiment is only deployed over a single AS. With the growth of the network, there could be multiple ASes between the edge networks. Specifically, the Next Hop field in MP-BGP indicates the tunnel endpoint in the current 4over6 technology. However, in the Inter-AS scenario, the tunnel endpoint needs to be separated from the field of Next Hop. Moreover, since the technology of 4over6 is deployed on the router running MP-BGP, the supportability of 4over6 on each Autonomous System Border Router (ASBR) will be a main concern in the Inter-AS experiment. We may consider different situations: (1) Some ASBRs do not support 4over6; (2) ASBRs only support the 4over6 control plane (i.e., MP-BGP extension of 4over6) rather than 4over6 data plane; (3) ASBRs support both the control plane and the data plane for 4over6.
上記の実験は、単一のASにのみ展開されます。ネットワークの成長に伴い、エッジネットワーク間に複数のASEが存在する可能性があります。具体的には、MP-BGPの次のホップフィールドは、現在の4Over6テクノロジーのトンネルエンドポイントを示しています。ただし、AS Inter-ASシナリオでは、トンネルエンドポイントを次のホップのフィールドから分離する必要があります。さらに、MP-BGPを実行しているルーターに4Over6の技術が展開されるため、各自律システムボーダールーター（ASBR）での4Over6のサポート性は、AS Inter-AS実験の主な関心事です。さまざまな状況を検討する場合があります。（1）一部のASBRは4Over6をサポートしていません。（2）ASBRSは、4Over6データプレーンではなく、4OVER6コントロールプレーン（つまり、4OVER6のMP-BGP拡張）のみをサポートしています。（3）ASBRSは、4Over6のコントロールプレーンとデータプレーンの両方をサポートしています。
2. Multicast 4over6
2. マルチキャスト4Over6
The current 4over6 technology only supports unicast routing and data forwarding. With the deployment of network-layer multicast in multiple IPv4 edge networks, we need to extend the 4over6 technology to support multicast including both multicast tree manipulation on the control plane and multicast traffic forwarding on the data plane. Based on the current unicast 4over6 technology providing the unicast connectivity of edge networks over the backbone in another address family, the multicast 4over6 will focus on the mapping technologies between the multicast groups in the different address families.
現在の4Over6テクノロジーは、ユニキャストルーティングとデータ転送のみをサポートしています。複数のIPv4エッジネットワークでネットワーク層マルチキャストの展開により、コントロールプレーンでのマルチキャストツリー操作とデータプレーンでのマルチキャストトラフィックの両方の転送など、マルチキャストをサポートするために4Over6テクノロジーを拡張する必要があります。別のアドレスファミリーのバックボーン上のエッジネットワークのユニキャスト接続を提供する現在のUnicast 4Over6テクノロジーに基づいて、マルチキャスト4OVER6は、異なるアドレスファミリのマルチキャストグループ間のマッピングテクノロジーに焦点を当てます。
The 4over6 solution was presented at the IETF Softwires Working Group Interim meeting in Hong Kong in January 2006. The existence of this large-scale implementation and deployment clearly showed that MP-BGP could be employed to support tunnel setup in a scalable fashion across an IPv6 backbone. Perhaps most important was the use-case presented -- an IPv6 backbone that offers transit to attached client IPv4 networks.
4OVER6ソリューションは、2006年1月に香港で開催されたIETFソフトワイヤワーキンググループの暫定会議で発表されました。この大規模な実装と展開の存在は、MP-BGPを使用してIPv6を介してスケーラブルな方法でトンネルのセットアップをサポートすることができることを明確に示しました。背骨。おそらく最も重要なのは、提示されたユースケース - 添付のクライアントIPv4ネットワークへのトランジットを提供するIPv6バックボーンです。
The 4over6 solution can be viewed as a precursor to the Softwire Mesh Framework proposed in the softwire problem statement [RFC4925]. However, there are several differences with this solution and the effort that emerged from the Softwires Working Group called "softwire Mesh Framework" [RFC5565] and the related solutions [RFC5512] [RFC5549].
4over6ソリューションは、Softwire問題ステートメント[RFC4925]で提案されているSoftwireメッシュフレームワークの前駆体として見ることができます。ただし、このソリューションにはいくつかの違いがあり、「ソフトワイヤーメッシュフレームワーク」[RFC5565]および関連ソリューション[RFC5512] [RFC5549]と呼ばれるソフトウェアワーキンググループから出現した努力があります。
o MP-BGP Extensions. 4over6 employs a new SAFI (BGP 4over6) to convey client IPv4 prefixes between 4over6 PE routers. Softwire Mesh retains the original AFI-SAFI designations, but it uses a modified MP_REACH_NLRI format to convey IPv4 Network Layer Reachability Information (NLRI) prefix information with an IPv6 next_hop address [RFC5549].
o MP-BGP拡張機能。4OVER6は、新しいSAFI（BGP 4Over6）を使用して、4OVER6 PEルーター間でクライアントIPv4プレフィックスを伝えます。Softwire Meshは元のAFI-Safi指定を保持していますが、IPv6 Next_Hopアドレス[RFC5549]を使用して、IPv4ネットワークレイヤーReachability情報（NLRI）プレフィックス情報を伝達するために変更されたMP_REACH_NLRI形式を使用します。
o Encapsulation. 4over6 assumes IP-in-IP or it is possible to configure Generic Routing Encapsulation (GRE). Softwires uses those two scenarios configured locally or for IP headers that require dynamic updating. As a result, the BGP encapsulation SAFI is introduced in [RFC5512].
o カプセル化。4Over6はIP-in-IPを想定するか、ジェネリックルーティングカプセル化（GRE）を構成することができます。Softwiresは、ローカルで構成されているこれらの2つのシナリオを使用するか、動的更新を必要とするIPヘッダーに使用します。その結果、BGPカプセル化Safiは[RFC5512]に導入されています。
o Multicast. The basic 4over6 solution only implemented unicast communications. The multicast communications are specified in the Softwire Mesh Framework and are also supported by the multicast extension of 4over6.
o マルチキャスト。Basic 4over6ソリューションは、ユニキャスト通信のみを実装しました。マルチキャスト通信は、Softwire Meshフレームワークで指定されており、4Over6のマルチキャスト拡張によってもサポートされています。
o Use-Cases. The 4over6 solution in this document specifies the 4over6 use-case, which is also pretty easy to extend for the use-case of 6over4. The Softwire Mesh Framework supports both 4over6 and 6over4.
o ユースケース。このドキュメントの4Over6ソリューションは、4Over6ユースケースを指定します。これは、6Over4のユースケースでも非常に簡単に拡張できます。Softwire Meshフレームワークは、4Over6と6Over4の両方をサポートしています。
A new SAFI value (67) has been assigned by IANA for the BGP 4over6 SAFI.
BGP 4over6 SafiにIANAによって新しいSAFI値（67）が割り当てられています。
Tunneling mechanisms, especially automatic ones, often have potential problems of Distributed Denial of Service (DDoS) attacks on the tunnel entry-point or tunnel exit-point. As the advantage, the BGP 4over6 extension doesn't allocate resources to a single flow or maintain the state for a flow. However, since the IPv6 tunnel endpoints are globally reachable IPv6 addresses, it would be trivial to spoof IPv4 packets by encapsulating and sending them over IPv6 to the tunnel interface. This could bypass IPv4 Reverse Path Forwarding (RPF) or other antispoofing techniques. Also, any IPv4 filters may be bypassed.
トンネルメカニズム、特に自動メカニズムは、多くの場合、トンネルの入力ポイントまたはトンネル出口ポイントに対する分散拒否（DDOS）攻撃の潜在的な問題を抱えています。利点として、BGP 4over6拡張は、単一のフローにリソースを割り当てたり、フローの状態を維持したりしません。ただし、IPv6トンネルのエンドポイントはグローバルに到達可能なIPv6アドレスであるため、IPv6をカプセル化してトンネルインターフェイスに送信することにより、IPv4パケットをスプーフィングすることは簡単です。これにより、IPv4リバースパス転送（RPF）または他の防腐剤技術をバイパスできます。また、IPv4フィルターはバイパスされる場合があります。
An iBGP peering relationship may be maintained over IPsec or other secure communications.
IBGPのピアリング関係は、IPSECまたはその他の安全な通信を介して維持される場合があります。
The emerging and growing deployment of IPv6 networks, in particular, IPv6 backbone networks, will introduce cases where connectivity with IPv4 networks is desired. Some IPv6 backbones will need to offer transit services to attached IPv4 access networks. The 4over6 solution outlined in this document supports such a capability through an extension to MP-BGP to convey IPv4 routing information along with an associated IPv6 address. Basic IP encapsulation is used in the data plane as IPv4 packets are tunneled through the IPv6 backbone.
IPv6ネットワークの新たに成長している展開、特にIPv6バックボーンネットワークは、IPv4ネットワークとの接続が望まれるケースを導入します。一部のIPv6バックボーンは、添付のIPv4アクセスネットワークにトランジットサービスを提供する必要があります。このドキュメントで概説されている4Over6ソリューションは、MP-BGPへの拡張機能を介してそのような機能をサポートし、関連するIPv6アドレスとともにIPv4ルーティング情報を伝えます。IPv4パケットがIPv6バックボーンを通じてトンネル化されるため、基本的なIPカプセル化はデータプレーンで使用されます。
An actual implementation has been developed and deployed on the CNGI-CERNET2 IPv6 backbone.
実際の実装が開発され、CNGI-Cernet2 IPv6バックボーンに展開されています。
During the design procedure of the 4over6 framework and definition of BGP-MP 4over6 extension, Professor Ke Xu gave the authors many valuable comments. The support of the IETF Softwires WG is also gratefully acknowledged with special thanks to David Ward, Alain Durand, and Mark Townsley for their rich experience and knowledge in this field. Yakov Rekhter provided helpful comments and advice. Mark Townsley reviewed this document carefully and gave the authors a lot of valuable comments, which were very important for improving this document.
4OVER6フレームワークの設計手順とBGP-MP 4Over6拡張の定義中に、Ke Xu教授は著者に多くの貴重なコメントを与えました。IETFソフトウェアWGのサポートは、この分野での豊かな経験と知識について、David Ward、Alain Durand、Mark Townsleyに感謝していることに感謝しています。Yakov Rekhterは、有益なコメントとアドバイスを提供しました。マークタウンズリーはこのドキュメントを慎重にレビューし、著者に多くの貴重なコメントを与えました。これはこの文書を改善するために非常に重要でした。
The deployment and test for the prototype system was conducted among seven universities -- namely, Tsinghua University, Peking University, Beijing University of Post and Telecommunications, Shanghai Jiaotong University, Huazhong University of Science and Technology, Southeast University, and South China University of Technology. The authors would like to thank everyone involved in this effort at these universities.
プロトタイプシステムの展開とテストは、7つの大学の間で実施されました。つまり、Tsinghua University、Peking University、北京郵便通信大学、上海Jiaotong大学、Huazhong科学技術大学、南東大学、南中国工科大学。著者は、これらの大学でこの取り組みに関与しているすべての人に感謝したいと思います。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473] Conta、A。およびS. Deering、「IPv6仕様の一般的なパケットトンネル」、RFC 2473、1998年12月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Li、T。、およびS. Hares、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760] Bates、T.、Chandra、R.、Katz、D。、およびY. Rekhter、「BGP-4のマルチプロトコル拡張」、RFC 4760、2007年1月。
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007.
[RFC4925] Li、X.、Dawkins、S.、Ward、D。、およびA. Durand、「Softwire Problem Statement」、RFC 4925、2007年7月。
[RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC 5512, April 2009.
[RFC5512] Mohapatra、P。およびE. Rosen、「BGPカプセル化後のアドレスファミリー識別子（SAFI）およびBGPトンネルカプセル化属性」、RFC 5512、2009年4月。
[RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop", RFC 5549, May 2009.
[RFC5549] Le Faucheur、F。およびE. Rosen、「IPv4 Networt Layer Reachability情報をIPv6 Next Hopで広告」、RFC 5549、2009年5月。
[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月。
Authors' Addresses
著者のアドレス
Jianping Wu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R. China Phone: +86-10-6278-5983 EMail: jianping@cernet.edu.cn
Jianping Wu Tsinghua University of Computer Science、Tsinghua University Beijing 100084 P.R. China Phone：86-10-6278-5983メール：jianping@cernet.edu.cn
Yong Cui Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R. China Phone: +86-10-6278-5822 EMail: cy@csnet1.cs.tsinghua.edu.cn
Yong Cui Tsinghua University of Computer Science、Tsinghua University Beijing 100084 P.R. China Phone：86-10-6278-5822メール：cy@csnet1.cs.tsinghua.edu.cn
Xing Li Tsinghua University Department of Electronic Engineering, Tsinghua University Beijing 100084 P.R. China Phone: +86-10-6278-5983 EMail: xing@cernet.edu.cn
Xing Li Tsinghua大学電子工学部、Tsinghua University Beijing 100084 P.R. China Phone：86-10-6278-5983メール：xing@cernet.edu.cn
Mingwei Xu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R. China Phone: +86-10-6278-5822 EMail: xmw@csnet1.cs.tsinghua.edu.cn
Mingwei Xu Tsinghua University of Computer Science、Tsinghua University Beijing 100084 P.R. China Phone：86-10-6278-5822メール：xmw@csnet1.cs.tsinghua.edu.cn
Chris Metz Cisco Systems, Inc. 3700 Cisco Way San Jose, CA 95134 USA EMail: chmetz@cisco.com
Chris Metz Cisco Systems、Inc。3700 Cisco Way San Jose、CA 95134 USAメール：chmetz@cisco.com