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ネットワークの新興成長の展開は、IPv6トランジットバックボーンを横断IPv4ネットワークとの接続性が要求される例をご紹介します。この文書では、BGPのマルチプロトコルの拡張機能を経由してのIPv4オーバー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.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。これは、独立して、他のRFCストリームの、RFCシリーズへの貢献です。 RFC Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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ワーキンググループによって開発され、IETFによって標準化過程文書として公表仕様に関連しているが、関係は、この文書の公開を防ぐことはできません。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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の関連トンネリングプロトコル及び機構が存在します。しかし、この文献に記載のメカニズムが導入された時点で、これらの既存の技術のほとんどは、かなりのIPv6経由の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メカニズムは二つの側面に関するものです。制御プレーンは、エッジルータの多数の間で自動的かつスケーラブルな方法でIPv4のオーバーのIPv6トンネルを設定する方法の問題に対処する必要があります。この文書は、トンネルエンドポイント情報を通信およびIPv6バックボーンネットワークのエッジに位置デュアルスタック・プロバイダ・エッジとの間の4over6トンネル（PE）ルータを確立するために使用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パケットを転送する中継コアとして作用します。これは、IPv4アクセスアイランドの各々は、IPv6トランジットコアにまたがる4over6トンネルを介して互いに通信することが可能となります。
_._._._._ _._._._._
| 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：IPv4からIPv6ネットワークトポロジを超えます
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ルータがあります。正しい出口4over6 PEルータへのIPv6バックボーンを横切ってIPv4パケットを転送する入口4over6のPEルータのために、入口4over6 PEルータは、IPv4宛先プレフィックスが各出口4over6 PEルータを介して到達可能である学ばなければなりません。 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.
イングレス4over6のPEルータは、MP-BGPを経由して、正しい出口4over6のPEルータを学習した後、それはIPカプセル化を使用したIPv6バックボーン間でパケットを転送します。出口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拡張は、ゼブラ・ルーティング・ソフトウェアを拡張することによって開発されました。
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のトランジットバックボーン上にカプセル化されたパケットの送信、及びIPv6ヘッダと、オリジナルのIPv4パケットの転送のデカプセル化：IPv6のトランジットコアを介してIPv4パケットを転送する三つの部分を含みます。 Pルータは、単にネイティブのIPv6パケットとして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].
適用するカプセル化フォーマットは、IPv4アドレス[RFC2473]に概説するように、IPv6の中に封入されています。
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.
図4に示すように各4over6 PEルータは、カプセル化テーブルを維持カプセル化テーブル内の各エントリは、IPv4プレフィックスとそれに対応するIPv6アドレスで構成されています。 IPv4のプレフィックスは、IPv4アクセス島のネットワークに位置特定のネットワークです。 IPv6アドレスは、IPv4のプレフィックスを介して到達可能である4over6 PEルータの4over6仮想インタフェース（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パケットがイングレス4over6 PEルータに到着すると、ローカルIPv4ルーティングテーブルのルックアップは、一致する宛先IPv4プレフィクスを持つローカルカプセル化テーブルエントリへのポインタになります。カプセル化テーブル内の対応するIPv6アドレスがあります。 IPv4パケットは、IPv6ヘッダ内にカプセル化されています。 IPv6ヘッダーのソースアドレスがローカル4over6 PEルータのIPv6のVIFアドレスであり、宛先アドレスがローカルカプセル化テーブルに含まれている遠隔4over6 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.
カプセル化されたパケットが出力4over6 PEルータに到着すると、IPv6ヘッダを除去し、オリジナルのIPv4パケットを出力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インタフェースを有しています。これは、ローカルのIPv4ルーティング情報を交換するためにIGPまたはBGPルーティングプロトコルを使用して、他の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.
各4over6 PEはまた、IPv6の遷移バックボーンにそれを接続するための少なくとも1つのIPv6インタフェースを有しています。 4over6 PEは、典型的には、他のIPv6 PルータとのIPv6バックボーンルーティング情報を交換するためにIGPルーティングプロトコルを使用します。 4over6 PEルータはまた、MP-のiBGP（内部BGP）のIPv6バックボーンネットワークに接続された他の4over6 PEルータとのピアリング関係を形成します。
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のトポロジーAS単一の反射（中国次世代インターネット - 中国教育研究ネットワーク）は、このソリューションのテストと展開に使用される国民のIPv6バックボーン。
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.遠隔4over6のPEルータにMP_REACH_NLRI更新情報の形で局所的なカプセル化テーブルの新しい内容を宣伝。次のようにこれらの更新プログラムの形式は次のとおりです。
* AFI = 1 (IPv4)
* AFI = 1（IPv4）の
* SAFI = 67 (4over6)
*ネット= 67（4ヴェール）
* NLRI = IPv4 network prefix
* NLRI = IPv4ネットワークプレフィックス
* Network Address of Next Hop = IPv6 address of its 4over6 VIF
その4over6 VIFのネクストホップ= 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 4over6などのルーティング情報のSAFIで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. AFI = 1（IPv4）とSAFI = 67（4over6）によって4over6ルーティング情報として受信したBGPアップデートパケットを検証。
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.ローカルIPv4ルーティングテーブルに新しい4over6ルーティング情報を再配布。 、抽出されたIPv4のプレフィックスとして宛先ネットワーク・プレフィックスを設定NULLとしてネクストホップを設定し、ローカル4over6のPEルータの4over6の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.
入口4over6 PEルータは、IPv4パケットを受信した場合、したがって、そのIPv4ルーティングテーブルのルックアップが示されているように、入ってくるIPv4パケットを新しいIPv6ヘッダでカプセル化されるローカル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は、中国教育研究ネットワーク（CERNET）が運営する中国次世代インターネット（CNGI）バックボーンの一つです。 CNGI-CERNET2は2.5-10 Gb /秒の速度で、中国の20都市に分布約25コア・ノードを接続しています。 CNGI-CERNET2骨格は、IPv6のみのデュアルスタックされ、いくつかの付属の顧客宅内ネットワーク（CPNS）です。 CNGI-CERNET2バックボーンは、CNGI-CERNET2 CPNS、およびCNGI-6IX取引所のすべてがAS番号グローバルに一意を持って取り付けられています。このIPv6のバックボーンは、バックボーンに4over6 PEルータを経由して接続されている顧客のIPv4ネットワークのためのトランジットの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×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.
OのHTTP：また、他のアプリケーションプロトコルが正常に以下ごとに試験しました。 1つのIPv4クライアントネットワークでInternet Explorerを実行しているクライアントは、別の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.
（例えば、MSN、Googleトーク）FTP、SSH、IM、およびマルチメディアストリーミングなどの他のプロトコル、すべてが正常に機能しました。
Based on the above successful experiment, we are going to have further experiments in the following two aspects.
上記の成功の実験に基づいて、我々は、以下の2つの面でさらなる実験を持ってしようとしています。
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上に展開されます。ネットワークの発展に伴い、エッジネットワークの間に複数のASが存在し得ます。具体的には、MP-BGPにおけるネクストホップフィールドは、現在の4over6技術のトンネルエンドポイントを示します。しかしながら、インターASのシナリオでは、トンネルエンドポイントは、ネクストホップのフィールドから分離する必要があります。 4over6の技術はMP-BGP、各自律システム境界ルータ（ASBR）上の4over6のサポート性を実行しているルータ上で展開されているので、インターAS実験における主な関心事となります。私たちは、さまざまな状況を考慮することができる：（1）一部のASBRは、4over6をサポートしていません。 （2）のASBRのみ4over6制御プレーンをサポートする（即ち、MP-BGP 4over6の拡張）、むしろ4over6データプレーンより。 （3）のASBRは、制御プレーンと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技術を拡張する必要があります。別のアドレスファミリのバックボーン上エッジネットワークのユニキャスト接続を提供する現在のユニキャスト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 Softwiresワーキンググループ中間会合で発表されたこの大規模な実装と展開の存在が明らかに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メッシュフレームワークへの前駆体とみなすことができます。しかし、この解決策と「softwireメッシュフレームワーク」[RFC5565]および関連ソリューション[RFC5512] [RFC5549]と呼ばれるSoftwiresワーキンググループから生まれた努力にはいくつかの違いがあります。
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は4over6 PEルータ間でクライアントのIPv4プレフィックスを搬送するために新しいSAFI（BGPの4over6）を採用しています。 Softwireメッシュは、元のAFI-SAFI指定を保持し、それは、[RFC5549]をアドレスNEXT_HOPのIPv6とIPv4のネットワークレイヤ到達可能性情報（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・イン・IPを前提としていたり、GREを設定することが可能です。 Softwiresは、ローカルまたは動的更新を必要とするIPヘッダ用に設定された2つのシナリオを使用しています。結果として、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マルチキャスト。基本4over6溶液は、ユニキャスト通信を実現します。マルチキャスト通信はSoftwireメッシュフレームワークで指定され、また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ソリューションは、6over4はのユースケースのために拡張することが非常に簡単です4over6ユースケースを指定します。 SoftwireメッシュFrameworkは、4over6と6over4は両方をサポートしています。
A new SAFI value (67) has been assigned by IANA for the BGP 4over6 SAFI.
新しいSAFI値（67）は、BGP 4over6 SAFIのためにIANAによって割り当てられています。
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溶液は、関連付けられたIPv6アドレスと共にIPv4ルーティング情報を伝達するために、BGPをMPに拡張を介してそのような機能をサポートします。 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.
BGP-MP 4over6延長の4over6枠組みと定義の設計手順の間、教授柯徐は作者に多くの貴重なコメントを与えました。 IETF Softwires WGのサポートも感謝し、この分野での豊富な経験と知識のためのデビッド・ウォード、アラン・デュラン、およびマークTownsleyに感謝と認識されています。ヤコフ・レックターは有用なコメントやアドバイスを提供しました。マークTownsleyは慎重にこの文書を検討し、作者にこの文書を改善するために非常に重要であった貴重なコメントの多くを与えました。
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
すなわち、清華大学、北京大学、北京郵電大学、上海交通大学、華中科技大学、東南 - プロトタイプシステムの展開とテストが7つの大学の間で行われました
University, and South China University of Technology. The authors would like to thank everyone involved in this effort at these universities.
大学、華南理工大学。著者らは、これらの大学では、この取り組みに関わるすべての人に感謝したいと思います。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473]コンタ、A.、およびS.デアリング、 "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.、李、T.、およびS.野兎、 "ボーダーゲートウェイプロトコル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]ベイツ、T.、チャンドラ、R.、カッツ、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.、ドーキンス、S.、ウォード、D.、およびA.デュラン、 "Softwire問題文"、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.ローゼン、 "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]ルFaucheur、F.とE.ローゼン、 "IPv6のネクストホップと広告のIPv4ネットワーク層到達可能性情報"、RFC 5549、2009年5月。
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", RFC 5565, June 2009.
[RFC5565]呉、J.、キュイ、Y.、メス、C.、およびE.ローゼン、 "Softwireメッシュフレームワーク"、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
コンピュータサイエンスのジアンピング・ウ清華大学学部、清華大学、北京100084中華人民共和国電話：+ 86-10-6278-5983 Eメール：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
コンピュータサイエンスの龍崔清華大学学部、清華大学、北京100084中華人民共和国電話：+ 86-10-6278-5822 Eメール：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
電子工学の興李清華大学学部、清華大学、北京100084中華人民共和国電話：+ 86-10-6278-5983 Eメール：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徐清華大学学部、清華大学、北京100084中華人民共和国電話：+ 86-10-6278-5822 Eメール：xmw@csnet1.cs.tsinghua.edu.cn
Chris Metz Cisco Systems, Inc. 3700 Cisco Way San Jose, CA 95134 USA EMail: chmetz@cisco.com
クリス・メッツシスコシステムズ株式会社3700シスコウェイサンノゼ、CA 95134 USA Eメール：chmetz@cisco.com