Independent Submission R. Despres
Request for Comments: 5569 RD-IPtech
Category: Informational January 2010
ISSN: 2070-1721
IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
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のインフラ上でIPv6の迅速な展開（6rd）は、急速にそれが顧客宅内機器を提供するためのIPv4サイトへのIPv6ユニキャストサービスを展開するサービスプロバイダを有効にするための6to4のメカニズムに基づいて構築します。 6to4のように、それはトランジットIPv4専用のネットワークインフラストラクチャへの順序でのIPv4カプセル化でステートレスIPv6を利用しています。 6to4のとは異なり、6rdサービスプロバイダは、固定の6to4プレフィックスの代わりに、独自のIPv6プレフィックスを使用しています。彼らはそれを活性化することが唯一の条件の下で、ネイティブIPv6を提供している以上1,500,000住宅サイトへの6rd原則への最初の暴露から5週目：サービスプロバイダは、独自のIPv6「迅速な展開」のために、このメカニズムを使用しています。
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 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/rfc5569.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（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.
このドキュメントの発行日に有効な：（trustee.ietf.org/license-info HTTP）この文書では、BCP 78とIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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):
た後6rdアイデア、フランスの大手インターネットサービスプロバイダ（ISP）の簡潔なプレゼンテーションを持っていた、イリアスグループの自由（以下無料）は、たった5週間（11月7日の印象短い遅延で、次のすべてをした月へ11日2007）：
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.（このために利用可能なの6to4コードをアップグレードする）、そのフリーボックスホームゲートウェイのソフトウェアに6rdサポートを追加しました。
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.自分のFreeboxesのダウンロード可能なソフトウェアの新バージョンにより、業務展開を終えました。
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を使用できるようになりました。唯一の条件は、それらのFreeboxesでの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）を提供し、ISPがこれまでのIPv6展開が6rdを可能に劇的に減少し、投資と運用コストを、できる延期していることを示していると報告されている、に決めますもはや待っていません。
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.
物語を完成させるために、無料でIPv6を有効にしていたその顧客サイトのうちの2つを用意月6日2008年に発表し、そのTelesitesアプリケーション（TV上で公開された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).
IPv6の可用性は、（/ 64、サイトプレフィックスが割り当てられた）顧客サイトごとに1つだけのIPv6リンクに2007年12月に制限されましたが。無料のRIRにその成果と計画を詳細に説明した後、顧客ごとの16個のIPv6リンクまで、それから/ 26プレフィックスを取得した後、数ヶ月後に、（/ 60、サイトプレフィックスの割り当てで）可能となりました。
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.
急速にIPv4のに加えて、追加料金なしで、お客様のサイトにIPv6をもたらすためのISPを持つ、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.
カプセル化ラの6to4は、[RFC3056]で指定され、このために十分であることに非常に近いです：それは簡単です。それは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.
顧客に完全なIPv6ユニキャスト接続性を提供するためにそれを使用してからのISPを防ぐの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リレールータを動作させると6to4プレフィックス:: / 16 2002年、IPv6インターネットでそれらに向かってIPv6ルートを開いた場合にも、それは他の6to4のISPの未知数宛てこれらのリレーパケットで受信することもできます。それはこれらのパケットを転送しない場合は、IPv6接続の一部を壊し、パケットが体系的に失われることのできるブラックホールを作成します。それはそれらを転送しない場合、それはもはや、独自の顧客のトラフィックに比例してその6to4リレールータ寸法を記入することはできません。サービスの質は、少なくとも他の6to4のISPの顧客のために、その後、ほとんど保証されません。
The purpose of 6rd is to slightly modify 6to4 so that:
6rdの目的は、わずかようで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.
グローバルなインターネットから、ISPの6rdゲートウェイを入力し、1パケットは、この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.すべてのIPv6パケットは、ISPの6rd顧客サイト宛て、およびIPv6インターネット上のどこからでも来て、このISPの6rdゲートウェイを通過します。
The principle of 6rd is that, to build on 6to4 and suppress its limitation, it is sufficient that:
6rdの原理は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によって選ばれた別のエニーキャストアドレスでの6to4エニーキャストアドレスを交換するように変更されています。
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つまたはいくつかの6rdゲートウェイ（アップグレードの6to4ルータ）を操作します。
3. CPEs support IPv6 on their customer-site side and support 6rd (upgraded 6to4 function) on their provider side.
3.のCPEは、その提供者側の顧客サイト側と支援6rd（アップグレードの6to4機能）でIPv6をサポートしています。
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：6rdカスタマーサイトに割り当てられた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.
図のノードは、6rdへの6to4からアップグレードする必要があり、図2に示すように、そしてどのアドレスまたはプレフィックスがそれらにルーティングする必要があります。
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：ISPアーキテクチャ6rdでIPv6を展開します
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アドレスにIPv4アドレスの32ビットを使用します。無料の顧客は、基本的に居住していることから、それらのほとんどはとにかく複数のサブネットを使用することができなかっただろう、と：重大な制限ではありませんでした、無料の初期接頭辞の結果は、/ 32であること、サイトごとに1つのIPv6サブネットに、最初は無料の顧客サイトを制限しますすぐ無料/ 32よりプレフィックス短くなるだろうと、この制限が緩和されるだろう。それはすぐにIPv6プレフィックスにIPv4アドレスの32ビット以下を使用することが重要であった場合、これは可能だったでしょう。無料のため、多くのISPのように、いくつかのRIRに割り当てられたIPv4プレフィックス（それらの6、特定の場合に/ 10から/ 16を有する長さ）、6rdゲートウェイと6rdのCPEこれを実装している可能性が可変長マッピングテーブルを有していました。しかし、IPv4のアドレス指定のエントロピーのいくつかは、このように6rdゲートウェイとの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宛先アドレスが自身の6rdリレーISPv6プレフィックスで開始することを見るとき、それは、IPv4、このプレフィクスに従う32ビットを取りますカプセル化したパケットの宛先。 （[RFC3056]のセクション5.3で説明したように適用され、正式の6to4プリフィックスの代わりに6rdプレフィックスに適合し、6to4の規則を送信し、デカプセル化）。
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.
6rdリレーのIPv4のエニーキャストアドレスは、各ISPによって独立に選択されてもよいです。唯一の制約は、公示されているISPに向けた経路は、このアドレスを含めることはできませんということです。例えば、フリーは、6to4と同じ/ 24接頭辞でルーティング192.88.99.201アドレスを取ったが、201の代わりに、1と、192.88.99.1と[RFC3068]のの6to4エニーキャストアドレスを混乱を避けるために。別の可能性は、保持されていない、の6to4のエニーキャストアドレスを使用すると、ISP側のアドレスのIPv6プレフィックスに、リレーでは、テストを追加することであっただろう。それは2002 :: / 16で始まっている場合、パケットは、6to4、ない6rdです。
______________________________
| |
| 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
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.
フリーは現在、6rdを使用しているすべてのIPv4由来のプレフィックスが一意であることが保証され、その加入者のそれぞれにグローバルIPv4アドレスを提供しています。可能なグローバルIPv4アドレスがますます不足してサービスプロバイダは、もはやこの贅沢を持っていないかもしれません。このセクションでは、6rdは、各加入者にグローバルIPv4アドレスを提供できないサービスプロバイダによって使用できる方法を説明します。
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アドレスが割り当てられている場合、それはまた、これらのサイトにIPv6を提供するために6rd使用することができます。
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に行っていない。その先は6rdリレーエニーキャストアドレスであるため、彼らは、6rdリレーに直接アクセスしてください。
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プレフィックスが6rdが使用されているアドレス指定のドメインのすべてのIPv4アドレスに共通であることに注目することができます。それを知って、ゲートウェイとのCPEはIPv6プレフィックスでこの定数のIPv4プレフィックスを含む避けるため、（これは無料には適用されませんでした）24にIPv6プレフィックスに含まれているIPv4アドレスのビット数を減らすことができます。
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エンドポイントにサービスを提供するのに十分な大きさであれば、それはIPv6がそれぞれの特定の接頭辞6rd-リレーにはいくつかのこのようなドメインを設定することができ、ことに留意されたいです1。これらのプレフィックスの各々は、次に、ISPによって選択されたドメイン識別子に続くRIR割り当て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の契約のリレー、次のようになって行われなければならチェックしていること6rdによって課されると
o CPE PACKETS TOWARD THE INTERNET: The IPv6 source must be, and the IPv6 destination must not be, a 6rd address of the site.
インターネットをめざしCPE PACKETS○：IPv6ソースでなければならない、とIPv6宛先は、サイトの6rdアドレスであってはなりません。
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 RELAYパケットがインターネット向けて：IPv6ソースは、IPv4ソースと一致6rdアドレスでなければなりません。 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).
インターネットからのCPE PACKETS O：IPv4ソースはローカルISPの6rd-リレーのエニーキャストアドレスである場合は、IPv6ソースは、このISPの6rdアドレスであってはなりません。そうでなければ、IPv6ソースは、IPv4ソース（ISPの6rdリレーのIPv6プレフィックスは、IPv4アドレスが続く）と一致6rdアドレスでなければなりません。
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の6rdアドレスであってはなりません。 IPv4宛先は3分の224で開始してはならない、すなわち、マルチキャストであってはなりません。 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.
これは、独立して上記の事項に、IPv6アドレスの詐称も可能である、（IPv4のサイトは、彼らが送る、いくつかのパケットに不正な送信元アドレスを置く）IPv4アドレスのなりすましが可能であることに変わりはないところ。
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.
6rdはまた、顧客が自分のCPEを持ってみましょうISPが、将来的に使用されるためには、これらのCPEへの6rdのパラメータが必要になるの通信を意味します。 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.
著者は暖かく6rdの実証済みの信頼性へのラニアサフの主要な貢献を認めています。彼は容易に6rdの可能性を高く評価し、そしてすぐに無料の運用ネットワーク上の非常に迅速な展開のためにそれを実装するための大胆な決断を下しました。
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.
マークTownsley、ブライアン・カーペンターとパトリックGrosseteteは彼らの励ましのために感謝し、IETFで知られるように6rdを進行する方法についての彼らの提案をする必要があります。
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の後半初心者として来て、特定のローランToutain、フランシスデュポン、とアラン・デュラン、で、彼の主題のいくつかの微妙な違いを教え、また、いくつかのIPv6古いタイマーによるものです。それらがなければ、設計6rdはおそらく不可能でした。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B.およびK.ムーア、RFC 3056、2001年2月 "のIPv4クラウドを介したIPv6ドメインの接続"。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、 "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.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[RFC3068]のHuitema、C.、 "6to4のリレールーターのエニーキャストプレフィックス"、RFC 3068、2001年6月。
[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004.
[RFC3964] Savola、P.とC.パテル、 "6to4のためのセキュリティの考慮事項"、RFC 3964、2004年12月。
Author's Address
著者のアドレス
Remi Despres RD-IPtech 3 rue du President Wilson Levallois, France
レミ・デプレRD IPtech 3 RUEデュウィルソン大統領、ルヴァロワ、フランス
Phone: +33 6 72 74 94 88 EMail: remi.despres@free.fr
電話：+33 6 72 74 94 88 Eメール：remi.despres@free.fr