Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 6343 Univ. of Auckland
Category: Informational August 2011
ISSN: 2070-1721
Advisory Guidelines for 6to4 Deployment
Abstract
抽象
This document provides advice to network operators about deployment of the 6to4 technique for automatic tunneling of IPv6 over IPv4. It is principally addressed to Internet Service Providers (ISPs), including those that do not yet support IPv6, and to Content Providers. Some advice to implementers is also included. The intention of the advice is to minimize both user dissatisfaction and help-desk calls.
この文書では、IPv4経由のIPv6の自動トンネリング用の6to4技術の展開について、ネットワークオペレータへのアドバイスを提供します。これは主に、まだIPv6をサポートしていないものを含め、インターネットサービスプロバイダ（ISP）に、およびコンテンツプロバイダにアドレス指定されています。実装者へのアドバイスも含まれています。アドバイスの意図は、ユーザーの不満やヘルプデスクコールの両方を最小限に抑えることです。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc6343.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6343で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
2. Principles of Operation .........................................3
2.1. Router 6to4 ................................................3
2.2. Anycast 6to4 ...............................................4
3. Problems Observed ...............................................5
4. Advisory Guidelines ............................................10
4.1. Vendor Issues .............................................10
4.2. Consumer ISPs, and Enterprise Networks, That Do
Not Support IPv6 in Any Way ...............................11
4.2.1. Anycast Address Availability .......................11
4.2.2. Protocol 41 ........................................11
4.2.3. IPv4 Prefix Issues .................................12
4.2.4. DNS Issues .........................................12
4.2.5. Rogue Router Advertisements ........................12
4.2.6. Planning for IPv6 Deployment .......................13
4.3. Consumer ISPs, and Enterprise Networks, That Do
Support IPv6 ..............................................13
4.4. Transit ISPs and Internet Exchange Points .................14
4.5. Content Providers and Their ISPs ..........................15
5. Tunnels Managed by ISPs ........................................17
6. Security Considerations ........................................17
7. Acknowledgements ...............................................18
8. References .....................................................18
8.1. Normative References ......................................18
8.2. Informative References ....................................18
A technique for automatic tunneling of IPv6 over IPv4, intended for situations where a user may wish to access IPv6-based services via a network that does not support IPv6, was defined a number of years ago. It is known as 6to4 [RFC3056] [RFC3068] and is quite widely deployed in end systems, especially desktop and laptop computers. Also, 6to4 is supported in a number of popular models of CPE routers, some of which have it enabled by default, leading to quite widespread unintentional deployment by end users.
ユーザーがIPv6をサポートしていないネットワークを経由してIPv6ベースのサービスにアクセスすることを望むかもしれない状況のために意図されたIPv4経由のIPv6の自動トンネリング技術は、数年前に定義されました。これは、6to4の[RFC3056] [RFC3068]として知られており、かなり広くエンドシステム、特にデスクトップおよびラップトップコンピュータに展開されます。また、6to4のは、エンドユーザーによってかなり広範囲の意図しない展開につながる、それがデフォルトで有効になっているそのうちのいくつかはCPEルータの人気モデルの数でサポートされています。
Unfortunately, experience shows that the method has some problems in current deployments that can lead to connectivity failures. These failures cause either long retry delays or complete failures for users trying to connect to services. In many cases, the user may be quite unaware that 6to4 is in use; when the user contacts a help desk, in all probability the help desk is unable to correctly diagnose the problem. Anecdotally, many help desks simply advise users to disable IPv6, thus defeating the whole purpose of the mechanism, which was to encourage early adoption of IPv6.
残念ながら、経験が方法が接続障害につながることができ、現在の展開でいくつかの問題を持っていることを示しています。これらの障害は、どちらか長いサービスに接続しようとするユーザーのための遅延または完全な失敗を再試行する原因となります。多くの場合、利用者は、6to4が使用中であることは非常に気づかないかもしれ。ときに、ユーザーの連絡先ヘルプデスクは、すべての確率でヘルプデスクが正しく問題を診断することができません。ちなみに、多くのヘルプデスクは、単純にこれのIPv6の早期適用を奨励することでしたメカニズムの全体の目的を破って、IPv6を無効にするには、利用者に助言します。
The main goal of the present document is to offer advice to network operators on how to deal with this situation more constructively than by disabling 6to4. It briefly describes the principle of operation, then describes the problems observed, and finally offers specific advice on the available methods of avoiding the problems. Note that some of this advice applies to ISPs that do not yet support IPv6, since their customers and help desks are significantly affected in any case.
本書の主な目標は、6to4を無効にすることで、より建設的よりも、このような状況に対処する方法でネットワーク事業者にアドバイスを提供することです。これは、簡単に、その後観察の問題を説明し、動作原理を説明し、最後に問題を回避するための利用可能な方法について具体的なアドバイスを提供しています。このアドバイスのいくつかは、顧客やヘルプデスクが大幅にどのような場合に影響を受けるため、まだ、IPv6をサポートしていないISPに適用されることに注意してください。
Other advice applies to content providers and implementers, but this document does not discuss aspects that are mainly outside the scope of network operators:
その他のアドバイスは、コンテンツプロバイダや実装に適用されますが、この文書は、ネットワーク事業者の範囲外で主に側面を議論していません。
1. Operating system preferences between IPv4 and IPv6 when both appear to be available [RFC3484-REVISE].
IPv4とIPv6との間の1オペレーティングシステム環境の両方が[RFC3484-REVISE]使用可能であるように見える場合。
2. Ensuring that application software deals gracefully with connectivity problems [EYEBALLS-IPV6].
2.接続の問題[眼球-IPV6]で優雅にそのアプリケーションソフトウェアのお得な情報を確保。
3. Some content providers have chosen to avoid the problem by hiding their IPv6 address except from customers of pre-qualified networks [DNSWHITE].
3.一部のコンテンツプロバイダは、事前に資格のネットワーク[DNSWHITE]の顧客から除き、そのIPv6アドレスを非表示にすることで問題を回避することを選択しました。
A companion document [HISTORIC] proposes to reclassify 6to4 as Historic. However, this will not remove the millions of existing hosts and CPEs that implement 6to4. Hence, the advice in this document remains necessary.
[名所旧跡]コンパニオン文書は歴史としての6to4を再分類することを提案しています。しかし、これは既存のホストと6to4を実装CPEの何百万も削除されません。したがって、この文書のアドバイスが必要なまま。
There are two variants of 6to4 that are referred to here as "Router 6to4" and "Anycast 6to4". To understand Anycast 6to4, it is necessary first to understand Router 6to4.
「ルータの6to4」と「エニーキャスト6to4の」とここで呼ばれているの6to4の二つの変種があります。エニーキャスト6to4のを理解するには、ルータの6to4を理解するために必要な最初のものです。
Router 6to4 is the original version, documented in [RFC3056]. The model assumes that a user site operates native IPv6, but that its ISP provides no IPv6 service. The site border router acts as a 6to4 router. If its external global 32-bit IPv4 address is V4ADDR, the site automatically inherits the IPv6 prefix 2002:V4ADDR::/48. (The explanation in RFC 3056 is somewhat confusing, as it refers to the obsolete "Top Level Aggregator" terminology.) The prefix 2002: V4ADDR::/48 will be used and delegated for IPv6 service within the user site.
ルータの6to4は、[RFC3056]に記載され、元のバージョンです。モデルは、ユーザのサイトがネイティブIPv6を動作することを前提としていますが、そのISPにはIPv6サービスを提供していないこと。サイトの境界ルータは、6to4ルーターとして機能します。 V4ADDR :: / 48：その外部グローバル32ビットのIPv4アドレスがV4ADDRであれば、サイトが自動的にIPv6プレフィックス2002を継承します。 （それは時代遅れ「トップレベルアグリゲータ」の用語を指すRFC 3056での説明は、やや混乱しています。）接頭辞2002：V4ADDR :: / 48を使用し、ユーザサイト内のIPv6サービスのために委任されます。
Consider two such site border routers, with global IPv4 addresses 192.0.2.170 and 192.0.2.187, and that therefore inherit the IPv6 prefixes 2002:c000:2aa::/48 and 2002:c000:2bb::/48, respectively. The routers can exchange IPv6 packets by encapsulating them in IPv4 using protocol number 41, and sending them to each other at their respective IPv4 addresses. In fact, any number of 6to4 routers connected to the IPv4 network can directly exchange IPv6 packets in this way.
グローバルIPv4のは192.0.2.170と192.0.2.187に対処して、二つのそのようなサイトの境界ルータを考えてみましょう、そしてそれは、したがって、IPv6が2002接頭辞継承：C000：2AA :: / 48と2002：C000：2BB :: / 48、それぞれ。ルータは、プロトコル番号41を使用して、IPv4のそれらをカプセル化し、それらのそれぞれのIPv4アドレスでお互いにそれらを送信することによって、IPv6パケットを交換することができます。実際には、IPv4ネットワークに接続された6to4ルータの任意の数は、直接このようにしてIPv6パケットを交換することができます。
Some 6to4 routers are also configured as "relay routers". They behave as just described, but, in addition, they obtain native IPv6 connectivity with a normal IPv6 prefix. They announce an IPv6 route to 2002::/16. For example, assume that the 6to4 router at 192.0.2.187 is a relay router, whose address on the 6to4 side is 2002:c000:2bb::1. Suppose that a host with the 6to4 address 2002: c000:2aa::123 sends an IPv6 packet to a native IPv6 destination such as 2001:db8:123:456::321. Assume that the 6to4 router at 192.0.2.170 has its IPv6 default route set to 2002:c000:2bb::1, i.e., the relay. The packet will be delivered to the relay, encapsulated in IPv4. The relay will decapsulate the packet and forward it into native IPv6 for delivery. When the remote host replies, the packet (source 2001:db8: 123:456::321, destination 2002:c000:2aa::123) will find a route to 2002::/16, and hence be delivered to a 6to4 relay. The process will be reversed and the packet will be encapsulated and forwarded to the 6to4 router at 192.0.2.170 for final delivery.
いくつかの6to4ルーターは、「中継ルータ」として設定されています。彼らはさらに、彼らは通常のIPv6プレフィックスを持つネイティブIPv6接続を得る、など今説明振る舞うが、。彼らは2002 :: / 16にIPv6ルートを発表します。 C000：2BB :: 1たとえば、192.0.2.187の6to4ルーターは、そのアドレスの6to4側で2002ある中継ルータであることを前提としています。仮定している6to4アドレス2002を持つホスト：C000：2AA :: 123は、2001などのネイティブIPv6宛先にIPv6パケットを送信します：DB8：123：456 :: 321。 C000：2BB :: 1、すなわち、リレー192.0.2.170の6to4ルーターは、2002年に設定されたIPv6デフォルトルートを持っていることを前提としています。パケットは、IPv4でカプセル化され、リレーに配信されます。リレーは、パケットをデカプセル化し、配信のためにネイティブIPv6にそれを転送します。ときにリモートホスト応答パケット（ソース2001：DB8：123：456 :: 321、宛先：2002 C000：2AA :: 123）2002 :: / 16へのルートを見つける、従って6to4リレーに送達すること。プロセスは逆転され、パケットがカプセル化され、最終的な送達のために192.0.2.170で6to4ルーターに転送されます。
Note that this process does not require the same relay to be used in both directions. The outbound packet will go to whichever relay is configured as the default IPv6 router at the source router, and the return packet will go to whichever relay is announcing a route to 2002::/16 in the vicinity of the remote IPv6 host.
このプロセスは両方向で使用されるように同じリレーを必要としないことに注意してください。アウトバウンドパケットは、ソースルータでデフォルトIPv6ルータとして設定されている方のリレーに行きますと、リレーは、リモートIPv6ホストの近くに2002 :: / 16へのルートを発表された方に戻りパケットが行きます。
Of course, there are many further details in RFC 3056, most of which are irrelevant to current operational problems.
もちろん、現在の操作上の問題とは無関係ですほとんどがRFC 3056には多くの更なる詳細は、あります。
Router 6to4 assumes that 6to4 routers and relays will be managed and configured cooperatively. In particular, 6to4 sites need to configure a relay router willing to carry their outbound traffic, which becomes their default IPv6 router (except for 2002::/16). The objective of the anycast variant, defined in [RFC3068], is to avoid any need for such configuration. The intention was to make the solution available for small or domestic users, even those with a single host or simple home gateway rather than a border router. This is achieved quite simply, by defining 192.88.99.1 as the default IPv4 address for a 6to4 relay, and therefore 2002:c058:6301:: as the default IPv6 router address for a 6to4 site.
ルーターの6to4は、6to4ルーターとリレーが管理し、協調的に設定されることを前提としています。具体的には、6to4サイトは（2002 :: / 16を除く）は、デフォルトのIPv6ルータになり自分のアウトバウンドトラフィックを運ぶために喜んでリレールータを設定する必要があります。 [RFC3068]で定義されたエニーキャスト変異体の目的は、このような構成の必要性を回避することです。意図はさえも、単一のホストまたは単純なホームゲートウェイではなく、境界ルータと、小規模または国内のユーザーのためのソリューションを利用できるようにしました。これは、6to4リレーのデフォルトのIPv4アドレスとして192.88.99.1を定義することによって、非常に簡単に達成され、したがって、2002：C058：6301 :: 6to4サイトのデフォルトのIPv6ルータアドレスなど。
Since Anycast 6to4 implies a default configuration for the user site, it does not require any particular user action. It does require an IPv4 anycast route to be in place to a relay at 192.88.99.1. As with Router 6to4, there is no requirement that the return path goes through the same relay.
エニーキャスト6to4のは、ユーザーのサイトのデフォルト設定を意味しているので、それは、特定のユーザーアクションを必要としません。これは、192.88.99.1でリレーに場所にあるとのIPv4エニーキャストルートを必要としません。ルータの6to4と同じように、リターンパスが同じリレーを経由する必要はありません。
It should be noted that Router 6to4 was not designed to be an unmanaged solution. Quite the contrary: RFC 3056 contains a number of operational recommendations intended to avoid routing issues. In practice, there are few if any deployments of Router 6to4 following these recommendations. Mostly, Anycast 6to4 has been deployed. In this case, the user site (either a single host or a small broadband gateway) discovers that it doesn't have native IPv6 connectivity, but that it does have a global IPv4 address and can resolve AAAA queries. Therefore, it assumes that it can send 6to4 packets to 192.88.99.1.
ルーターの6to4は、非管理ソリューションであるように設計されていなかったことに留意すべきです。それどころか：RFC 3056には、ルーティングの問題を回避するための操作勧告の数が含まれています。ルータの6to4のいずれかの展開がこれらの推奨事項を以下の場合は実際には、いくつかあります。ほとんどの場合、エニーキャスト6to4のは展開されています。この場合、ユーザサイト（単一ホストまたは小さなブロードバンドゲートウェイのいずれか）は、ネイティブIPv6接続がないことを発見し、それがグローバルIPv4アドレスを持っているし、AAAAクエリを解決できること。したがって、それは192.88.99.1への6to4パケットを送信できることを前提としています。
Empirically, 6to4 appears to suffer from a significant level of connection failure; see [Aben] and [Huston-a]. In experiments conducted on a number of dual-stack web servers, the TCP connection failure rate has been measured. In these experiments, the client's connection attempt to a server was considered to have failed when the server received a TCP SYN packet and sent a SYN/ACK packet in response, but received no ACK packet to complete the initial TCP three-way handshake. The experiment conducted by Aben recorded a failure rate of between 9% and 20% of all 6to4 connection attempts. The experiment conducted by Huston has recorded a failure rate of between 9% and 19% of all 6to4 clients. In this latter experiment, it was further noted that between 65% to 80% of all 6to4 clients who failed to connect using 6to4 were able to make a successful connection using IPv4, while the remainder did not make any form of IPv4 connection attempt, successful or otherwise, using the mapped IPv4 address as a source address. No connection attempts using embedded RFC 1918 IPv4 addresses were recorded by the server.
経験的には、6to4のは、接続障害の有意水準に苦しむように見えます。 [アーベン]を参照し、[ヒューストン-A]。デュアルスタックWebサーバの数に行われた実験では、TCP接続の失敗率が測定されています。これらの実験では、サーバーへのクライアントの接続試行は、サーバーがTCP SYNパケットを受信し、それに応答してSYN / ACKパケットを送信しますが、初期TCP 3ウェイハンドシェイクを完了するために、何のACKパケットを受信しない場合に失敗したと考えられました。アーベンによって実験は9％との6to4全ての接続試行の20％との間の不良率を記録しました。ヒューストンによって実験は9％との6to4全てのクライアントの19％との間の不良率を記録しました。この後者の実験では、残りは成功した、IPv4接続試行の任意のフォームを作成しなかったの6to4を使用して接続に失敗したすべての6to4クライアントの間で65％から80％が、IPv4を使用して成功した接続を行うことができたことにさらに注目されましたまたはそうでなければ、送信元アドレスとしてマッピングされたIPv4アドレスを使用して。埋め込まれたRFC 1918 IPv4アドレスを使用しませ接続試行はサーバーによって記録されませんでした。
There have been several possible reasons offered for this form of 6to4 connection failure. One is the use of private IPv4 addresses embedded in the 6to4 address, making the return path for the 6to4 tunnel infeasible, and the second is the use of local filters and firewalls that drop incoming IP packets that use IP protocol 41. If the former case were prevalent, it would be reasonable to expect that a significant proportion of failed 6to4 connections would use embedded IPv4 addresses that are either drawn from the private use (RFC 1918) address ranges, contrary to RFC 3056, or from addresses that are not announced in the Internet's IPv4 inter-domain routing table. Neither case was observed to any significant volume in the experiments conducted by Huston. Furthermore, the experimental conditions were varied to use a return 6to4 tunnel with either the native IPv4 source address of the dual-stack server or an IPv4 source address of 192.88.99.1. No change in the 6to4 connection failure rate was observed between these two configurations; however, other operators have reported significant problems when replying from the native address, caused by stateful firewalls at the user site. Given that the server used its own 6to4 relay for the return path, the only difference in the IP packet itself between the successful IPv4 connections and the failed 6to4 connections was the IP protocol number, which was 6 (TCP) for the successful IPv4 connections and 41 (IPv6 payload) for the failed 6to4 connections. The inference from these experiments is that one likely reason for the high connection failure rate for 6to4 connections is the use of local filters close to the end user that block incoming packets with protocol 41, in some cases made worse by stateful firewalls if the source address is not 192.88.99.1.
6to4の接続障害のこのフォームのために提供、いくつかの可能な理由がありました。一つは、実行不可能6to4トンネルのためのリターンパスを作り、6to4アドレスに埋め込まれたプライベートIPv4アドレスを使用することであり、第二は、前者の場合ならばIPプロトコル41を使用して、着信IPパケットをドロップするローカルフィルタとファイアウォールの使用であります流行だった、失敗したの6to4接続のかなりの割合が、いずれかの私的使用RFC 3056に反し、またはに発表されていないアドレスから（RFC 1918）のアドレス範囲から描かれて埋め込まれたIPv4アドレスを使用するだろうと予想するのが妥当だろうインターネットのIPv4ドメイン間ルーティングテーブル。どちらの場合は、ヒューストンで行われた実験の大幅なボリュームに観察されました。さらに、実験条件は、デュアルスタックサーバのネイティブIPv4ソースアドレスまたは192.88.99.1のIPv4ソースアドレスのいずれかと戻り6to4トンネルを使用するように変化させました。 6to4の接続不良率の変化は、これらの二つの構成の間で観察されませんでした。ユーザサイトでのステートフルファイアウォールによって引き起こされるネイティブのアドレスから返信するときしかし、他の事業者は重大な問題を報告しています。サーバはリターンパスの独自の6to4リレーを使用することを考えると、成功したIPv4接続と失敗の6to4接続間のIPパケット自体の唯一の違いは、成功したIPv4接続のために6（TCP）であったIPプロトコル番号、たと失敗した6to4の接続のための41（IPv6のペイロード）。これらの実験からの推論は6to4の接続のための高い接続の失敗率は、送信元アドレス場合は、ステートフルファイアウォールによって悪化し、いくつかの例では、プロトコル41で着信パケットをブロックするエンドユーザーに近いローカルフィルタの使用であるため、1つの可能性が高い理由であります192.88.99.1ではありません。
In a dual-stack context, this connection failure rate was effectively masked by the ability of the client system to recover from the failure and make a successful connection using IPv4. In this case, the only effect on the client system was a delay in making the connection of between 7 and 20 seconds as the client's system timed out on the 6to4 connection attempts (see [EYEBALLS-IPV6]).
デュアルスタック文脈では、この接続の失敗率を効果的に障害から回復し、IPv4を使用して成功した接続を行うために、クライアントシステムの能力によってマスクされました。この場合、クライアントシステム上でのみ効果がクライアントのシステムとして7〜20秒の接続を行う際に遅延が6to4の接続試行にタイムアウトした（参照[眼球-IPV6]）。
This experience, and further analysis, shows that specific operational problems with Anycast 6to4 include:
この経験、そしてさらなる分析は、エニーキャストの6to4で特定の操作上の問題が含まれていることを示しています。
1. Outbound Black Hole: 192.88.99.1 does not generate 'destination unreachable' but in fact packets sent to that address are dropped. This can happen due to routing or firewall configuration, or even because the relay that the packets happen to reach contains an ACL such that they are discarded.
1.アウトバウンドブラックホール：192.88.99.1が「到達不能先」を生成しませんが、実際にそのアドレスに送信されたパケットがドロップされます。これは、ルーティングやファイアウォールの設定に起こることができ、またはパケットが到達するために起こることを、リレーは、それらが破棄されるようにACLが含まれていてもいるので。
This class of problem arises because the user's ISP is accepting
a route to 192.88.99.0/24 despite the fact that it doesn't go
anywhere useful. Either the user site or its ISP is dropping
outbound protocol 41 traffic, or the upstream operator is
unwilling to accept incoming 6to4 packets from the user's ISP.
The latter is superficially compatible with the design of Router
6to4 (referred to as "unwilling to relay" in RFC 3056). However,
the simple fact of announcing a route to 192.88.99.0/24 in IPv4,
coupled with the behavior described in RFC 3068, amounts to
announcing a default route for IPv6 to all 6to4 sites that
receive the IPv4 route. This violates the assumptions of RFC
3056.
The effect of this problem on users is that their IPv6 stack believes that it has 6to4 connectivity, but in fact all outgoing IPv6 packets are black-holed. The prevalence of this problem is hard to measure, since the resulting IPv6 packets can never be observed from the outside.
ユーザーにこの問題の影響は彼らのIPv6スタックがそれを6to4接続性を有していると考えているということですが、実際には、すべての発信IPv6パケットはブラックホールです。その結果IPv6パケットを外部から観察することはできませんので、この問題の有病率は、測定することは困難です。
2. Inbound Black Hole: In this case, 6to4 packets sent to 192.88.99.1 are correctly delivered to a 6to4 relay, and reply packets are returned, but they are dropped by an inbound protocol 41 filter. As far as the user is concerned, the effect is the same as the previous case: IPv6 is a black hole. Many enterprise networks are believed to be set up in this way. Connection attempts due to this case can be observed by IPv6 server operators, in the form of SYN packets from addresses in 2002::/16 followed by no response to the resulting SYN/ACK. From the experiments cited above, this appears to be a significant problem in practice.
2.インバウンドブラックホール：この場合には、192.88.99.1に送信された6to4パケットが正しく6to4リレーに配信され、および応答パケットが返されますが、それらは、インバウンドプロトコル41フィルタによってドロップされます。ユーザに関する限り、効果は、前述の場合と同じである：IPv6はブラックホールです。多くの企業ネットワークは、このように設定していると考えられています。この場合による接続試みは、2002年にアドレスからのSYNパケットの形で、IPv6のサーバのオペレータによって観察することができる:: / 16は、得られたSYN / ACKに対する応答が続きます。上に引用した実験から、これは実際には重大な問題であるように思われます。
This problem is complicated by three variables: the firewall
applying the protocol 41 filter may be stateless or stateful; the
relay may source its packets from its native IPv4 address or from
192.88.99.1; packets from the relay may be subject to IPv4
ingress filtering. If the protocol 41 filter is stateless, 6to4
will never succeed. If it is stateful, the firewall will drop
inbound packets from addresses that have not been seen in
outbound traffic on the same port. In this case, 6to4 will only
succeed if the packets are sourced from 192.88.99.1. If the
relay is subject to ingress filtering, only packets from its
native IPv4 address can be transmitted. Therefore, there are
only three combinations that can succeed:
1. No protocol 41 filter, with the relay using its native IPv4 source address.
1.その天然のIPv4ソースアドレスを使用してリレーとはプロトコル41フィルタ、。
2. No protocol 41 filter, with the relay using the anycast IPv4 source address and with no ingress filter.
2.エニーキャストIPv4ソースアドレスを使用してリレーとなし入力フィルタとはプロトコル41フィルタ、。
3. A stateful protocol 41 firewall, with the relay using the anycast IPv4 source address and with no ingress filter.
3.ステートフルプロトコル41ファイアウォール、エニーキャストIPv4ソースアドレスを使用してリレーとなし入口フィルター付き。
3. No Return Relay: If the Outbound Black Hole problem does not occur, i.e., the outgoing packet does reach the intended native IPv6 destination, the target system will send a reply packet, to 2002:c000:2aa::123 in our example above. Then, 2002::/16 may or may not be successfully routed. If it is not routed, the packet will be dropped (hopefully, with 'destination unreachable'). According to RFC 3056, an unwilling relay "MUST NOT advertise any 2002:: routing prefix into the native IPv6 domain"; therefore, conversely, if this prefix is advertised the relay must relay packets regardless of source and destination. However, in practice, the problem arises that some relays reject packets that they should relay, based on their IPv6 source address.
3.ノーリターンリレー：アウトバウンドブラックホールの問題が発生しない場合、すなわち、意図したネイティブIPv6宛先に到達ん発信パケットは、ターゲットシステムは、2002年に、応答パケットを送信します：C000：私たちの例では2AA :: 123上記。その後、2002 :: / 16は、または正常にルーティングしてもしなくてもよいです。それが配線されていない場合は、パケットが（「到達できない送信先」で、うまくいけば）削除されます。 RFC 3056によると、不本意リレーは、「ネイティブのIPv6ドメインに任意の2002 ::ルーティングプレフィックスを通知てはなりません」。従って、逆に、このプレフィクスがアドバタイズされた場合、リレーは関係なく、送信元と宛先のパケットを中継しなければなりません。しかし、実際には、問題は、一部のリレーが、彼らは彼らのIPv6ソースアドレスに基づいて、リレーすべきパケットを拒否することを生じます。
Whether the native IPv6 destination has no route to 2002::/16 or
it turns out to have a route to an unwilling relay, the effect is
the same: all return IPv6 packets are black-holed. While there
is no direct evidence of the prevalence of this problem, it
certainly exists in practice.
4. Large RTT: In the event that none of the above three problems applies, and a two-way path does in fact exist between a 6to4 host and a native host, the round-trip time may be quite large and variable since the paths to the two relays are unmanaged and may be complex. Overloaded relays might also cause highly variable RTT.
4.大RTT：上記の3つの問題のいずれも適用されない、との6to4ホストとネイティブホストの間に存在する双方向のパスは、実際には、ラウンドトリップ時間がパスするので非常に大きく且つ可変であってもよいないした場合には2つのリレーへの管理対象外であり、複雑です。オーバーロードリレーはまた、非常に多様RTTを引き起こす可能性があります。
5. PMTUD Failure: A common link MTU size observed on the Internet today is 1500 bytes. However, when using 6to4, the path MTU is less than this due to the encapsulation header. Thus, a 6to4 client will normally see a link MTU that is less than 1500, but a native IPv6 server will see 1500. It has been observed that Path MTU Discovery (PMTUD) does not always work, and this can lead to connectivity failures. Even if a TCP SYN/ACK exchange works, TCP packets with full-size payloads may simply be lost. This problem is apparently exacerbated in some cases by failure of the TCP Maximum Segment Size (MSS) negotiation mechanism [RFC2923]. These failures are disconcerting even to an informed user, since a standard 'ping' from the client to the server will succeed, because it generates small packets, and the successful SYN/ACK exchange can be traced. Also, the failure may occur on some paths but not others, so a user may be able to fetch web pages from one site, but only ping another.
5. PMTUDの失敗：今日、インターネット上で観測され、共通のリンクMTUサイズは1500バイトです。 6to4を使用する場合しかし、パスMTUは、カプセル化ヘッダに起因この未満です。したがって、6to4のクライアントは、通常は1500未満のリンクMTUが表示されますが、ネイティブIPv6サーバが表示されます1500それはそのパスMTUディスカバリ（PMTUD）が観察されている、常に動作しません、これは接続障害につながることができます。 TCP SYN / ACK交換が動作する場合でも、フルサイズのペイロードを持つTCPパケットは、単純に失われる可能性があります。この問題は、明らかTCP最大セグメントサイズ（MSS）ネゴシエーションメカニズム[RFC2923]の失敗により、いくつかのケースでは悪化します。クライアントからサーバーへの標準「のping」は成功するので、それは小さなパケットを生成するので、これらの障害は、情報に基づいたユーザーにも、当惑され、成功したSYN / ACK交換をトレースすることができます。また、障害が一部のパスではなく、他人に発生する可能性がありますので、ユーザは、1つのサイトからWebページを取得することができるかもしれませんが、唯一の他にpingを実行します。
Additionally, there is a problem if 6to4 is enabled on a router
and it advertises the resulting prefix on a LAN, but does not
also advertise a smaller MTU; in this case, TCP MSS negotiation
will definitely fail.
6. Reverse DNS Failure: Typically, a 6to4-addressed host will not have a reverse DNS delegation. If reverse DNS is used as a pseudo-security check, it will fail.
6.リバースDNSの失敗：一般的に、6to4のアドレス指定ホストは逆引きDNS委任を持っていません。リバースDNSは、擬似セキュリティチェックとして使用されている場合、それは失敗します。
7. Bogus Address Failure: By design, 6to4 does not work and will not activate itself if the available V4ADDR is a private address [RFC1918]. However, it will also not work if the available V4ADDR is a "bogon", i.e., a global address that is being used by the operator as a private address. A common case of this is a legacy wireless network using 1.1.1.0/24 as if it was a private address. In this case, 6to4 will assume it is connected to the global Internet, but there is certainly no working return path.
7.偽の住所の失敗：設計により、6to4のが動作しないと利用できV4ADDRはプライベートアドレス[RFC1918]であれば、それ自体をアクティブにしません。利用可能V4ADDRは「bogon」、すなわち、プライベートアドレスとしてオペレータによって使用されているグローバルアドレスである場合しかし、それはまた、動作しません。この一般的な場合は、それがプライベートアドレスであるかのよう1.1.1.0/24を使ってレガシー無線ネットワークです。この場合、6to4のは、それがグローバルなインターネットに接続されていると仮定しますが、ない作業リターンパスは確かにありません。
This failure mode will also occur if an ISP is operating a
Carrier Grade NAT [CGN] between its customers and the Internet,
and is using global public address space as if it were private
space to do so.
8. Faulty 6to4 Implementations: It has been reported that some 6to4 implementations attempt to activate themselves even when the available IPv4 address is an RFC 1918 address. This is in direct contradiction to RFC 3056, and will produce exactly the same failure mode as Bogus Address Failure. It is of course outside the ISP's control.
8.障害のある6to4の実装：いくつかの6to4実装が可能なIPv4アドレスは、RFC 1918アドレスであっても、自分自身をアクティブにしようとしていることが報告されています。これは、RFC 3056に直接矛盾する、と偽のアドレスの失敗とまったく同じ故障モードが生成されます。これは、ISPのコントロール外はもちろんです。
9. Difficult Fault Diagnosis: The existence of all the above failure modes creates a problem of its own: very difficult fault diagnosis, especially if the only symptom reported by a user is slow access to web pages, caused by a long timeout before fallback to IPv4. Tracking down anycast routing problems and PMTUD failures is particularly hard.
9.困難な故障診断：へのフォールバックの前に長いタイムアウトによる、ユーザーによって報告された唯一の症状は、Webページへのアクセスが遅い場合は特に、非常に困難な故障診断：上記のすべての故障モードの存在は、独自の問題を作成し、 IPv4の。エニーキャストルーティングの問題とPMTUDの障害を追跡することは特に難しいです。
The practical impact of the above problems, which are by no means universal as there is considerable successful use of Anycast 6to4, has been measured at a fraction of 1% loss of attempted connections to dual-stack content servers [Anderson]. This is because a small fraction of client hosts attempt to connect using 6to4, and up to 20% of these experience one of the above failure modes. While this seems low, it amounts to a significant financial impact for content providers. Also, end users frustrated by the poor response times caused by fallback to IPv4 connectivity [EYEBALLS-IPV6] are considered likely to generate help-desk calls with their attendant costs.
エニーキャストの6to4のかなりの成功した使用があるようになしによるものである、上記の問題の実用的な影響は、汎用手段、デュアルスタック・コンテンツ・サーバに接続試行の1％損失[アンダーソン]の分数で測定されました。クライアントホストのごく一部が6to4のを使用して接続しようとすると、これらの経験上記の故障モードの1の20％までのためです。これは低いと思われるが、それはコンテンツプロバイダのための重要な財務的影響になります。また、[眼球-IPV6] IPv4接続にフォールバックによって引き起こされる貧困層の応答時間でイライラエンドユーザーがヘルプデスクは、その付随するコストを呼び出す発生する可能性が高いと考えられています。
A rather different operational problem caused incidentally by 6to4 is that, according to observations made at the University of Southampton by Tim Chown and James Morse, and at other sites, rogue Router Advertisements [RFC6104] often convey a 2002::/16 prefix. This appears to be due to misbehavior by devices acting as local IPv6 routers or connection-sharing devices but issuing Router Advertisement (RA) messages on the wrong interface. Such a device, if it obtains IPv6 connectivity via an upstream link to the Internet, should only issue the corresponding RA messages on its downstream link to the nodes intended to share its Internet connection. Issuing RA messages on the upstream link will perturb any other IPv6 hosts on that link. If 6to4 routing is enabled by default on a device that exhibits this faulty behavior, the resulting rogue RA messages will indeed convey a 2002::/16 prefix.
むしろ、異なる動作上の問題は、6to4で偶然に生じた不正なルータ広告は、多くの場合、2002 :: / 16のプレフィックスを伝える[RFC6104]、つまり、ティムchownコマンドとジェームズ・モールスによってサウサンプトン大学で行った観察によると、他のサイトです。これは、ローカルIPv6ルータまたは接続共有デバイスとして動作しますが、間違ったインターフェイスでルータアドバタイズメント（RA）メッセージを発行するデバイスが不正行為に起因すると思われます。それはインターネットへのアップストリームリンクを介してIPv6接続を取得する場合、そのようなデバイスは、唯一のインターネット接続を共有することを意図したノードへの下流リンクに対応するRAメッセージを発行しなければなりません。上流リンクにRAメッセージを発行すると、そのリンク上の他のIPv6ホストを混乱させるだろう。 6to4のルーティングは、この障害のある挙動を示すデバイスでは、デフォルトで有効になっている場合は、結果の不正なRAメッセージは確かに2002 :: / 16のプレフィックスを伝えます。
There are several types of operator involved, willingly or unwillingly, in the Anycast 6to4 scenario and they will all suffer if things work badly. To avoid operational problems and customer dissatisfaction, there is a clear incentive for each of them to take appropriate action, as described below.
そこ関わるオペレータのいくつかのタイプは、エニーキャスト6to4のシナリオでは、喜んまたは不本意、ある物事がひどく動作している場合、それらはすべて低下します。操作上の問題や顧客の不満を回避するために、以下に説明するように、適切な行動を取るためにそれらのそれぞれのための明確な動機が存在します。
This document avoids formal normative language, because it is highly unlikely that the guidelines apply universally. Each operator will make its own decisions about which of the following guidelines are useful in its specific scenario.
ガイドラインが普遍的に適用する可能性はほとんどありませんので、この文書では、正式な規範的な言語を避けることができます。各オペレータは、その特定のシナリオで有用である以下のガイドラインのかについて、独自の意思決定を行います。
Although this document is aimed principally at operators, there are some steps that implementers and vendors of 6to4 should take.
この文書は、事業者で、主目的としているが、6to4のの実装とベンダーが取るべきいくつかのステップがあります。
1. Some vendors of routers, including customer premises equipment, have not only included support for 6to4 in their products, but have enabled it by default. This is bad practice - it should always be a conscious decision by a user to enable 6to4. Many of the above problems only occur due to unintentional deployment of 6to4.
1.顧客宅内機器を含む、ルータの一部のベンダーは、自社製品での6to4のためのサポートが含まれているだけでなく、デフォルトでは、それを有効にしています。これは悪い習慣である - いつもの6to4を有効にするには、ユーザが意識的に決定する必要があります。上記の問題の多くは、唯一の原因で6to4の意図しない展開に起こります。
2. Similarly, host operating systems should not enable Anycast 6to4 by default; it should always be left to the user to switch it on.
2.同様に、ホスト・オペレーティング・システムは、デフォルトではエニーキャストの6to4を有効にしないでください。常にそれを切り替えるために、ユーザーに委ねられるべき。
3. Any 6to4 implementation that attempts to activate itself when the available IPv4 address is an RFC 1918 address is faulty and needs to be updated.
3.利用可能なIPv4アドレスは、RFC 1918アドレスであるとき、自身を起動しようとする任意の6to4の実装に障害があり、更新する必要があります。
4. 6to4 implementations should adopt updated IETF recommendations on address selection [RFC3484-REVISE].
4. 6to4の実装では、アドレス選択[RFC3484-REVISE]に更新IETF勧告を採用すべきです。
5. 6to4 relay implementations must carefully follow Section 3.2 of [RFC4213] to ensure correct handling of MTU issues.
5.の6to4リレーの実装は慎重にMTUの問題の正しい取扱いを確保するために、[RFC4213]の3.2節に従わなければなりません。
6. 6to4 router or connection-sharing implementations must avoid issuing rogue RAs [RFC6104]. Additionally, where 6to4 is being enabled by a node for Internet-connection-sharing purposes, and the node supports [RFC4191], then it should set the Router Advertisement router preference bits to 11 (low preference).
6. 6to4ルーターまたは接続共有の実装は不正のRA [RFC6104]を発行することを避けなければなりません。 6to4がインターネット接続を共有する目的のためのノード、及びノードサポート[RFC4191]で有効にされている場合に加えて、それは11（低優先）にルータ広告ルータの優先ビットを設定しなければなりません。
4.2. Consumer ISPs, and Enterprise Networks, That Do Not Support IPv6 in Any Way
4.2. 消費者のISP、および企業ネットワーク、どのような方法でサポートしないIPv6のこと
To reduce the negative impact of Anycast 6to4 deployed (probably unknowingly) by users, and consequent user dissatisfaction and help-desk calls, such ISPs should check in sequence:
ユーザー、およびその結果としてユーザーの不満やヘルプデスクの呼び出しで（おそらく無意識のうちに）展開の6to4エニーキャストのマイナスの影響を減らすために、そのようなISPは順番にチェックする必要があります：
1. Does the ISP have a route to 192.88.99.1? (This means an explicit route, or knowledge that the default upstream provider has an explicit route. A default route doesn't count!)
1. ISPは、192.88.99.1へのルートを持っていますか？ （これはデフォルトの上流プロバイダは、明示的なルートがあることを明示的なルート、あるいは知識を意味します。デフォルトルートはカウントされません！）
4. If so, does the relay willingly accept 6to4 traffic from the ISP's IPv4 prefixes? (Note that this is an administrative as well as a technical question -- is the relay's operator willing to accept the traffic?)
4.もしそうなら、リレーは喜んでISPのIPv4プレフィックスからの6to4トラフィックを受け入れるのですか？ （これは行政だけでなく、技術的な問題であることに注意してください - リレーのオペレータは、トラフィックを受け入れることを望んでいるのですか？）
Unless the answer to all these questions is 'yes', the operator should consider blocking the route to 192.88.99.1 and generating an IPv4 'destination unreachable' message. This may cause some 6to4 implementations to fall back to IPv4 more quickly. There is little operational experience with this, however.
すべてのこれらの質問への答えは「イエス」である場合を除き、オペレータは、192.88.99.1へのルートを遮断し、IPv4の「宛先到達不能」というメッセージを生成する検討すべきです。これは、いくつかの6to4実装は、より迅速に戻ったIPv4に落下する恐れがあります。これで少し運用経験は、しかし、があります。
Some implementations also perform some form of 6to4 relay qualification. For example, one host implementation (Windows) tests the protocol 41 reachability by sending an ICMPv6 echo request with Hop Limit = 1 to the relay, expecting a response or Hop Limit exceeded error back. Lack of any response indicates that the 6to4 relay does not work so 6to4 is turned off [Savola].
いくつかの実装も6to4リレー資格のいくつかのフォームを実行します。例えば、一つのホストの実装（Windows）は応答を期待またはホップリミットバック誤差を超えて、リレーにホップ限界= 1でICMPv6エコー要求を送信することによって、プロトコル41の到達可能性をテストします。任意の応答の欠如は、6to4リレーが[Savola]ターンオフされる6to4のように動作しないことを示しています。
A more constructive approach for such an ISP is to seek out a transit provider who is indeed willing to offer outbound 6to4 relay service, so that the answer to each of the questions above is positive.
そのようなISPのためのより建設的なアプローチは、上記の質問のそれぞれに対する答えが肯定的であるように、確かにアウトバウンド6to4リレーサービスを提供していく所存ですトランジットプロバイダーを模索することです。
ISPs in this class should always allow protocol 41 through their network and firewalls. Not only is this a necessary condition for 6to4 to work, but it also allows users who want to use a configured IPv6 tunnel service to do so.
このクラスのISPは、常に自社のネットワークとファイアウォールを介したプロトコル41を許可する必要があります。これは、6to4が機能するための必要条件であるが、それはまた、そうするように構成されたIPv6トンネルサービスを利用したいユーザーを可能にするだけでなく。
Some operators, particularly enterprise networks, silently block protocol 41 on security grounds. Doing this on its own is bad practice, since it contributes to the problem and harms any users who are knowingly or unknowingly attempting to run 6to4. The strategic solution is to deploy native IPv6, making protocol 41 redundant. In the short term, experimentation could be encouraged by allowing protocol 41 for certain users, while returning appropriate ICMP responses as mentioned above. Unfortunately, if this is not done, the 6to4 problem cannot be solved.
静かにいくつかの演算子、特に企業ネットワークは、セキュリティ上の理由でプロトコル41を遮断します。それが問題に貢献し、故意または無意識の6to4を実行しようとしているすべてのユーザーに害を与えるので、自分自身でこれを行うと、悪い習慣です。戦略的な解決策は、プロトコル41の冗長を行う、ネイティブIPv6を展開することです。上述したように、適切なICMP応答を返しながら、短期的には、実験は、特定のユーザのためのプロトコル41を可能にすることによって促進することができます。これが行われていない場合は残念ながら、6to4の問題を解決することはできません。
Operators should never use "bogon" address space such as the example of 1.1.1.0/24 for customers, since IPv4 exhaustion means that all such addresses are likely to be in real use in the near future. (Also, see [RFC6269].) An operator that is unable to immediately drop this practice should ensure that 192.88.99.1 generates IPv4 'destination unreachable'. It has been suggested that they could also run a dummy 6to4 relay at that address which always returns ICMPv6 'destination unreachable' as a 6to4 packet. However, these techniques are not very effective, since most current end-user 6to4 implementations will ignore them.
IPv4の枯渇は、すべてのそのようなアドレスが近い将来における実際の使用中である可能性があることを意味するのでオペレータは、そのような顧客のため1.1.1.0/24の一例として、「bogon」のアドレス空間を使用しないでください。 （また、[RFC6269]を参照。）すぐにこの練習をドロップすることができない操作者は192.88.99.1は、IPv4「宛先が到達不能」を生成することを確実にすべきです。彼らはまた、常に6to4のパケットとして「到達不能先」のICMPv6を返すそのアドレスにダミー6to4リレーを実行できることが示唆されています。最新のエンドユーザーの6to4実装はそれらを無視するので、しかし、これらの技術は、非常に効果的ではありません。
If an operator is providing legitimate global addresses to customers (neither RFC 1918 nor bogon addresses), and also running Carrier Grade NAT (Large Scale NAT) between this address space and the global address space of the Internet, then 6to4 cannot work properly. Such an operator should also take care to return 'destination unreachable' for 6to4 traffic. Alternatively, they could offer untranslated address space to the customers concerned.
オペレータは（どちらもRFC 1918もbogonアドレス）顧客への正当なグローバルアドレスを提供し、またこのアドレス空間とインターネットのグローバルアドレス空間との間でキャリアグレードNAT（大規模NAT）を実行している場合は、6to4のは正しく動作することはできません。このようなオペレータは、6to4のトラフィックのために「宛先到達不能」を返すように注意する必要があります。あるいは、それらは、当該顧客に翻訳されないアドレス空間を提供することができます。
A customer who is intentionally using 6to4 may also need to create AAAA records, and the operator should be able to support this, even if the DNS service itself runs exclusively over IPv4. However, customers should be advised to consider carefully whether their 6to4 service is sufficiently reliable for this.
意図的で6to4を使用している顧客はまた、AAAAレコードを作成する必要があり、操作者がDNSサービス自体は、IPv4上で排他的に実行されている場合でも、これをサポートすることができるはずです。しかし、顧客は6to4サービスは、このための十分な信頼性があるかどうかを慎重に検討することをお勧めする必要があります。
Operators could, in principle, offer reverse DNS support for 6to4 users [RFC5158], although this is not straightforward for domestic customers.
これは、国内の顧客のために簡単ではないが、オペレータは、原則的には、6to4のユーザーが[RFC5158]のための逆引きDNSのサポートを提供することができます。
Paradoxically, operators in this category should consider whether they need to defend themselves against rogue IPv6 RA messages [RFC6105], since such messages may appear from devices seeking to
このようなメッセージがしようとしているデバイスから表示される場合がありますので、逆説的に、このカテゴリーの事業者は、彼らが不正なIPv6のRAメッセージ[RFC6105]から身を守るために必要があるかどうかを検討すべきです
operate as 6to4 routers and confuse any user devices with IPv6 enabled by default. Eventually, the measures being designed by the IETF Source Address Validation Improvement (SAVI) working group will assist with this problem. In the short term, IPv4-only operators may choose to filter out packets with the IPv6 Ethertype (0x86DD) in their access equipment; this will definitively remove rogue RA packets.
6to4のルータとして動作し、デフォルトで有効になってIPv6で任意のユーザデバイスを混乱させる。結局、対策が検証改善（SAVI）ワーキンググループは、この問題を支援するIETFソースアドレスによって設計されています。短期的には、IPv4のみのオペレータはそのアクセス機器におけるIPv6のイーサタイプ（0x86DD）を持つパケットをフィルタリングすることを選択することができます。これは決定的に不正RAパケットを削除します。
Enterprise operators who have complete administrative control of all end systems may choose to disable 6to4 in those systems as an integral part of their plan to deploy IPv6.
すべてのエンドシステムの完全な管理制御を持つエンタープライズ事業者は、IPv6を展開する彼らの計画の不可欠な一部として、これらのシステムでの6to4を無効にすることもできます。
Some IPv4 operators have chosen to install a 6to4 relay, connected via an IPv6-in-IPv4 tunnel to an IPv6 operator, as a first step before native IPv6 deployment. The routing guidelines in Section 4.4 would apply. However, offering genuine IPv6 service to interested customers, even if tunneled, would generally be a better first step.
いくつかのIPv4オペレータは、ネイティブIPv6展開の前に最初のステップとして、IPv6のオペレータへのIPv6型のIPv4トンネルを介して接続され、6to4リレーをインストールすることを選択しました。 4.4節でのルーティングのガイドラインが適用されます。しかし、興味を持ってお客様に本物のIPv6サービスを提供し、トンネル化しても、一般的に、より良い最初のステップになります。
Once an operator does support IPv6 service, whether experimentally or in production, it is almost certain that users will get better results using this service than by continuing to use 6to4. Therefore, these operators are encouraged to advise their users to disable 6to4 and they should not create DNS records for any 6to4 addresses.
オペレータは、実験や生産のか、IPv6サービスをサポートしていたら、ユーザーが6to4のを使い続けるよりも、このサービスを利用して、より良い結果を得るだろうことはほぼ確実です。したがって、これらの演算子は、6to4の無効にするには、その利用者に助言することが奨励され、彼らはどんな6to4のアドレスのDNSレコードを作成しないでください。
Such an operator may automatically fall into one of the following two categories (transit provider or content provider), so the guidelines in Sections 4.4 or 4.5 will apply instead.
そのようなオペレータは、自動的に次の二つのカテゴリー（トランジット・プロバイダ又はコンテンツプロバイダ）のいずれかに分類することができるので、セクション4.4または4.5のガイドラインは、代わりに適用されます。
Operators in this category should make sure that no routers are unintentionally or by default set up as active 6to4 relays. Unmanaged 6to4 relays will be a source of problems.
このカテゴリにオペレータにはルータが意図せずまたはアクティブの6to4リレーとして設定し、デフォルトではされていないことを確認する必要があります。非管理対象の6to4リレーは、問題の原因となります。
Operators in this category should consider whether they need to defend themselves against rogue RA messages with an RA Guard solution [RFC6105]. If RA Guard is not available, it may help in some cases if at least one legitimate IPv6 router per LAN supports [RFC4191] and sets the Router Advertisement router preference bits to 01 (high preference). Eventually, the measures being designed by the IETF Source Address Validation Improvement (SAVI) working group will assist with this problem.
このカテゴリーのオペレータは、彼らがRAガードソリューション[RFC6105]で不正なRAメッセージに対して自身を守るために必要があるかどうかを検討すべきです。 RAガードが使用できない場合はLANごとに少なくとも1つの合法的なIPv6ルータは、[RFC4191]をサポートしており、01（高優先度）にルータアドバタイズメントのルータの優先ビットを設定した場合、それはいくつかのケースで役立つことがあります。結局、対策が検証改善（SAVI）ワーキンググループは、この問題を支援するIETFソースアドレスによって設計されています。
We assume that transit ISPs have IPv6 connectivity. To reduce the negative impact of Anycast 6to4 on all their client networks, it is strongly recommended that they each run an Anycast 6to4 relay service. This will have the additional advantage that they will terminate the 6to4 IPv4 packets and can then forward the decapsulated IPv6 traffic according to their own policy. Otherwise, they will blindly forward all the encapsulated IPv6 traffic to a competitor who does run a relay.
私たちは、トランジットISPがIPv6接続を持っていることを前提としています。すべてのクライアント・ネットワーク上のエニーキャストの6to4の負の影響を低減するために、強く、彼らそれぞれがエニーキャストの6to4リレーサービスを実行することをお勧めします。これは、彼らがの6to4 IPv4パケットを終了し、その後、独自のポリシーに従ってカプセル化が解除IPv6トラフィックを転送することができるという追加の利点を持つことになります。そうでなければ、彼らはリレーを実行しない競合他社へのすべてのカプセル化されたIPv6トラフィック盲目的に転送します。
Although most modern Internet Exchange Points do not offer IP layer services, an Internet exchange point (IXP) could choose to operate an Anycast 6to4 relay service for the benefit of its customers. If so, it should follow the recommendations in this section.
最も近代的なインターネットエクスチェンジは、IPレイヤのサービスを提供していませんが、インターネットエクスチェンジポイント（IXP）は、その顧客の利益のためにエニーキャストの6to4リレーサービスを動作させるために選択することができます。もしそうなら、それは、このセクションの推奨事項に従ってください。
It is of critical importance that routing to this service is carefully managed:
それは、このサービスへのルーティングを慎重に管理されていることを非常に重要です：
1. The IPv4 prefix 192.88.99.0/24 must be announced only towards client IPv4 networks whose outbound 6to4 packets will be accepted.
1.のIPv4プレフィックス192.88.99.0/24はそのアウトバウンドの6to4パケット受け入れられるクライアントのIPv4ネットワークに向けて発表されなければなりません。
2. The IPv6 prefix 2002::/16 must be announced towards native IPv6. The relay must accept all traffic towards 2002::/16 that reaches it, so the scope reached by this announcement should be carefully planned. It must reach all client IPv6 networks of the transit ISP. If it reaches a wider scope, the relay will be offering a free ride to non-clients.
2. IPv6プレフィックス2002 :: / 16は、ネイティブIPv6に向けて発表されなければなりません。リレーは、2002年に向けて、すべてのトラフィックを受け入れる必要があります:: / 16に到達したので、この発表によって到達範囲を慎重に計画しなければならないこと。これは、トランジットISPのすべてのクライアントのIPv6ネットワークに到達しなければなりません。それは、より広い範囲に達した場合、リレーは非クライアントにフリーライドを提供する予定。
3. As discussed in item 2 of Section 3, the choice of IPv4 source address used when the relay sends 6to4 packets back towards a 6to4 user is important. The best choice is likely to be 192.88.99.1, not the relay's unicast IPv4 address, unless ingress filtering is an issue. This is to avoid failure if the user is behind a stateful firewall.
3.第3の項目2で述べたように、中継バックの6to4ユーザに向けての6to4パケットを送信するときに使用されるIPv4ソースアドレスの選択が重要です。最良の選択は、入力フィルタリングが問題でない限り、192.88.99.1ではなく、リレーのユニキャストIPv4アドレスである可能性が高いです。これにより、ユーザーは、ステートフルファイアウォールの背後にある場合は、障害を回避することです。
4. The relay should be capable of responding correctly to ICMPv6 echo requests encapsulated in IPv4 protocol 41, typically with outer destination address 192.88.99.1 and inner destination address 2002:c058:6301::. (As noted previously, some 6to4 hosts are known to send echo requests with Hop Limit = 1, which allows them to rapidly detect the presence or absence of a relay in any case, but operators cannot rely on this behavior.)
前記リレーは、典型的には、外側の宛先アドレス192.88.99.1と内側宛先アドレス2002、IPv4プロトコル41内に封入されたICMPv6のエコー要求に正しく応答することができなければならない：C058：6301 ::。 （先に述べたように、いくつかの6to4ホストはそれらが急速にいずれの場合にも中継の有無を検出することを可能にするが、オペレータは、この動作に頼ることができないホップ限界= 1、エコー要求を送信することが知られています。）
5. Protocol 41 must not be filtered in any IPv4 network or firewalls.
5.プロトコル41は、任意のIPv4ネットワークまたはファイアウォールでフィルタリングしてはなりません。
6. As a matter of general practice, which is essential for 6to4 to work well, IPv6 PMTUD must be possible, which means that ICMPv6 must not be blocked anywhere [RFC4890]. This also requires that the relay has a sufficiently high ICMP error generation threshold. For a busy relay, a typical default rate limit of 100 packets per second is too slow. On a busy relay, 1000 pps or more might be needed. If ICMPv6 "Packet Too Big" error messages are rate limited, users will experience PMTUD failure.
6. 6to4のがうまく機能するために不可欠であり、一般的な慣行の問題として、IPv6のPMTUDは、ICMPv6のはどこか[RFC4890]ブロックされてはならないことを意味し、可能でなければなりません。また、これはリレーが十分に高いICMPエラー発生のしきい値を持っていることが必要です。忙しいリレーの場合、毎秒100のパケットの典型的なデフォルトのレート制限は遅すぎます。忙しいリレーでは、1000のPPS以上が必要になることがあります。 ICMPv6の「パケット過大」エラーメッセージがレート制限されている場合、ユーザーはPMTUDの障害が発生します。
7. The relay must have adequate performance, and since load prediction is extremely hard, it must be possible to scale it up or, perhaps better, to replicate it as needed. Since the relay process is stateless, any reasonable method of load sharing between multiple relays will do.
7.リレーは、十分な性能を持っている必要がありますし、負荷予測が極めて困難であることから、それをスケールアップするか、おそらくより良い、必要に応じてそれを複製することが可能でなければなりません。リレープロセスはステートレスであるので、複数のリレー間の負荷分散のいずれかの合理的な方法を行います。
8. Of course, the relay must be connected directly to global IPv4 space, with no NAT.
もちろん8.、リレーがNATなしで、グローバルIPv4空間に直接接続する必要があります。
Operators in this category should make sure that no routers are unintentionally or by default set up as active 6to4 relays. Unmanaged 6to4 relays will be a source of problems.
このカテゴリにオペレータにはルータが意図せずまたはアクティブの6to4リレーとして設定し、デフォルトではされていないことを確認する必要があります。非管理対象の6to4リレーは、問題の原因となります。
We assume that content providers and their ISPs have IPv6 connectivity, and that the servers are dual stacked. The following applies to content servers as such, but equally to web hosting servers, servers that form part of a content distribution network, load balancers in front of a server farm, and HTTP caches. There is a need to avoid the situation where a client host, configured with Anycast 6to4, succeeds in sending an IPv6 packet to the server, but the 6to4 return path fails as described above. To avoid this, there must be a locally positioned 6to4 relay. Large content providers are advised to operate their own relays, and ISPs should do so in any case. There must be a 2002::/16 route from the content server to the relay. As noted in the previous section, the corresponding route advertisement must be carefully scoped, since any traffic that arrives for 2002::/16 must be relayed.
私たちは、コンテンツプロバイダとそのISPがIPv6接続を持っていると仮定して、サーバがデュアルスタックされています。以下のようなコンテンツサーバに適用されますが、同じようにウェブホスティングサーバ、コンテンツ配信ネットワークの一部を形成して、サーバ、サーバファームの前でロードバランサ、およびHTTPキャッシュへ。そこエニーキャストの6to4で構成されたクライアントホストは、サーバーへのIPv6パケットを送信することに成功した状況を回避する必要があるが、上記のように6to4のリターンパスが失敗します。これを避けるために、ローカルに配置さ6to4リレーがなければなりません。大規模なコンテンツプロバイダは、独自のリレーを動作することをお勧めします、とISPはどのような場合にはそうする必要があります。コンテンツサーバからリレーへの2002 :: / 16ルートが存在する必要があります。前節で述べたように2002年のために到着するすべてのトラフィック:: / 16を中継しなければならないので、対応するルートの広告は慎重に、スコープする必要があります。
Such a relay may be dedicated entirely to return traffic, in which case, it need not respond to the 6to4 anycast address.
このようなリレーは、その場合には、それは、6to4エニーキャストアドレスに対応する必要はない、トラフィックを返すように完全に専念することができます。
Nevertheless, it seems wisest to ensure that when the relay sends 6to4 packets back towards a 6to4 user, they should have 192.88.99.1 as their IPv4 source address (not the relay's unicast IPv4 address). As noted above, this is to avoid problems if the user is behind a stateful firewall that drops UDP packets from addresses that have not been seen in outbound traffic. However, it is also necessary that 192.88.99.1 is not blocked by upstream ingress filtering -- this needs to be tested.
それにもかかわらず、リレーは6to4のユーザーの方に戻った6to4パケットを送信するとき、彼らは自分のIPv4送信元アドレス（ないリレーのユニキャストIPv4アドレス）として192.88.99.1を持つべきであることを保証するために賢明なようです。上述したように、これは、ユーザーが発信トラフィックで見られていないアドレスからのUDPパケットをドロップするステートフルファイアウォールの背後にある場合の問題を回避することです。しかし、192.88.99.1、上流入口フィルタリングによってブロックされていないことも必要である - これはテストする必要があります。
Without careful engineering, there is nothing to make the return path as short as possible. It is highly desirable to arrange the scope of advertisements for 2002::/16 such that content providers have a short path to the relay, and the relay should have a short path to the ISP border. Care should be taken about shooting off advertisements for 2002::/16 into BGP4; they will become traffic magnets. If every ISP with content provider customers operates a relay, there will be no need for any of them to be advertised beyond each ISP's own customers.
慎重なエンジニアリングせずに、できるだけ短いリターン・パスを作るためには何もありません。 2002年の広告の範囲を手配することが非常に望ましい::など/ 16コンテンツプロバイダは、リレーへのショートパスを持っており、リレーはISPの国境に短いパスを持つべきであるということ。ケアは、BGP4に2002 :: / 16の広告をオフに撮影について注意が必要です。彼らは、トラフィックの磁石になります。コンテンツプロバイダーの顧客とのすべてのISPは、リレーを動作させる場合は、各ISPの独自の顧客を超えて宣伝するそれらのいずれかは必要ないでしょう。
Protocol 41 must not be filtered in the ISP's IPv4 network or firewalls. If the relays are placed outside the content provider's firewall, the latter may filter protocol 41 if desired.
プロトコル41は、ISPのIPv4ネットワークまたはファイアウォールでフィルタリングしてはいけません。リレーは、コンテンツプロバイダのファイアウォールの外側に配置されている場合、所望であれば、後者は、プロトコル41をフィルタリングすることができます。
The relay must have adequate performance, and since load prediction is extremely hard, it must be possible to scale it up or, perhaps better, to replicate it as needed. Since the relay process is stateless, any reasonable method of load sharing between multiple relays will do.
リレーは、十分な性能を持っている必要がありますし、負荷予測が極めて困難であることから、それをスケールアップするか、おそらくより良い、必要に応じてそれを複製することが可能でなければなりません。リレープロセスはステートレスであるので、複数のリレー間の負荷分散のいずれかの合理的な方法を行います。
The relay must of course be connected directly to global IPv4 space, with no NAT.
リレーはもちろん、NATなしで、グローバルIPv4空間に直接接続する必要があります。
An option is to embed the relay function directly in the content server or first hop router. This is straightforward, since it can be achieved by enabling a local 6to4 interface, and using it to route 2002::/16 for outbound packets. (This might not allow use of 192.88.99.1 as the source address.) Further details are to be found at [Huston-b]. However, in this case protocol 41 must be allowed by the firewalls.
オプションでは、コンテンツサーバまたは最初のホップルータに直接リレー機能を埋め込むことです。それはローカル6to4インタフェースを可能にし、アウトバウンドパケットのルート2002 :: / 16にそれを使用することによって達成することができるので、これは簡単です。 （これは、ソースアドレスとして192.88.99.1の使用を許可しない場合があります。）さらに詳しく[ヒューストン-B]に見出されます。しかし、この場合には、プロトコル41がファイアウォールによって許可されなければなりません。
Content providers who do embed the relay function in this way could, in theory, accept inbound 6to4 traffic as well. This is highly unadvisable since, according to the rules of 6to4, they would then have to relay traffic for other IPv6 destinations, too. So they should not be reachable via 192.88.99.1. Also, they should certainly not create an AAAA record for their 6to4 address -- their inbound IPv6 access should be native, and advertising a 6to4 address might well lead to unicast reverse path forwarding (uRPF) [RFC3704] ingress filtering problems.
このように、中継機能を埋め込むないコンテンツプロバイダは、理論的には、同様のインバウンドの6to4トラフィックを受け入れることができます。これは、6to4のの規則に従って、彼らはその後、あまりにも、他のIPv6宛先にトラフィックを中継しなければならないので、非常にunadvisableです。そこで、彼らは192.88.99.1を経由して到達すべきではありません。その着信IPv6アクセスがネイティブであるべきであり、6to4アドレスを公示することも、ユニキャストリバースパス転送（uRPFの）[RFC3704]イングレスフィルタリングの問題につながる可能性がある - また、彼らは確かに彼らの6to4アドレスのためのAAAAレコードを作成しないでください。
To avoid the path MTU problem described above, content servers should also set their IPv6 MTU to a safe value. From experience, 1280 bytes (the minimum allowed for IPv6) is recommended; again, see [Huston-b].
上記のパスMTUの問題を回避するには、コンテンツサーバも安全な値に自分のIPv6 MTUを設定する必要があります。経験から、1280バイト（IPv6のために許容される最小）が推奨されます。もう一度、[ヒューストン-B]を参照してください。
Of course, ICMPv6 "Packet Too Big" must not be blocked or rate-limited anywhere [RFC4890].
[RFC4890]をもちろん、ICMPv6の「パケット過大」はブロックされてはならないか、任意の場所にレート制限します。
Reverse DNS delegations are highly unlikely to exist for 6to4 clients, and are by no means universal for other IPv6 clients. Content providers (and, in fact, all service providers) should not rely on them as a pseudo-security check for IPv6 clients.
リバースDNSの代表団は、6to4クライアントのために存在する可能性は極めて低いです、ノーで他のIPv6クライアント用のユニバーサルを意味しています。コンテンツプロバイダ（と、実際には、すべてのサービスプロバイダ）は、IPv6のクライアントの擬似セキュリティチェックとして、それらに頼るべきではありません。
Operators and content providers should make sure that no routers are unintentionally or by default set up as active 6to4 relays. Unmanaged 6to4 relays will be a source of problems.
オペレータやコンテンツプロバイダにはルータが意図せずまたはアクティブの6to4リレーとして設定し、デフォルトではされていないことを確認する必要があります。非管理対象の6to4リレーは、問題の原因となります。
There are various ways, such as tunnel brokers [RFC3053], 6rd [RFC5969], and Layer 2 Tunneling Protocol version 2 (L2TPv2) hub-and-spoke [RFC5571], by which Internet Service Providers can provide tunneled IPv6 service to subscribers in a managed way, in which the subscriber will acquire an IPv6 prefix under a normal provider-based global IPv6 prefix. Most of the issues described for 6to4 do not arise in these scenarios. However, for IPv6-in-IPv4 tunnels used by clients behind a firewall, it is essential that IPv4 protocol 41 is not blocked.
インターネットサービスプロバイダは、内の加入者にトンネルIPv6サービスを提供することができることにより、様々な、このようなトンネルブローカー[RFC3053]、6rd [RFC5969]などの方法、およびレイヤ2トンネリングプロトコルバージョン2（L2TPv2）ハブ・アンド・スポーク[RFC5571]は、あります。加入者は、通常のプロバイダベースのグローバルIPv6プレフィックスの下でIPv6プレフィックスを買収することで管理の方法、。 6to4のために説明した問題のほとんどは、これらのシナリオでは発生しません。しかし、ファイアウォールの背後のクライアントによって使用されるのIPv6インのIPv4トンネルのために、IPv4プロトコル41がブロックされていないことが不可欠です。
As a matter of general practice, IPv6 PMTUD must be possible, which means that ICMPv6 "Packet Too Big" must not be blocked or rate-limited anywhere [RFC4890].
一般的な慣行の問題として、IPv6のPMTUDはICMPv6の「パケット過大」は[RFC4890]をブロックまたは任意の場所にレートが制限されてはならないことを意味し、可能でなければなりません。
There is a general discussion of security issues for IPv6-in-IPv4 tunnels in [RFC6169], and [TUNNEL-LOOPS] discusses possible malicious loops. [RFC3964] specifically discusses 6to4 security. In summary, tunnels create a challenge for many common security mechanisms, simply because a potentially suspect packet is encapsulated inside a harmless outer packet. All these considerations apply to the automatic mechanisms discussed in this document. However, it should be noted that if an operator provides well-managed servers and relays for 6to4, non-encapsulated IPv6 packets will pass through well-defined points (the native IPv6 interfaces of those servers and relays) at which security mechanisms may be applied.
[RFC6169]でのIPv6インのIPv4トンネル、および[TUNNEL-LOOPS]が可能悪質なループを議論するために、セキュリティ上の問題の一般的な議論があります。 [RFC3964]は、具体的に6to4のセキュリティを論じています。要約すると、トンネルが潜在的に疑わしいパケットが無害な外部パケット内にカプセル化されたという理由だけで、多くの一般的なセキュリティメカニズムのための課題を作成します。すべてのこれらの考慮事項は、この文書で説明する自動メカニズムに適用されます。しかし、オペレータは6to4のために適切に管理サーバーとリレーを提供する場合、非カプセル化されたIPv6パケットは、セキュリティメカニズムが適用されるに十分に規定された点（これらのサーバーとリレーのネイティブIPv6インタフェース）を通過することに留意すべきです。
A blanket recommendation to block protocol 41 is not compatible with mitigating the 6to4 problems described in this document.
プロトコル41を遮断するブランケット勧告は、本書に記載の6to4問題を緩和すると互換性がありません。
Useful comments and contributions were made by Emile Aben, Mikael Abrahamsson, Tore Anderson, Hermin Anggawijaya, Jack Bates, Cameron Byrne, Tim Chown, Remi Despres, Jason Fesler, Wes George, Philip Homburg, Ray Hunter, Geoff Huston, Eric Kline, Victor Kuarsingh, Martin Levy, David Malone, Alexey Melnikov, Martin Millnert, Keith Moore, Gabi Nakibly, Michael Newbery, Phil Pennock, Pekka Savola, Mark Smith, Nathan Ward, James Woodyatt, and others.
有益なコメントと貢献はエミールアーベン、ミカエルAbrahamssonによって作られた、アンダーソン、Hermin Anggawijaya、ジャック・ベイツ、キャメロン・バーン、ティムのchown、レミ・デプレ、ジェイソンFesler、ウェス・ジョージ、フィリップ・ホンブルク、レイ・ハンター、ジェフ・ヒューストン、エリック・クライン、ビクターをとれKuarsingh、マーティン・レヴィ、デイビッド・マローン、アレクセイ・メルニコフ、マーティンMillnert、キースムーア、ガビNakibly、マイケル・ニューベリー、フィル・ペノック、ペッカSavola、マーク・スミス、ネイサンウォード、ジェームズWoodyattなど。
[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ドメインの接続"。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[RFC3068]のHuitema、C.、 "6to4のリレールーターのエニーキャストプレフィックス"、RFC 3068、2001年6月。
[Aben] Aben, E., "6to4 - How Bad is it Really?", 2010, <ht tps://labs.ripe.net/Members/emileaben/ 6to4-how-bad-is-it-really>.
[アーベン]アーベン、E.は、 "6to4の - それは本当にどのように悪いのですか？"、2010年、<HT TPS：//labs.ripe.net/Members/emileaben/の6to4-いかに悪いです - それは、本当に>。
[Anderson] Anderson, T., "IPv6 dual-stack client loss in Norway", 2010, <http://www.fud.no/ipv6/>.
[アンダーソン]アンダーソン、T.、 "ノルウェーのIPv6のデュアルスタッククライアント損失"、2010年、<http://www.fud.no/ipv6/>。
[CGN] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common requirements for Carrier Grade NAT (CGN)", Work in Progress, July 2011.
[CGN]ペロー、S.、山形、I.、宮川、S.、中川、A.、およびH.芦田、 "キャリアグレードNAT（CGN）のための一般的な要件"、進歩、2011年7月での作業。
[DNSWHITE] Livingood, J., "IPv6 AAAA DNS Whitelisting Implications", Work in Progress, June 2011.
[DNSWHITE] Livingood、J.、 "IPv6のAAAA DNSホワイトリストへの影響"、進歩、2011年6月での作業。
[EYEBALLS-IPV6] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending Towards Success with Dual-Stack Hosts", Work in Progress, October 2010.
[眼球-IPV6]ウイング、D.とA. Yourtchenko、：進歩、2010年10月、「ハッピー眼球デュアルスタックホストと成功に向けて注目キーワード」ワーク。
[HISTORIC] Troan, O., "Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status", Work in Progress, June 2011.
[名所旧跡] Troan、O.、進歩、2011年6月に、ワークを「要求は歴史的状態へのIPv4雲（の6to4）を介したIPv6ドメインの接続を移動します」。
[Huston-a] Huston, G., "Flailing IPv6", 2010, <http:// www.potaroo.net/ispcol/2010-12/6to4fail.html>.
[ヒューストン-A]ヒューストン、G.、 "暴れるのIPv6"、2010年、<のhttp：// www.potaroo.net/ispcol/2010-12/6to4fail.html>。
[Huston-b] Huston, G., "Two Simple Hints for Dual Stack Servers", 2010, <http://www.potaroo.net/ispcol/ 2010-05/v6hints.html>.
[ヒューストン-b]ヒューストン、G.、 "デュアルスタックサーバーの2つの簡単なヒント" 2010年、<http://www.potaroo.net/ispcol/ 2010-05 / v6hints.html>。
[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月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923]レイヒー、K.、 "パスMTUディスカバリとTCPの問題"、RFC 2923、2000年9月。
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3053]デュラン、A.、ファザーノ、P.、Guardini、I.、およびD.レント、 "IPv6のトンネルブローカー"、RFC 3053、2001年1月。
[RFC3484-REVISE] Matsumoto, A., Kato, J., Fujisaki, T., and T. Chown, "Update to RFC 3484 Default Address Selection for IPv6", Work in Progress, July 2011.
[RFC3484-REVISE]松本、A.、加藤、J.、藤崎、T.、およびT. CHOWN、 "IPv6のRFC 3484のデフォルトのアドレス選択に更新"、進歩、2011年7月での作業。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F.およびP. Savola、 "マルチホームネットワークの入力フィルタリング"、BCP 84、RFC 3704、2004年3月。
[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004.
[RFC3964] Savola、P.とC.パテル、 "6to4のためのセキュリティの考慮事項"、RFC 3964、2004年12月。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4191] Draves、R.とD.ターラー、 "デフォルトルータの設定と、より詳細なルート"、RFC 4191、2005年11月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmarkと、E.とR.ギリガン、 "IPv6ホストとルータのための基本的な変遷メカニズム"、RFC 4213、2005年10月。
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
[RFC4890]デイヴィス、E.およびJ. Mohacsi、 "ファイアウォールでのフィルタリングICMPv6メッセージへの提言"、RFC 4890、2007年5月。
[RFC5158] Huston, G., "6to4 Reverse DNS Delegation Specification", RFC 5158, March 2008.
[RFC5158]ヒューストン、G.は、2008年3月、RFC 5158 "DNS委任仕様を逆にした6to4"。
[RFC5571] Storer, B., Pignataro, C., Dos Santos, M., Stevant, B., Toutain, L., and J. Tremblay, "Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2)", RFC 5571, June 2009.
[RFC5571]のStorer、B.、Pignataro、C.、ドス・サントス、M.、Stevant、B.、Toutain、L.、及びJ.トレンブレイ、「Softwireハブおよびレイヤ2トンネリングプロトコルバージョン2で展開フレームワークのスポーク（L2TPv2 ）」、RFC 5571、2009年6月。
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010.
[RFC5969] Townsley、W.およびO. Troan、 "IPv4の基盤のIPv6のRapid Deployment（6rd） - プロトコル仕様"、RFC 5969、2010年8月。
[RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Problem Statement", RFC 6104, February 2011.
[RFC6104]のchown、T.とS. Venaas、 "ローグのIPv6ルータアドバタイズメントの問題に関する声明"、RFC 6104、2011年2月。
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011.
[RFC6105]レヴィ - Abegnoli、E.、ヴァン・デ・ヴェルデ、G.、Popoviciu、C.、およびJ. Mohacsi、 "IPv6ルーター広告ガード"、RFC 6105、2011年2月。
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, April 2011.
[RFC6169]クリシュナン、S.、ターラー、D.、およびJ.ホーグランド、 "IPトンネリングとセキュリティの懸念"、RFC 6169、2011年4月。
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
[RFC6269]フォード、M.、Boucadair、M.、デュラン、A.、リーバイス、P.、およびP.ロバーツ、RFC 6269、2011年6月、 "IPアドレスの共有に関する問題"。
[Savola] Savola, P., "Observations of IPv6 Traffic on a 6to4 Relay", ACM SIGCOMM CCR 35 (1) 23-28, 2006.
[Savola] Savola、P.、 "6to4リレー上のIPv6トラフィックの観察"、ACM SIGCOMM CCR 35（1）23-28、2006。
[TUNNEL-LOOPS] Nakibly, G. and F. Templin, "Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations", Work in Progress, May 2011.
[トンネルLOOPS] Nakibly、G.およびF.テンプリン、「IPv6の自動トンネルを使用してルーティングループ攻撃：問題文と提案た軽減」、進歩、2011年5月での作業。
Author's Address
著者のアドレス
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland, 1142 New Zealand
オークランドPB 92019オークランド、1142年ニュージーランドのコンピュータサイエンス大学のブライアン・カーペンター部門
EMail: brian.e.carpenter@gmail.com
メールアドレス：brian.e.carpenter@gmail.com