[要約] RFC 6343は、6to4デプロイメントのためのアドバイザリガイドラインであり、IPv6とIPv4の間のトンネリングをサポートする6to4プロトコルに関する情報を提供します。このRFCの目的は、6to4の適切な設定とデプロイメントに関するガイダンスを提供し、ネットワークエンジニアや管理者が効果的な6to4デプロイメントを行うための支援をすることです。
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
6to4展開のためのアドバイザリーガイドライン
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 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. 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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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].
1. 両方が利用可能であると思われる場合のIPv4とIPv6の間のオペレーティングシステムの好み[RFC3484-Revise]。
2. Ensuring that application software deals gracefully with connectivity problems [EYEBALLS-IPV6].
2. アプリケーションソフトウェアが接続の問題を優雅に扱うことを保証します[Eyeballs-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.
コンパニオンドキュメント[Historic]は、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.
ここでは「Router 6to4」と「Anycast 6to4」と呼ばれる6to4の2つのバリアントがあります。Anycast 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.
Router 6to4は、[RFC3056]に文書化された元のバージョンです。モデルは、ユーザーサイトがネイティブIPv6を運用しているが、ISPがIPv6サービスを提供しないことを想定しています。サイトボーダールーターは、6to4ルーターとして機能します。外部のグローバル32ビットIPv4アドレスがV4ADDRの場合、サイトはIPv6プレフィックス2002：V4ADDR ::/48を自動的に継承します。（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を備えた2つのサイトボーダールーターを考慮してください。したがって、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年までのIPv6ルートを発表します::/16。たとえば、192.0.2.187の6to4ルーターはリレールーターであり、6to4側のアドレスは2002：C000：2BB :: 1であると仮定します。6to4アドレス2002：C000：2AA :: 123を持つホストが、2001：DB8：123：456 :: 321のようなネイティブIPv6宛先にIPv6パケットを送信したとします。192.0.2.170の6to4ルーターには、2002：C000：2BB :: 1、つまりリレーに設定されたIPv6デフォルトルートがあると仮定します。パケットは、IPv4にカプセル化されたリレーに配信されます。リレーはパケットを脱カプセル化し、それをネイティブIPv6に転送して配信します。リモートホストが応答すると、パケット（Source 2001：DB8：123：456 :: 321、Destination 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.
Router 6to4は、6to4ルーターとリレーが管理され、協力的に構成されると想定しています。特に、6to4サイトでは、アウトバウンドトラフィックを運ぶことをいとわないリレールーターを構成する必要があります。これは、デフォルトのIPv6ルーターになります（2002 ::/16を除く）。[RFC3068]で定義されているAnycastバリアントの目的は、そのような構成の必要性を回避することです。意図は、ボーダールーターではなく、単一のホストまたはシンプルなホームゲートウェイを持っている人でも、小規模または国内のユーザーがソリューションを利用できるようにすることでした。これは、192.88.99.1を6to4リレーのデフォルトIPv4アドレスとして定義することにより、非常に簡単に達成され、したがって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.
Anycast 6to4はユーザーサイトのデフォルト構成を暗示するため、特定のユーザーアクションは必要ありません。192.88.99.1でリレーに導入するには、IPv4 Anycastルートが必要です。Router 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の展開はほとんどありません。ほとんどの場合、Anycast 6to4が展開されています。この場合、ユーザーサイト（単一のホストまたは小さなブロードバンドゲートウェイ）は、ネイティブIPv6接続がないが、グローバルIPv4アドレスがあり、AAAAクエリを解決できることを発見します。したがって、6to4パケットを192.88.99.1に送信できると想定しています。
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は接続の障害の重要なレベルに苦しんでいるようです。[Aben]および[Huston-A]を参照してください。多くのデュアルスタックWebサーバーで実施された実験では、TCP接続の故障率が測定されています。これらの実験では、サーバーがTCP synパケットを受信し、応答してSyn/ACKパケットを送信したときにサーバーへのクライアントの接続の試みが失敗したと見なされましたが、最初のTCP 3方向ハンドシェイクを完了するためにACKパケットを受け取りませんでした。Abenが実施した実験では、6to4接続試行すべての9％〜20％の故障率が記録されました。Hustonが実施した実験では、6to4クライアント全体の9％から19％の故障率が記録されています。この後者の実験では、6to4を使用して接続に失敗したすべての6to4クライアントの65％から80％がIPv4を使用して接続を成功させることができ、残りは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
この形式の6to4接続障害のいくつかの理由が提供されています。1つは、6to4アドレスに埋め込まれたプライベートIPv4アドレスを使用して、6to4トンネルのリターンパスを実行不可能にすることです。2つ目は、IPプロトコル41を使用する着信IPパケットをドロップするローカルフィルターとファイアウォールの使用です。普及していた場合、失敗した6to4接続のかなりの割合が、個人使用（RFC 1918）アドレス範囲から引き出される埋め込みIPv4アドレスを使用するか、RFC 3056に反して、または発表されていないアドレスから使用することを期待するのが合理的です。インターネットのIPv4インタードメインルーティングテーブル。どちらの症例も、Hustonが実施した実験でかなりの量に観察されませんでした。さらに、実験
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.
条件は、デュアルスタックサーバーのネイティブIPv4ソースアドレスまたは192.88.99.1のIPv4ソースアドレスのいずれかを使用して、リターン6to4トンネルを使用するために変化しました。これら2つの構成の間に6to4接続の故障率に変更は観察されませんでした。ただし、他のオペレーターは、ユーザーサイトでのステートフルファイアウォールによって引き起こされるネイティブアドレスから返信する際に重大な問題を報告しています。サーバーがリターンパスに独自の6to4リレーを使用したことを考えると、成功したIPv4接続と失敗した6to4接続の間のIPパケット自体の唯一の違いは、成功したIPv4接続と成功したIPv4接続の6（TCP）でした。失敗した6to4接続の41（IPv6ペイロード）。これらの実験からの推論は、6to4接続の接続障害率が高い理由の1つは、プロトコル41で着信パケットをブロックするエンドユーザーに近いローカルフィルターの使用であることです。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を使用して接続を成功させる能力によって効果的にマスクされました。この場合、クライアントシステムへの唯一の効果は、クライアントのシステムが6to4接続試行でタイミングを出したため、7〜20秒の接続の遅延でした（[Eyeballs-IPV6]を参照）。
This experience, and further analysis, shows that specific operational problems with Anycast 6to4 include:
この経験とさらなる分析は、Anycast 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.
ユーザーのISPが192.88.99.0/24へのルートを受け入れているため、このクラスの問題が発生します。ユーザーサイトまたはISPがアウトバウンドプロトコル41トラフィックを削除しているか、上流のオペレーターがユーザーのISPから着信6to4パケットを受け入れたくない。後者は、ルーター6to4（RFC 3056で「リレーしたくない」と呼ばれるルーター6to4の設計と表面的に互換性があります。ただし、IPv4で192.88.99.0/24へのルートを発表するという単純な事実は、RFC 3068で説明されている動作と組み合わせて、IPv4ルートを受信するすべての6to4サイトにIPv6のデフォルトルートを発表することに相当します。これは、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:
この問題は3つの変数によって複雑になります。プロトコル41フィルターを適用するファイアウォールは、ステートレスまたはステートフルである場合があります。リレーは、ネイティブIPv4アドレスまたは192.88.99.1からパケットを調達する場合があります。リレーからのパケットは、IPv4イングレスフィルタリングの対象となる場合があります。プロトコル41フィルターがステートレスの場合、6to4は成功しません。ステートフルの場合、ファイアウォールは、同じポートのアウトバウンドトラフィックでは見られないアドレスからインバウンドパケットをドロップします。この場合、パケットが192.88.99.1から供給されている場合にのみ6to4が成功します。リレーがイングレスフィルタリングの対象となる場合、ネイティブIPv4アドレスからのパケットのみを送信できます。したがって、成功できる組み合わせは3つしかありません。
1. No protocol 41 filter, with the relay using its native IPv4 source address.
1. プロトコル41フィルターはありません。リレーは、ネイティブIPv4ソースアドレスを使用しています。
2. No protocol 41 filter, with the relay using the anycast IPv4 source address and with no ingress filter.
2. プロトコル41フィルターはありません。リレーは、Anycast IPv4ソースアドレスを使用し、イングレスフィルターを使用していません。
3. A stateful protocol 41 firewall, with the relay using the anycast IPv4 source address and with no ingress filter.
3. Stateful Protocol 41 Firewall。リレーは、Anycast 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,
3. リターレイなし：アウトバウンドブラックホールの問題が発生しない場合、つまり、発信パケットが意図したネイティブIPv6宛先に到達した場合、ターゲットシステムは、上記の例では2002：C000：2AA :: 123に返信パケットを送信します。その後、2002年::/16は、ルーティングに成功する場合とできない場合があります。ルーティングされていない場合、パケットはドロップされます（うまくいけば、「宛先の到達不可能」で）。RFC 3056によると、不本意なリレーは「2002 ::ネイティブIPv6ドメインにプレフィックスをルーティングしてはいけません」。したがって、
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.
逆に、このプレフィックスが宣伝されている場合、リレーはソースと宛先に関係なくパケットをリレーする必要があります。ただし、実際には、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.
ネイティブIPv6の宛先が2002年::/16へのルートがない場合でも、不本意なリレーへのルートがあることが判明した場合、効果は同じです。すべての返品IPv6パケットはブラックホールです。この問題の有病率の直接的な証拠はありませんが、実際には確かに存在します。
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 Exchangeが機能している場合でも、フルサイズのペイロードを備えたTCPパケットは単に失われる可能性があります。この問題は、TCPの最大セグメントサイズ（MSS）交渉メカニズムの障害により、明らかに悪化しているようです[RFC2923]。クライアントからサーバーへの標準的な「ping」が成功するため、これらの障害は情報に基づいたユーザーにさえ戸惑っています。これは小さなパケットを生成し、Syn/ACK交換を成功させることができるためです。また、障害は一部のパスで発生する可能性がありますが、他のパスでは発生する可能性があるため、ユーザーは1つのサイトからWebページを取得できますが、別のサイトのみを取得できます。
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.
さらに、ルーターで6to4が有効になり、結果のプレフィックスをLANに宣伝しているが、小さいMTUも宣伝していない場合、問題があります。この場合、TCP MSS交渉は間違いなく失敗します。
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
7. 偽の住所の失敗：設計により、6to4は機能せず、利用可能なV4ADDRがプライベートアドレスである場合、それ自体をアクティブにしません[RFC1918]。ただし、利用可能なV4ADDRが「ボゴン」、つまり使用されているグローバルアドレスである場合、それは機能しません。
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.
プライベートアドレスとしてのオペレーター。これの一般的なケースは、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.
この障害モードは、ISPが顧客とインターネットの間でキャリアグレードのNAT [CGN]を動作し、グローバルなパブリックアドレススペースを使用するためのプライベートスペースのように使用している場合にも発生します。
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実装：利用可能なIPv4アドレスがRFC 1918アドレスである場合でも、約6to4実装が自分自身をアクティブ化しようとしていることが報告されています。これは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. 困難な障害診断：上記のすべての障害モードの存在は、それ自体の問題を引き起こします。特に、ユーザーが報告した唯一の症状がIPv4へのフォールバックの前の長いタイムアウトによって引き起こされるWebページへのゆっくりとしている場合。Anycastルーティングの問題と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.
上記の問題の実際的な影響は、Anycast 6to4の使用がかなり成功しているため、決して普遍的ではありませんが、デュアルスタックコンテンツサーバー[Anderson]への接続の試みの1％の損失の一部で測定されています。これは、クライアントホストのごく一部が6to4を使用して接続しようとし、これらの最大20％が上記の障害モードの1つを経験しようとしているためです。これは低いように見えますが、コンテンツプロバイダーにとって大きな経済的影響になります。また、IPv4接続[Eyeballs-IPV6]へのフォールバックによって引き起こされる低い応答時間に不満を抱いているエンドユーザーは、付随するコストでヘルプデスクの呼び出しを生成する可能性が高いと考えられています。
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
偶然6to4によって引き起こされるかなり異なる運用上の問題は、サウサンプトン大学でティムチャウンズとジェームズモースが行った観察によると、他のサイトでは、Rogueルーターの広告[RFC6104]が2002 ::/16プレフィックスを伝えることが多いことです。これは、ローカルIPv6ルーターまたは接続共有デバイスとして機能するデバイスによる不正行為によるものであるように見えますが、間違ったインターフェイスでルーター広告（RA）メッセージを発行します。このようなデバイスは、インターネットへのアップストリームリンクを介してIPv6接続を取得した場合、インターネット接続を共有することを目的としたノードへの下流のリンクに対応するRAメッセージのみを発行する必要があります。上流のリンクでRAメッセージを発行すると、他のIPv6ホストが妨害されます
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ルーティングが有効になっている場合、結果のRogue 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.
Anycast 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. 同様に、ホストオペレーティングシステムは、デフォルトでAnycast 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実装では、アドレス選択に関する更新されたIETF推奨事項[RFC3484-Revise]を採用する必要があります。
5. 6to4 relay implementations must carefully follow Section 3.2 of [RFC4213] to ensure correct handling of MTU issues.
5. 6TO4リレーの実装は、[RFC4213]のセクション3.2に従って、MTUの問題の正しい処理を確保する必要があります。
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ルーターまたは接続共有の実装は、Rogue Ras [RFC6104]の発行を避けなければなりません。さらに、インターネット接続共有目的のために6to4がノードによって有効になっている場合、ノードは[RFC4191]をサポートしている場合、ルーター広告ルーターの優先ビットを11に設定する必要があります（低好み）。
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:
ユーザーによって（おそらく知らないうちに）展開されたAnycast 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へのルートがありますか？（これは、明示的なルート、またはデフォルトのアップストリームプロバイダーに明示的なルートがあるという知識を意味します。デフォルトのルートはカウントされません！）
2. If so, is it functional and stable?
2. もしそうなら、それは機能的で安定していますか？
3. If so, is the ping time reasonably short?
3. もしそうなら、ping時間はかなり短いですか？
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リレー資格も実行されます。たとえば、1つのホスト実装（Windows）は、ホップリミット= 1でICMPV6エコーリクエストをリレーに送信し、応答またはホップ制限がエラーを超えたことを期待することにより、プロトコル41の到達可能性をテストします。応答の欠如は、6to4リレーが機能しないことを示しているため、6to4がオフになっている[Savola]。
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を実行しようとしているユーザーに害を及ぼし、6to4を実行しようとしているユーザーに害を及ぼすため、それ自体でこれを行うことは悪い習慣です。戦略的ソリューションは、ネイティブIPv6を展開し、プロトコル41を冗長化することです。短期的には、特定のユーザーにプロトコル41を許可しながら、上記の適切なICMP応答を返すことで実験を奨励することができます。残念ながら、これが行われない場合、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.
Operatorsは、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もボーゴンアドレスもありません）、このアドレススペースとインターネットのグローバルアドレススペースの間でキャリアグレード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
逆説的に、このカテゴリの演算子は、そのようなメッセージが求めているデバイスから表示される可能性があるため、Rogue 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とユーザーデバイスを混同します。最終的に、IETFソースアドレス検証改善（SAVI）ワーキンググループによって設計されている対策は、この問題を支援します。短期的には、IPv4のみのオペレーターは、アクセス機器にIPv6 EtherType（0x86DD）を使用してパケットをフィルタリングすることを選択できます。これにより、Rogue 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-in-IPV4トンネルを介してIPv6オペレーターに接続された6to4リレーをインストールすることを選択しています。セクション4.4のルーティングガイドラインが適用されます。ただし、たとえTunneledであっても、関心のある顧客に本物の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.
このようなオペレーターは、次の2つのカテゴリ（トランジットプロバイダーまたはコンテンツプロバイダー）のいずれかに自動的に分類される可能性があるため、セクション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]を使用してRogue RAメッセージから身を守る必要があるかどうかを検討する必要があります。RAガードが利用できない場合、LANごとに少なくとも1つの正当なIPv6ルーターが[RFC4191]をサポートし、ルーター広告ルーターの優先ビットを01（高い選好）に設定する場合、場合によっては役立ちます。最終的に、IETFソースアドレス検証改善（SAVI）ワーキンググループによって設計されている対策は、この問題を支援します。
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.
Transit ISPにはIPv6接続があると想定しています。すべてのクライアントネットワークに対するAnycast 6to4のマイナスの影響を減らすために、それぞれがAnycast 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）は、顧客の利益のためにAnycast 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に向けてすべてのトラフィックを受け入れる必要があるため、この発表によって到達したスコープは慎重に計画する必要があります。Transit 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ソースアドレスの選択が重要です。最良の選択は、イングレスフィルタリングが問題でない限り、リレーのユニキャストIPv4アドレスではなく、192.88.99.1である可能性があります。これは、ユーザーがステートフルファイアウォールの背後にいる場合、失敗を回避するためです。
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.)
4. リレーは、IPv4プロトコル41にカプセル化されたICMPV6エコー要求に正しく応答できる必要があります。通常、外部宛先アドレス192.88.99.1および内部宛先アドレス2002：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エラー生成しきい値があることも必要です。忙しいリレーの場合、1秒あたり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接続があり、サーバーがデュアルスタックされていると想定しています。以下は、コンテンツサーバーに適用されますが、Webホスティングサーバー、コンテンツ配信ネットワークの一部を形成するサーバー、サーバーファームの前のロードバランサー、およびHTTPキャッシュにも同様です。Anycast 6to4で構成されたクライアントホストがサーバーにIPv6パケットを送信することに成功したが、6to4戻りパスが上記のように失敗する状況を回避する必要があります。これを回避するには、ローカルに配置された6to4リレーが必要です。大規模なコンテンツプロバイダーは、独自のリレーを操作することをお勧めします。いずれにせよ、ISPはそうする必要があります。コンテンツサーバーからリレーまでの2002 ::/16ルートが必要です。前のセクションで述べたように、2002年に到着するトラフィックを中継する必要があるため、対応するルート広告は慎重にスコープする必要があります。
Such a relay may be dedicated entirely to return traffic, in which case, it need not respond to the 6to4 anycast address.
このようなリレーは、完全にトラフィックを返すことに専念する可能性があります。その場合、6to4 Anycastアドレスに応答する必要はありません。
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
それにもかかわらず、リレーが6to4ユーザーに6to4パケットを送り返すと、IPv4ソースアドレスとして192.88.99.1を持つ必要があることを保証するのが最も賢いようです（リレーのユニキャストIPv4アドレスではありません）。上記のように、これは、ユーザーがUDPパケットをドロップしていないステートフルなファイアウォールの背後にいる場合、問題を回避するためです。
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.
アウトバウンドトラフィックで見られました。ただし、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.
慎重なエンジニアリングがなければ、リターンパスを可能な限り短くすることは何もありません。コンテンツプロバイダーがリレーへの短いパスを持ち、リレーにはISPの境界への短いパスがあるように、2002年の広告の範囲を2002年の広告の範囲をアレンジすることが非常に望ましい::/16です。2002年の広告をBGP4に撮影することに注意する必要があります。それらは交通磁石になります。コンテンツプロバイダーの顧客を備えたすべての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の使用が許可されない場合があります。）詳細については、[Huston-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宛先のトラフィックも中継する必要があるため、これは非常に妥協できません。したがって、192.88.99.1を介して到達可能ではありません。また、6to4アドレスのAAAAレコードを確実に作成するべきではありません。InboundIPv6アクセスはネイティブである必要があり、6to4アドレスを宣伝する可能性があります。
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].
上記のPATH MTUの問題を回避するには、コンテンツサーバーもIPv6 MTUを安全な価値に設定する必要があります。経験から、1280バイト（IPv6に許可される最小）が推奨されます。繰り返しますが、[Huston-B]を参照してください。
Of course, ICMPv6 "Packet Too Big" must not be blocked or rate-limited anywhere [RFC4890].
もちろん、ICMPV6「パケットが大きすぎる」は、どこでもブロックまたはレート制限されてはなりません[RFC4890]。
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.
トンネルブローカー[RFC3053]、第6 [RFC5969]、レイヤー2トンネリングプロトコルバージョン2（L2TPV2）ハブアンドスポーク[RFC5571]など、さまざまな方法があります。サブスクライバーが通常のプロバイダーベースのグローバルIPv6プレフィックスの下でIPv6プレフィックスを取得する管理方法。6to4で説明されている問題のほとんどは、これらのシナリオでは発生しません。ただし、ファイアウォールの背後にあるクライアントが使用するIPv6-in-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-in-IPV4トンネルのセキュリティ問題に関する一般的な議論があり、[トンネルループ]は悪意のあるループの可能性について説明しています。[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.
有用なコメントと貢献は、エミール・アベン、ミカエル・アブラハムソン、トーレ・アンダーソン、ハーミン・アンガウィジャヤ、ジャック・ベイツ、キャメロン・バーン、ティム・チャウン、レミ・デスプレス、ジェイソン・フェスラー、ウェス・ジョージ、フィリップ・ホンバーグ、レイ・ハンター、レイ・ハンター、ジェフ・ハストン、エリック・クリンによって行われました。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など。
[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月。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[RFC3068] Huitema、C。、「6to4リレールーターのAnycast Prefix」、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>.
[Aben] Aben、E。、「6to4-それは本当に悪いことですか？」、2010年、<ht tps：//labs.ripe.net/members/emileaben/ 6to4-how-bad-is-it really>。
[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] Perreault、S.、Yamagata、I.、Miyakawa、S.、Nakagawa、A。、およびH. Ashida、「Carrier Grade 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.
[Eyeballs-IPv6] Wing、D。and A. Yourtchenko、「Happy Eyeballs：Dual Stack Hostsの成功へのトレンド」、2010年10月の作業。
[HISTORIC] Troan, O., "Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status", Work in Progress, June 2011.
[Historic] Troan、O。、「IPv4クラウド（6to4）を介してIPv6ドメインの接続を歴史的ステータスに移動するようリクエスト」、2011年6月、進行中の作業。
[Huston-a] Huston, G., "Flailing IPv6", 2010, <http:// www.potaroo.net/ispcol/2010-12/6to4fail.html>.
[Huston-A] Huston、G。、 "Flailing 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>.
[Huston-B] Huston、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.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923] Lahey、K。、「Path MTU DiscoveryのTCP問題」、RFC 2923、2000年9月。
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3053] Durand、A.、Fasano、P.、Guardini、I。、およびD. Lento、「IPv6 Tunnel Broker」、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] Matsumoto、A.、Kato、J.、Fujisaki、T。、およびT. Chown、「RFC 3484 IPv6のデフォルトアドレス選択」、2011年7月の作業。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704] Baker、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. Patel、「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. Thaler、「デフォルトのルーター設定とより固有のルート」、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. Gilligan、「IPv6ホストとルーターの基本的な遷移メカニズム」、RFC 4213、2005年10月。
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
[RFC4890] Davies、E。およびJ. Mohacsi、「ファイアウォールでICMPV6メッセージをフィルタリングするための推奨」、RFC 4890、2007年5月。
[RFC5158] Huston, G., "6to4 Reverse DNS Delegation Specification", RFC 5158, March 2008.
[RFC5158] Huston、G。、「6to4 Reverse DNS Dedegation Specification」、RFC 5158、2008年3月。
[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.、Dos Santos、M.、Stevant、B.、Toutain、L。、およびJ. Tremblay、 "Softwire Hub and Speake Deployment Framework with Layer 2 Tunneling Protocolバージョン2（L2TPV2（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、「IPv6インフラストラクチャのIPv6迅速な展開（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、「Rogue 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] Levy-Abegnoli、E.、Van de Velde、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] Krishnan、S.、Thaler、D。、およびJ. Hoagland、「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] Ford、M.、Boucadair、M.、Durand、A.、Levis、P。、およびP. Roberts、「IPアドレス共有の問題」、RFC 6269、2011年6月。
[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.
[Tunnel-Loops] Nakibly、G。およびF. Templin、「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