[要約] RFC 5569は、IPv4インフラストラクチャ上でのIPv6の迅速な展開（6rd）に関するものであり、IPv6の導入を容易にするための技術的なガイドラインを提供しています。目的は、IPv6の普及を促進し、IPv4インフラストラクチャ上でのIPv6の展開を効率化することです。
Independent Submission R. Despres
Request for Comments: 5569 RD-IPtech
Category: Informational January 2010
ISSN: 2070-1721
IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
IPv4インフラストラクチャのIPv6迅速な展開（6番目）
Abstract
概要
IPv6 rapid deployment on IPv4 infrastructures (6rd) builds upon mechanisms of 6to4 to enable a service provider to rapidly deploy IPv6 unicast service to IPv4 sites to which it provides customer premise equipment. Like 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to transit IPv4-only network infrastructure. Unlike 6to4, a 6rd service provider uses an IPv6 prefix of its own in place of the fixed 6to4 prefix. A service provider has used this mechanism for its own IPv6 "rapid deployment": five weeks from first exposure to 6rd principles to more than 1,500,000 residential sites being provided native IPv6, under the only condition that they activate it.
IPv4インフラストラクチャ（6RD）でのIPv6 Rapid Deploymentは、6to4のメカニズムに基づいて構築され、サービスプロバイダーが顧客の前提装備を提供するIPv4サイトにIPv6 Unicastサービスを迅速に展開できるようにします。6to4と同様に、IPv4のみのネットワークインフラストラクチャをトランジットするために、IPv4カプセル化でStateless IPv6を使用します。6to4とは異なり、第6サービスプロバイダーは、固定6to4プレフィックスの代わりに独自のIPv6プレフィックスを使用します。サービスプロバイダーは、このメカニズムを独自のIPv6の「迅速な展開」に使用しています。最初の露出から第6の原則への5週間から、1,500,000を超える住宅サイトがネイティブIPv6を提供する唯一の条件の下で、1,500,000を超える住宅用サイトに5週間です。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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/rfc5569.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5569で取得できます。
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 ....................................................2
2. Problem Statement and Purpose of 6rd ............................3
3. Specification ...................................................4
4. Applicability to ISPs That Assign Private IPv4 Addresses ........7
5. Security Considerations .........................................8
6. IANA Considerations .............................................8
7. Acknowledgements ................................................9
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References .....................................9
After having had a succinct presentation of the 6rd idea, a major French Internet service provider (ISP), Free of the Iliad group (hereafter Free), did all of the following in an impressively short delay of only five weeks (November 7th to December 11th 2007):
第6アイデアの簡潔なプレゼンテーションを行った後、Iliad Group（以下無料）がない主要なフランスのインターネットサービスプロバイダー（ISP）は、わずか5週間（11月7日から12月までのわずかな短い遅延で以下をすべて行いました。2007年11日）：
1. obtained from its regional Internet Registry (RIR) an IPv6 prefix, the length of which was that allocated without a justification and a delay to examine it, namely /32;
1. 地域のインターネットレジストリ（RIR）から取得されたIPv6プレフィックスは、正当化とそれを調べる遅延なし、つまり /32なしで割り当てられた長さでした。
2. added 6rd support to the software of its Freebox home-gateway (upgrading for this an available 6to4 code);
2. Freebox Home-Gatewayのソフトウェアに6番目のサポートを追加しました（これのアップグレードは、利用可能な6to4コードをアップグレードします）。
3. provisioned PC-compatible platform with a 6to4 gateway software;
3. 6to4ゲートウェイソフトウェアを備えたプロビジョニングされたPC互換プラットフォーム。
4. modified it to support 6rd;
4. 6番目をサポートするように変更しました。
5. tested IPv6 operation with several operating systems and applications;
5. いくつかのオペレーティングシステムとアプリケーションでテストされたIPv6操作。
6. finished operational deployment, by means of new version of the downloadable software of their Freeboxes;
6. フリーボックスのダウンロード可能なソフトウェアの新しいバージョンを使用して、完成した運用展開。
7. announced IPv6 Internet connectivity, at no extra charge, for all its customers wishing to activate it.
7. IPv6インターネット接続は、それをアクティブにしたいすべての顧客のために、追加料金なしで発表しました。
More than 1,500,000 residential customers thus became able to use IPv6 if they wished, with all the look and feel of native IPv6 addresses routed in IPv6. The only condition was an activation of IPv6 in their Freeboxes, and of course in their IPv6-capable hosts.
したがって、1,500,000人以上の住宅顧客が、IPv6でルーティングされたすべての外観と感触を使用して、IPv6を希望する場合はIPv6を使用することができました。唯一の条件は、フリーボックス、そしてもちろんIPv6対応ホストでのIPv6の活性化でした。
This story is reported to illustrate that ISPs that provide customer premise equipment (CPE) to their clients, with included routing capability, and that have so far postponed IPv6 deployment can, with the dramatically reduced investment and operational costs that 6rd make possible, decide to wait no longer.
このストーリーは、クライアントに顧客の前提装備（CPE）を提供し、ルーティング機能を含めて、これまでにIPv6の展開を延期できるISPが、6番目の投資と運用コストを劇的に削減できることを示していることを示しています。もう待っていません。
To complete the story, Free announced, on March 6th 2008, that provided two of its customer sites had IPv6 activated, its Telesites application (Web sites published on TV) could now be used remotely between them.
ストーリーを完成させるために、2008年3月6日に無料で発表された2つの顧客サイトがIPv6をアクティブにしたため、Telesitesアプリケーション（テレビで公開されているWebサイト）をリモートで使用できるようになりました。
While IPv6 availability was limited in December 2007 to only one IPv6 link per customer site (with /64 site-prefix assignments). A few months later, after Free had detailed its achievement and plans to its RIR, and then obtained from it a /26 prefix, up to 16 IPv6 links per customer became possible (with /60 site-prefix assignments).
2007年12月にIPv6の可用性は、顧客サイトごとに1つのIPv6リンクのみに制限されていました（ /64 Site-Prefix割り当て）。数ヶ月後、FreeがRIRにその功績と計画を詳述し、その後A /26プレフィックスから取得した後、顧客ごとに最大16のIPv6リンクが可能になりました（ /60 Site-Prefix割り当てで）。
Readers are supposed to be familiar with 6to4 [RFC3056].
読者は6to4 [RFC3056]に精通しているはずです。
Having ISPs to rapidly bring IPv6 to customers' sites, in addition to IPv4 and without extra charge, is a way to break the existing vicious circle that has delayed IPv6 deployment: ISPs wait for customer demand before deploying IPv6; customers don't demand IPv6 as long as application vendors announce that their products work on existing infrastructures (that are IPv4 with NATs); application vendors focus their investments on NAT traversal compatibility as long as ISPs don't deploy IPv6.
IPv6を顧客のサイトに迅速に持ち込むためのISPSがIPv4に加えて追加料金なしで、IPv6の展開が遅れた既存の悪循環を破る方法です。ISPはIPv6を展開する前に顧客需要を待ちます。アプリケーションベンダーが既存のインフラストラクチャ（NATを備えたIPv4）で機能することを発表する限り、顧客はIPv6を要求しません。アプリケーションベンダーは、ISPがIPv6を展開しない限り、NATトラバーサルの互換性に投資を集中します。
But most ISPs are not willing to add IPv6 to their current offer at no charge unless incurred investment and operational costs are extremely limited. For this, ISPs that provide router CPEs to their customers have the most favorable conditions: they can upgrade their router CPEs and can operate gateways between their IPv4 infrastructures and the global IPv6 Internet to support IPv6 encapsulation in IPv4. They then need no more routing plans than those that exist on these IPv4 infrastructures.
しかし、ほとんどのISPは、発生した投資と運用コストが非常に限られていない限り、現在のオファーにIPv6を現在のオファーに追加する意思はありません。このため、顧客にルーターCPEを提供するISPには最も有利な条件があります。ルーターCPEをアップグレードでき、IPv4インフラストラクチャとグローバルIPv6インターネット間でゲートウェイを操作してIPv4でのIPv6カプセル化をサポートできます。その後、これらのIPv4インフラストラクチャに存在するルーティングプランよりも多くのルーティングプランを必要としません。
Encapsulation a la 6to4, as specified in [RFC3056], is very close to being sufficient for this: it is simple; it is supported on many platforms including PC-compatible appliances; open-source portable code is available; its stateless nature ensures good scalability.
[RFC3056]で指定されているように、6to4のカプセル化は、これに十分なことに非常に近いです。それは簡単です。PC互換のアプライアンスを含む多くのプラットフォームでサポートされています。オープンソースポータブルコードが利用可能です。そのステートレスの性質は、優れたスケーラビリティを保証します。
There is however a limitation of 6to4 that prevents ISPs from using it to offer full IPv6 unicast connectivity to their customers. While an ISP that deploys 6to4 can guarantee that IPv6 packets outgoing from its customer sites will reach the IPv6 Internet, and also guarantee that packets coming from other 6to4 sites will reach its customer sites, it cannot guarantee that packets from native IPv6 sites will reach them. The problem is that a packet coming from a native IPv6 address needs to traverse, somewhere on its way, a 6to4 relay router to do the required IPv6/IPv4 encapsulation. There is no guarantee that routes toward such a relay exist from everywhere, nor is there a guarantee that all such relays do forward packets toward the complete IPv4 Internet.
ただし、ISPSを使用して顧客に完全なIPv6ユニキャスト接続を提供することを防ぐ6to4の制限があります。6to4を展開するISPは、顧客サイトから発信されるIPv6パケットがIPv6インターネットに到達することを保証し、他の6to4サイトから来るパケットが顧客サイトに到達することを保証しますが、ネイティブIPv6サイトからのパケットがそれらに到達することを保証することはできません。。問題は、ネイティブIPv6アドレスからのパケットが、その途中のどこかで、必要なIPv6/IPv4カプセル化を行うために6to4リレールーターを通過する必要があることです。そのようなリレーへのルートがどこからでも存在するという保証はなく、そのようなすべてのリレーが完全なIPv4インターネットに向かって転送されることを保証することもありません。
Also, if an ISP operates one or several 6to4 relay routers and opens IPv6 routes toward them in the IPv6 Internet, for the 6to4 prefix 2002::/16, it may receive in these relays packets destined to an unknown number of other 6to4 ISPs. If it doesn't forward these packets, it creates a black hole in which packets may be systematically lost, breaking some of the IPv6 connectivity. If it does forward them, it can no longer dimension its 6to4 relay routers in proportion to the traffic of its own customers. Quality of service, at least for customers of other 6to4 ISPs, will then hardly be guaranteed.
また、ISPが1つまたは複数の6to4リレールーターを操作し、IPv6インターネットでIPv6ルートを開くと、6to4プレフィックス2002 ::/16については、他の6to4 ISPの未知の数に運命づけられたこれらのリレーパケットで受信される場合があります。これらのパケットを転送しない場合、パケットが体系的に失われる可能性があるブラックホールが作成され、IPv6接続の一部が破損します。それらを転送すると、自国の顧客のトラフィックに比例して6to4リレールーターを寸法化することはできなくなります。少なくとも他の6to4 ISPの顧客にとっては、サービスの質はほとんど保証されません。
The purpose of 6rd is to slightly modify 6to4 so that:
6番目の目的は、6to4をわずかに変更することです。
1. Packets that, coming from the global Internet, enter 6rd gateways of an ISP are only packets destined to customer sites of this ISP.
1. グローバルなインターネットから来るパケットは、ISPの第6ゲートウェイに入ることで、このISPの顧客サイトに向けられたパケットのみです。
2. All IPv6 packets destined to 6rd customer sites of an ISP, and coming from anywhere else on the IPv6 Internet, traverse a 6rd gateway of this ISP.
2. ISPの第6カスタマーサイトに向けられたすべてのIPv6パケットは、IPv6インターネット上のどこからでも来て、このISPの6番目のゲートウェイを横断します。
The principle of 6rd is that, to build on 6to4 and suppress its limitation, it is sufficient that:
6番目の原則は、6to4に基づいてその制限を抑制するには、次のことで十分であるということです。
1. 6to4 functions are modified to replace the standard 6to4 prefix 2002::/16 by an IPv6 prefix that belongs to the ISP-assigned address space, and to replace the 6to4 anycast address by another anycast address chosen by the ISP.
1. 6TO4関数は、ISPが割り当てられたアドレススペースに属するIPv6プレフィックスに標準の6TO4プレフィックス2002 ::/16を置き換え、ISPが選択した別のAnyCastアドレスに6To4 Anycastアドレスを置き換えるように変更されます。
2. The ISP operates one or several 6rd gateways (upgraded 6to4 routers) at its border between its IPv4 infrastructure and the IPv6 Internet.
2. ISPは、IPv4インフラストラクチャとIPv6インターネットとの境界で、1つまたは複数の6番目のゲートウェイ（6to4ルーターをアップグレード）を操作します。
3. CPEs support IPv6 on their customer-site side and support 6rd (upgraded 6to4 function) on their provider side.
3. CPESは、顧客サイト側でIPv6をサポートし、プロバイダー側で6番目（6to4機能をアップグレード）をサポートします。
Figure 1 shows how the IPv6 prefix of a customer site is derived from its IPv4 address.
図1は、顧客サイトのIPv6プレフィックスがIPv4アドレスからどのように導出されるかを示しています。
+---------------//-------.------------------------------+
| 6rd-relays IPv6 prefix | IPv4 address |
| of the ISP | of the customer site |
+---------------//-------'------------------------------+
<-- less or equal to 32 -><------------ 32 ------------->
<-- less or equal to 64 ------------------------------->
Figure 1: Format of the IPv6 Prefix Assigned to a 6rd Customer Site
図1：第6カスタマーサイトに割り当てられたIPv6プレフィックスの形式
Figure 2 shows which nodes have to be upgraded from 6to4 to 6rd, and which addresses or prefixes have to be routed to them.
図2は、どのノードを6〜4から6番目にアップグレードする必要があるか、どのノードがそれらにルーティングする必要があるかを示しています。
IPv4 AND IPv6 customer site
|
| 6rd CPEs 6rd relays
| (modified 6to4) (modified 6to4)
| | |
| | __________________________ |
| | | | |
| | | ISP IPV4 INFRASTRUCTURE | V GLOBAL
V V | | ___ IPV6
___ | | | | INTERNET
| | | | .-----------------|--| |---
|--| |--|-. / | |___|
| |___| | \ / |
| \ / IPv4 | IPv6 Prefix
| O anycast address => | <= of 6rd relays
| ___ | / \ of 6rd relays | of the ISP
| | | | / \ | ___
|--| |--|-' \ | | |
| |___| | '-----------------|--| |---
| | | |___|
| IPv4 addresses |
| <= of customer sites |
|__________________________|
Figure 2: ISP Architecture to Deploy IPv6 with 6rd
図2：IPv6を6番目に展開するISPアーキテクチャ
NOTE: The chosen address format uses 32 bits of IPv4 addresses in IPv6 addresses for reasons of simplicity and of compatibility with the existing 6to4 code. Limiting initially Free's customer sites to one IPv6 subnet per site, a consequence of Free's initial prefix being a /32, was not a significant restriction: since Free's customers are essentially residential, most of them would have been unable to use several subnets anyway, and as soon as Free would get a prefix shorter than /32, this restriction would be relaxed. If it had been important to immediately use less than 32 bits of IPv4 addresses in IPv6 prefixes, this would have been possible. Since Free, like many ISPs, had several RIR-allocated IPv4 prefixes (6 of them, having lengths from /10 to /16 in the particular case), 6rd gateways and 6rd CPEs could for this have implemented variable-length mapping table. But some of the IPv4 addressing entropy would thus have been extended to 6rd gateways and CPEs. Complexity being then significantly higher, this would have defeated the objective of extreme simplicity to favor actual and rapid deployment.
注：選択されたアドレス形式は、単純さと既存の6to4コードとの互換性のために、IPv6アドレスの32ビットのIPv4アドレスを使用します。最初にFreeの顧客サイトをサイトごとに1つのIPv6サブネットに制限することは、Freeの初期プレフィックスがA /32であることの結果ではありませんでしたが、Freeの顧客は本質的に住宅であるため、ほとんどのサブネットを使用することはできませんでした。Freeが /32より短い接頭辞を取得するとすぐに、この制限は緩和されます。IPv6プレフィックスで32ビット未満のIPv4アドレスをすぐに使用することが重要だった場合、これは可能でした。Freeは、多くのISPと同様に、いくつかのRIRに割り当てられたIPv4プレフィックス（そのうち6つ、特定のケースで /10から /16までの長さ）を持っていたため、6番目のゲートウェイと6番目のCPEが可変長さのマッピングテーブルを実装できました。しかし、エントロピーに対処するIPv4の一部は、6番目のゲートウェイとCPEに拡張されていました。その後、複雑さは大幅に高く、これは、実際の迅速な展開を支持するという極端なシンプルさの目的を打ち負かしていたでしょう。
IPv6 communication between customer sites of a same ISP is direct across the ISP IPv4 infrastructure: when a CPE sees that the IPv6 destination address of an outgoing packet starts with its own 6rd relay ISPv6 prefix, it takes the 32 bits that follow this prefix as IPv4 destination of the encapsulating packet. (Sending and decapsulation rules of 6to4, duly adapted to the 6rd prefix in place of the 6to4 prefix, apply as described in Section 5.3 of [RFC3056].)
同じISPの顧客サイト間のIPv6通信は、ISP IPv4インフラストラクチャ全体に直接的です。CPEが、発信パケットのIPv6宛先アドレスが独自の6番目のリレーISPv6プレフィックスで始まることを確認すると、このプレフィックスに従う32ビットがIPV4として使用されることを確認するとカプセル化パケットの宛先。（6to4の6to4の送信および脱カプセル化ルールは、6to4プレフィックスの代わりに6番目のプレフィックスに正式に適合し、[RFC3056]のセクション5.3に記載されているように適用されます。）
The IPv4 anycast address of 6rd relays may be chosen independently by each ISP. The only constraint is that routes toward the ISP that are advertised must not include this address. For example, Free took a 192.88.99.201 address, routed with the same /24 prefix as 6to4 but with 201 instead of 1 to avoid confusion with 192.88.99.1, the 6to4 anycast address of [RFC3068]. Another possibility, not retained, would have been to use the anycast address of 6to4 and to add, in relays, a test on the IPv6 prefix of the ISP-side address. If it starts with 2002::/16, the packet is 6to4, not 6rd.
第6リレーのIPv4 Anycastアドレスは、各ISPが独立して選択できます。唯一の制約は、宣伝されているISPに向かうルートがこのアドレスを含めてはならないことです。たとえば、Freeは192.88.99.201のアドレスを取りました。これは、同じ /24プレフィックスを6to4とルーティングしますが、192.88.99.1での混乱を避けるために1ではなく201では[RFC3068]の6to4 Anycastアドレスを避けました。保持されていない別の可能性は、6to4のAnycastアドレスを使用し、リレーにISP側のアドレスのIPv6プレフィックスのテストを追加することでした。2002年::/16から始まる場合、パケットは6to4ではなく6to4です。
______________________________
| |
| 10.x.x.x/8 private addresses |
| <== |
<-----| IPv4 anycast address |----->
| of 6rd relays |
6rd-CPEs | ==> | 6rd-relays
| |
<-----| 0.0.0.0/0 |----->
| : |
|______________V_______________|
__|__
ISP-supported NAT(s) | |
|_____|
|
V
IPv4 public addresses
Figure 3: 6rd Applicability to ISPs That Assign IPv4 Private Addresses
図3：IPv4プライベートアドレスを割り当てるISPへの6番目の適用性
Free currently offers a global IPv4 address to each of its subscribers, which ensures that all IPv4-derived prefixes using 6rd are unique. Service providers may no longer have this luxury as available global IPv4 addresses become more and more scarce. This section describes how 6rd could be used by a service provider who cannot provide global IPv4 addresses to each subscriber.
Freeは現在、各サブスクライバーにグローバルIPv4アドレスを提供しています。これにより、6番目を使用したすべてのIPv4由来のプレフィックスが一意であることが保証されています。利用可能なグローバルIPv4アドレスがますます少なくなるため、サービスプロバイダーはこの贅沢をもはや持っていないかもしれません。このセクションでは、各サブスクライバーにグローバルIPv4アドレスを提供できないサービスプロバイダーが6番目をどのように使用できるかについて説明します。
If an ISP has assigned to customer sites addresses of an IPv4 private space of [RFC1918], typically 10.x.x.x addresses, it can also use 6rd to offer IPv6 to these sites.
ISPが[RFC1918]のIPv4プライベートスペースの顧客サイトアドレスに割り当てられている場合、通常10.x.x.xアドレスは、6番目を使用してこれらのサイトにIPv6を提供することもできます。
IPv4 packets that contain IPv6 packets don't go to NATs that this ISP needs to operate in its infrastructure: they go directly to 6rd relays because their destination is the 6rd relay anycast address.
IPv6パケットを含むIPv4パケットは、このISPがインフラストラクチャで動作する必要があるNATに移動しません。宛先が6番目のリレーAnycastアドレスであるため、6番目のリレーに直接移動します。
It can be noted that in this case, the 10.0.0.0/8 prefix is common to all IPv4 addresses of the addressing domain in which 6rd is used. Knowing it, gateways and CPEs could avoid including this constant IPv4 prefix in IPv6 prefixes, and thus reduce to 24 the number of bits of IPv4 addresses that are included in IPv6 prefixes (but this was not applicable to Free).
この場合、10.0.0.0/8のプレフィックスは、6番目が使用されるアドレスドメインのすべてのIPv4アドレスに共通していることに注意してください。GatewaysとCPEは、IPv6プレフィックスにこの定数IPv4プレフィックスを含めることを避けることができ、IPv6プレフィックスに含まれるIPv4アドレスのビット数を24に減らします（ただし、これは無料には適用されませんでした）。
It can also be noted that, if an ISP is large enough to provide service to more IPv4 endpoints than will fit inside a single 10.0.0.0/8 addressing domain, it can configure several such domains, with 6rd-relay IPv6 prefixes specific of each one. Each of these prefixes is then the RIR-allocated ISP prefix followed by a domain identifier chosen by the ISP.
また、ISPが単一の10.0.0.0/8アドレス指定ドメイン内に収まるよりも多くのIPv4エンドポイントにサービスを提供するのに十分な大きさである場合、それぞれに特異的な第6 relay IPv6プレフィックスを使用して、いくつかのそのようなドメインを構成できることに注意してください。一。これらのプレフィックスのそれぞれは、RIRに割り当てられたISPプレフィックスに続いて、ISPによって選択されたドメイン識別子が続きます。
Security considerations for 6to4 are documented in [RFC3964]. With the restriction imposed by 6rd that relays of an ISP deal only with traffic that belongs to that ISP, checks that have to be done become the following:
6to4のセキュリティ上の考慮事項は、[RFC3964]で文書化されています。ISPのリレーがそのISPに属するトラフィックのみを処理する6番目によって課される制限により、行わなければならないチェックは次のとおりです。
o CPE PACKETS TOWARD THE INTERNET: The IPv6 source must be, and the IPv6 destination must not be, a 6rd address of the site.
o インターネットに向かってCPEパケット：IPv6ソースは必要であり、IPv6宛先はサイトの6番目のアドレスである必要はありません。
o RELAY PACKETS TOWARD THE INTERNET: The IPv6 source must be a 6rd address that matches the IPv4 source. The IPv6 destination must not start with the ISP 6rd prefix.
o インターネットに向けてパケットをリレーする：IPv6ソースは、IPv4ソースに一致する6番目のアドレスでなければなりません。IPv6宛先は、ISP 6rdプレフィックスから開始してはなりません。
o CPE PACKETS FROM THE INTERNET: If the IPv4 source is the 6rd-relay's anycast address of the local ISP, the IPv6 source must not be a 6rd address of this ISP. Otherwise, the IPv6 source must be the 6rd address that matches the IPv4 source (is the IPv6 prefix of 6rd relays of the ISP followed by the IPv4 address).
o インターネットからのCPEパケット：IPv4ソースがローカルISPの第6領域のAnycastアドレスである場合、IPv6ソースはこのISPの6番目のアドレスであってはなりません。それ以外の場合、IPv6ソースは、IPv4ソースに一致する6番目のアドレスでなければなりません（ISPの6番目のリレーのIPv6リレーのIPv4アドレスのIPv6プレフィックスです）。
o RELAY PACKETS FROM THE INTERNET: The IPv6 source must not be a 6rd address of the ISP. The IPv4 destination must not be multicast, i.e., must not start with 224/3. The fact that the IPv6 destination starts with the IPv6 prefix of the ISP 6rd relays is ensured by the routing configuration, but may be double-checked.
o インターネットからのリレーパケット：IPv6ソースは、ISPの6番目のアドレスであってはなりません。IPv4宛先はマルチキャストであってはなりません。つまり、224/3から始めてはなりません。IPv6宛先がISP 6rdリレーのIPv6プレフィックスから始まるという事実は、ルーティング構成によって保証されますが、ダブルチェックされる可能性があります。
It remains that where IPv4 address spoofing is possible (IPv4 sites placing unauthorized source addresses in some packets they send), IPv6 address spoofing is also possible, independently of the above precautions.
IPv4アドレススプーフィングが可能である場合（送信するパケットに不正なソースアドレスを配置するIPv4サイト）、上記の予防措置とは無関係にIPv6アドレススプーフィングも可能です。
ISPs that provide CPEs to all their customers need no new number assignment by IANA. Their being allocated an IPv6 prefix by their RIR, /32 or shorter, is sufficient.
すべての顧客にCPEを提供するISPは、IANAによる新しい番号割り当てを必要としません。/32以下のRIRによってIPv6プレフィックスを割り当てるだけで十分です。
For 6rd to be also used in the future by ISPs that let customers have their own CPEs, means to communicate 6rd parameters to these CPEs would be needed. If the IETF specifies such means for this, some number assignment by IANA is likely to be solicited, in a registry to be then defined.
将来、顧客が独自のCPEを持つことができるISPによって将来使用されるためには、これらのCPEに6番目のパラメーターを伝えることが必要です。IETFがこのような手段を指定している場合、IANAによる多数の割り当てが勧誘される可能性が高く、レジストリで定義されます。
The author warmly acknowledges the major contribution of Rani Assaf to 6rd's proven credibility. He readily appreciated 6rd's potential, and made the daring decision to immediately implement it for a very rapid deployment on Free's operational network.
著者は、第6の実証済みの信頼性に対するラニ・アサフの主要な貢献を温かく認めています。彼は第6の可能性をすぐに高く評価し、Freeの運用ネットワークで非常に迅速な展開のためにすぐにそれを実装するという大胆な決定を下しました。
Mark Townsley, Brian Carpenter and Patrick Grossetete have to be thanked for their encouragements, and for their suggestions on how to proceed for 6rd to be known in the IETF.
マーク・タウンズリー、ブライアン・カーペンター、パトリック・グロセテテは、彼らの励ましと、IETFで6番目に進む方法についての提案に感謝しなければなりません。
Acknowledgments are also due to some IPv6 old timers, in particular Laurent Toutain, Francis Dupont, and Alain Durand, who, when the author came as a late novice on IPV6, taught him a few subtleties of the subject. Without them, designing 6rd would probably not have been possible.
謝辞は、IPv6の古いタイマー、特にLaurent Toutain、Francis Dupont、Alain Durandによるものでもあります。それらがなければ、6番目を設計することはおそらく不可能だったでしょう。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] Carpenter、B。およびK. Moore、「IPv4 Cloudsを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[RFC3068] Huitema、C。、「6to4リレールーターのAnycast Prefix」、RFC 3068、2001年6月。
[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004.
[RFC3964] Savola、P。およびC. Patel、「6to4のセキュリティ上の考慮事項」、RFC 3964、2004年12月。
Author's Address
著者の連絡先
Remi Despres RD-IPtech 3 rue du President Wilson Levallois, France
Remi Despres RD-Tipech 3 Rue Du社長Wilson Levallois、フランス
Phone: +33 6 72 74 94 88
EMail: remi.despres@free.fr