[要約] RFC 6732は、6to4プロバイダ管理トンネルの仕様を定義しています。その目的は、IPv6ネットワークへのアクセスを提供するために、IPv4ネットワーク上でトンネリングを行うことです。
Independent Submission V. Kuarsingh, Ed.
Request for Comments: 6732 Rogers Communications
Category: Informational Y. Lee
ISSN: 2070-1721 Comcast
O. Vautrin
Juniper Networks
September 2012
6to4 Provider Managed Tunnels
6to4プロバイダー管理トンネル
Abstract
概要
6to4 Provider Managed Tunnels (6to4-PMT) provide a framework that can help manage 6to4 tunnels operating in an anycast configuration. The 6to4-PMT framework is intended to serve as an option for operators to help improve the experience of 6to4 operation when conditions of the network may provide sub-optimal performance or break normal 6to4 operation. 6to4-PMT supplies a stable provider prefix and forwarding environment by utilizing existing 6to4 relays with an added function of IPv6 Prefix Translation. This operation may be particularly important in NAT444 infrastructures where a customer endpoint may be assigned a non-RFC1918 address, thus breaking the return path for anycast-based 6to4 operation. 6to4-PMT has been successfully used in a production network, implemented as open source code, and implemented by a major routing vendor.
6to4プロバイダー管理トンネル（6to4-PMT）は、エニーキャスト構成で動作する6to4トンネルの管理に役立つフレームワークを提供します。 6to4-PMTフレームワークは、ネットワークの状態が最適ではないパフォーマンスを提供したり、通常の6to4操作を中断したりする場合に、オペレーターが6to4操作のエクスペリエンスを向上させるためのオプションとして機能することを目的としています。 6to4-PMTは、IPv6プレフィックス変換の追加機能を備えた既存の6to4リレーを利用して、安定したプロバイダープレフィックスと転送環境を提供します。この操作は、カスタマーエンドポイントに非RFC1918アドレスが割り当てられる可能性があるNAT444インフラストラクチャで特に重要であり、エニーキャストベースの6to4操作のリターンパスを壊します。 6to4-PMTは、実稼働ネットワークで成功裏に使用され、オープンソースコードとして実装され、主要なルーティングベンダーによって実装されています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc6732.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6732で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................3
2. Motivation ......................................................3
3. 6to4 Provider Managed Tunnels ...................................5
3.1. 6to4 Provider Managed Tunnel Model .........................5
3.2. Traffic Flow ..............................................5
3.3. Prefix Translation ........................................6
3.4. Translation State .........................................7
4. Deployment Considerations and Requirements ......................7
4.1. Customer Opt-Out ...........................................7
4.2. Shared CGN Space Considerations ............................8
4.3. End-to-End Transparency ....................................8
4.4. Path MTU Discovery Considerations ..........................9
4.5. Checksum Management ........................................9
4.6. Application Layer Gateways .................................9
4.7. Routing Requirements .......................................9
4.8. Relay Deployments .........................................10
5. Security Considerations ........................................10
6. Acknowledgements ...............................................10
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................11
6to4 [RFC3056] tunneling, along with the anycast operation described in [RFC3068], is widely deployed in modern Operating Systems and off-the-shelf gateways sold throughout retail and Original Equipment Manufacturer (OEM) channels. Anycast-based 6to4 [RFC3068] allows for tunneled IPv6 connectivity through IPv4 clouds without explicit configuration of a relay address. Since the overall system utilizes anycast forwarding in both directions, flow paths are difficult to determine, tend to follow separate paths in either direction, and often change based on network conditions. The return path is normally uncontrolled by the local operator and can contribute to poor performance for IPv6 and can also act as a breakage point. Many of the challenges with 6to4 are described in [RFC6343]. A specific critical use case for problematic anycast 6to4 operation is related to conditions in which the consumer endpoints are downstream from a northbound Carrier-Grade NAT (CGN) [RFC6264] function when assigned non-RFC1918 IPv4 addresses, which are not routed on interdomain links.
6to4 [RFC3056]トンネリングは、[RFC3068]で説明されているエニーキャストオペレーションとともに、最新のオペレーティングシステムや、小売および相手先ブランド供給（OEM）チャネル全体で販売されている既成のゲートウェイに広く展開されています。エニーキャストベースの6to4 [RFC3068]では、リレーアドレスを明示的に構成しなくても、IPv4クラウドを介したIPv6接続のトンネル化が可能です。システム全体がエニーキャスト転送を両方向で利用するため、フローパスを特定することは困難であり、どちらの方向でも別のパスをたどる傾向があり、ネットワークの状態に基づいて変化することがよくあります。通常、リターンパスはローカルオペレーターによって制御されておらず、IPv6のパフォーマンス低下の原因となる可能性があり、破損点としても機能する可能性があります。 6to4の課題の多くは[RFC6343]で説明されています。問題のあるエニーキャスト6to4操作の特定の重要なユースケースは、ドメイン間リンクでルーティングされない非RFC1918 IPv4アドレスが割り当てられているときに、コンシューマエンドポイントがノースバウンドキャリアグレードNAT（CGN）[RFC6264]機能の下流にある状態に関連しています。 。
Operators that are actively deploying IPv6 networks and operate legacy IPv4 access environments may want to utilize the existing 6to4 behavior in customer site resident hardware and software as an interim option to reach the IPv6 Internet in advance of being able to offer full native IPv6. Operators may also need to address the brokenness related to 6to4 operation originating from behind a provider NAT function. 6to4-PMT offers an operator the opportunity to utilize IPv6 Prefix Translation to enable deterministic traffic flow and an unbroken path to and from the Internet for IPv6-based traffic sourced originally from these 6to4 customer endpoints.
IPv6ネットワークを積極的に展開し、レガシーIPv4アクセス環境を運用しているオペレーターは、完全なネイティブIPv6を提供する前に、IPv6インターネットに到達するための暫定的なオプションとして、顧客サイト常駐ハードウェアおよびソフトウェアの既存の6to4動作を利用することができます。オペレーターは、プロバイダーNAT機能の背後から発生する6to4操作に関連する問題に対処する必要がある場合もあります。 6to4-PMTにより、オペレーターはIPv6プレフィックス変換を利用して、これらの6to4カスタマーエンドポイントから発信されたIPv6ベースのトラフィックの確定的トラフィックフローとインターネットへの途切れのないパスを実現できます。
6to4-PMT translates the prefix portion of the IPv6 address from the 6to4-generated prefix to a provider-assigned prefix that is used to represent the source. This translation will then provide a stable forward and return path for the 6to4 traffic by allowing the existing IPv6 routing and policy environment to control the traffic. 6to4-PMT is primarily intended to be used in a stateless manner to maintain many of the elements inherent in normal 6to4 operation. Alternatively, 6to4-PMT can be used in a stateful translation mode should the operator choose this option.
6to4-PMTは、IPv6アドレスのプレフィックス部分を6to4で生成されたプレフィックスから、ソースを表すために使用されるプロバイダー割り当てのプレフィックスに変換します。この変換により、既存のIPv6ルーティングとポリシー環境がトラフィックを制御できるようになり、6to4トラフィックに安定したフォワードパスとリターンパスが提供されます。 6to4-PMTは主に、通常の6to4操作に固有の要素の多くを維持するためにステートレスな方法で使用することを目的としています。または、オペレーターがこのオプションを選択した場合、6to4-PMTをステートフル変換モードで使用できます。
Many operators endeavor to deploy IPv6 as soon as possible so as to ensure uninterrupted connectivity to all Internet applications and content through the IPv4 to IPv6 transition process. The IPv6 preparations within these organizations are often faced with both financial challenges and timing issues related to deploying IPv6 to the network edge and related transition technologies. Many of the new technologies available for IPv4 to IPv6 transition will require the replacement of the organization's Customer Premises Equipment (CPE) to support technologies like IPv6 Rapid Deployment (6RD) [RFC5969], Dual-Stack Lite [RFC6333], and native dual-stack.
多くの事業者は、IPv4からIPv6への移行プロセスを通じて、すべてのインターネットアプリケーションとコンテンツへの接続が中断されないように、できるだけ早くIPv6を導入するよう努めています。これらの組織内のIPv6の準備は、多くの場合、ネットワークエッジへのIPv6の導入と関連する移行テクノロジに関連する財政上の課題とタイミングの問題の両方に直面しています。 IPv4からIPv6への移行に使用できる新しいテクノロジーの多くは、IPv6 Rapid Deployment（6RD）[RFC5969]、Dual-Stack Lite [RFC6333]、およびネイティブデュアル-のようなテクノロジーをサポートするために、組織の顧客宅内機器（CPE）の交換が必要になります。スタック。
Operators face a number of challenges related to home equipment replacement. Operator-initiated replacement of this equipment will take time due to the nature of mass equipment refresh programs or may require the consumer to replace their own gear. Replacing consumer owned and operated equipment, compounded by the fact that there is also a general unawareness of what IPv6 is, also adds to the challenges faced by operators. It is also important to note that 6to4 is present in much of the equipment found in networks today that do not as of yet, or will not, support 6RD and/or native IPv6.
オペレーターは、住宅設備の交換に関連する多くの課題に直面しています。この機器のオペレーターが開始した交換は、大量の機器更新プログラムの性質上、時間がかかるか、または消費者が自分のギアを交換する必要がある場合があります。 IPv6が何であるかについての一般的な認識がないこともあり、消費者が所有および操作する機器を交換することも、オペレーターが直面する課題に追加されます。 6to4は、現在ネットワークで見つかっている多くの機器に存在し、現時点ではまだ6RDやネイティブIPv6をサポートしていないか、サポートしないことに注意することも重要です。
Operators may still be motivated to provide a form of IPv6 connectivity to customers and would want to mitigate potential issues related to IPv6-only deployments elsewhere on the Internet. Operators also need to mitigate issues related to the fact that 6to4 operation is often on by default, and may be subject to erroneous behavior. The undesired behavior may be related to the use of non-RFC1918 addresses on CPE equipment that operate behind large operator NATs or other conditions as described in a general advisory as laid out in [RFC6343].
オペレーターは依然として顧客にIPv6接続の形式を提供する動機があり、インターネット上の他の場所でのIPv6のみの展開に関連する潜在的な問題を緩和したいと思うでしょう。オペレーターは、6to4操作がデフォルトでオンになっていることが多く、誤った動作をする可能性があるという事実に関連する問題を軽減する必要もあります。望ましくない動作は、[RFC6343]で説明されている一般的な勧告で説明されているように、大規模なオペレーターNATまたは他の条件の背後で動作するCPE機器での非RFC1918アドレスの使用に関連している可能性があります。
6to4-PMT allows an operator to help mitigate such challenges by leveraging the existing 6to4 deployment base, while maintaining operator control of access to the IPv6 Internet. It is intended for use when better options, such as 6RD or native IPv6, are not yet viable. One of the key objectives of 6to4-PMT is to also help reverse the negative impacts of 6to4 in CGN environments. The 6to4-PMT operation can also be used immediately with the default parameters that are often enough to allow it to operate in a 6to4-PMT environment. Once native IPv6 is available to the endpoint, the 6to4-PMT operation is no longer needed and will cease to be used based on correct address selection behaviors in end hosts [RFC6724].
6to4-PMTを使用すると、オペレーターは、IPv6インターネットへのアクセスのオペレーター制御を維持しながら、既存の6to4展開ベースを活用して、このような課題を軽減できます。 6RDやネイティブIPv6などのより良いオプションがまだ実行可能でない場合に使用することを目的としています。 6to4-PMTの主要な目的の1つは、CGN環境における6to4の悪影響を逆転させることも支援することです。 6to4-PMT操作は、6to4-PMT環境での操作を可能にするのに十分な場合が多いデフォルトのパラメーターですぐに使用することもできます。エンドポイントでネイティブIPv6が利用可能になると、6to4-PMT操作は不要になり、エンドホストでの正しいアドレス選択動作に基づいて使用されなくなります[RFC6724]。
6to4-PMT thus helps operators remove the impact of 6to4 in CGN environments, deals with the fact that 6to4 is often on by default, and allows access to IPv6-only endpoints from IPv4-only addressed equipment. Additionally, it provides relief from many challenges related to mis-configurations in other networks that control return flows via foreign relays. Due to the simple nature of 6to4-PMT, it can also be implemented in a cost-effective and simple manner, allowing operators to concentrate their energy on deploying native IPv6.
したがって、6to4-PMTは、オペレーターがCGN環境で6to4の影響を取り除くのに役立ち、6to4がデフォルトでオンになっていることが多いという事実に対処し、IPv4のみのアドレス指定された機器からIPv6のみのエンドポイントへのアクセスを許可します。さらに、外部リレーを介してリターンフローを制御する他のネットワークの設定ミスに関連する多くの課題から解放されます。 6to4-PMTのシンプルな性質により、費用対効果が高くシンプルな方法で実装することもでき、オペレーターはネイティブIPv6の展開にエネルギーを集中できます。
The 6to4 managed tunnel model behaves like a standard 6to4 service between the customer IPv6 host or gateway, and the 6to4-PMT Relay (within the provider domain). The 6to4-PMT Relay shares properties with 6RD [RFC5969] by decapsulating and forwarding encapsulated IPv6 flows within an IPv4 packet to the IPv6 Internet. The model provides an additional function that translates the source 6to4 prefix to a provider-assigned prefix that is not found in 6RD [RFC5969] or traditional 6to4 operation.
6to4マネージドトンネルモデルは、顧客のIPv6ホストまたはゲートウェイと6to4-PMTリレー（プロバイダードメイン内）の間の標準の6to4サービスのように動作します。 6to4-PMTリレーは、IPv4パケット内のカプセル化されたIPv6フローをカプセル化解除してIPv6インターネットに転送することにより、6RD [RFC5969]とプロパティを共有します。このモデルは、ソース6to4プレフィックスを、6RD [RFC5969]または従来の6to4操作にはないプロバイダー割り当てのプレフィックスに変換する追加機能を提供します。
The 6to4-PMT Relay is intended to provide a stateless (or stateful) mapping of the 6to4 prefix to a provider supplied prefix.
6to4-PMTリレーは、プロバイダーが提供するプレフィックスへの6to4プレフィックスのステートレス（またはステートフル）マッピングを提供することを目的としています。
| 6to4-PMT Operation |
| 6to4-PMT操作|
+-----+ 6to4 Tunnel +--------+ +------+ IPv6 +----+
| CPE |-------------|6to4 BR |--| PT66 |--------- |Host|
+-----+ IPv4 +--------+ +------+ Provider +----+
Network Prefix
Unified or Separate
Functions/Platforms
Figure 1: 6to4-PMT Functional Model
図1：6to4-PMT機能モデル
This mode of operation is seen as beneficial when compared to broken 6to4 paths and/or environments where 6to4 operation may be functional but highly degraded.
この動作モードは、6to4の動作が機能しているが非常に劣化している可能性のある壊れた6to4パスや環境と比較すると、有益であると見なされています。
Traffic in the 6to4-PMT model is intended to be controlled by the operator's IPv6 peering operations. Egress traffic is managed through outgoing routing policy, and incoming traffic is influenced by the operator-assigned prefix advertisements using normal interdormain routing functions.
6to4-PMTモデルのトラフィックは、オペレーターのIPv6ピアリング操作によって制御されることを目的としています。出力トラフィックは送信ルーティングポリシーを通じて管理され、受信トラフィックは、通常のインターメインルーティング機能を使用して、オペレーターが割り当てたプレフィックス通知の影響を受けます。
The routing model is as predictable as native IPv6 traffic and legacy IPv4-based traffic. Figure 2 provides a view of the routing topology needed to support this relay environment. The diagram references PrefixA as 2002::/16 and PrefixB as the example 2001:db8::/32.
ルーティングモデルは、ネイティブIPv6トラフィックやレガシーIPv4ベースのトラフィックと同じくらい予測可能です。図2は、このリレー環境をサポートするために必要なルーティングトポロジを示しています。この図では、PrefixAを2002 :: / 16として、PrefixBを例2001：db8 :: / 32として参照しています。
| 6to4 IPv4 Path | Native IPv6 Path |
----------- ----------- -------------
/ IPv4 Net \ / IPv6 Net \ / IPv6 Internet \
+------+ +--------+ +-------+ +---------+
| CPE | PrefixA |6to4-PMT| PrefixB |Peering| |IPv6 HOST|
+------+ +--------+ +-------+ +---------+
\ / \ / \ /
---------- ------------ --------------
IPv4 6to4 IPv6 Provider IPv6 Prefix Anycast Prefix Propagation
IPv4 6to4 IPv6プロバイダーIPv6プレフィックスエニーキャストプレフィックス伝搬
Figure 2: 6to4-PMT Flow Model
図2：6to4-PMTフローモデル
Traffic between two 6to4-enabled devices would use the IPv4 path for communication according to [RFC3056] unless the local host still prefers traffic via a relay. 6to4-PMT is intended to be deployed in conjunction with the 6to4 relay function in an attempt to help simplify its deployment. The model can also provide the ability for an operator to forward both 6to4-PMT (translated) and normal 6to4 flows (untranslated) simultaneously based on configured policy.
2つの6to4対応デバイス間のトラフィックは、ローカルホストがリレー経由のトラフィックを優先しない限り、[RFC3056]に従って通信にIPv4パスを使用します。 6to4-PMTは、6to4リレー機能と組み合わせて配置し、その配置を簡略化することを目的としています。このモデルは、オペレーターが、構成されたポリシーに基づいて、6to4-PMT（変換済み）フローと通常の6to4フロー（非変換済み）の両方を同時に転送する機能も提供します。
IPv6 Prefix Translation is a key part of the system as a whole. The 6to4-PMT framework is a combination of two concepts: 6to4 [RFC3056] and IPv6 Prefix Translation. IPv6 Prefix Translation, as used in 6to4-PMT, has some similarities to concepts discussed in [RFC6296]. 6to4-PMT would provide prefix translation based on specific rules configured on the translator that maps the 6to4 2002::/16 prefix to an appropriate provider assigned prefix. In most cases, a ::/32 prefix would work best in 6to4-PMT that matches common Regional Internet Registry (RIR) prefix assignments to operators.
IPv6プレフィックス変換は、システム全体の重要な部分です。 6to4-PMTフレームワークは、6to4 [RFC3056]とIPv6プレフィックス変換という2つの概念の組み合わせです。 6to4-PMTで使用されるIPv6プレフィックス変換は、[RFC6296]で説明されている概念といくつかの類似点があります。 6to4-PMTは、6to4 2002 :: / 16プレフィックスを適切なプロバイダーによって割り当てられたプレフィックスにマップするトランスレーターで構成された特定のルールに基づいて、プレフィックス変換を提供します。ほとんどの場合、:: / 32プレフィックスは、オペレーターへの一般的な地域インターネットレジストリ（RIR）プレフィックス割り当てと一致する6to4-PMTで最適に機能します。
The provider can use any prefix mapping strategy they so choose, but the simpler the better. Simple direct bitmapping can be used, or more advanced forms of translation should the operator want to achieve higher address compression. More advanced forms of translation may require the use of stateful translation.
プロバイダーは、選択した任意のプレフィックスマッピング戦略を使用できますが、シンプルな方が良いです。単純な直接ビットマップを使用できます。または、オペレーターがより高いアドレス圧縮を実現したい場合は、より高度な形式の変換を使用できます。より高度な形式の翻訳では、ステートフル翻訳の使用が必要になる場合があります。
Figure 3 shows a 6to4 Prefix with a Subnet-ID of "0000" mapped to a provider-assigned, globally unique prefix (2001:db8::/32). With this simple form of translation, there is support for only one Subnet-ID per provider-assigned prefix. In characterization of deployed OSs and gateways, a Subnet-ID of "0000" is the most common default case followed by Subnet-ID "0001". Use of the Subnet-ID can be referenced in [RFC4291]. It should be noted that in normal 6to4 operation, the endpoint (network) has access to 65,536 (16-bits) Subnet IDs. In the 6to4-PMT case as described above using the mapping in Figure 3, all but the one Subnet-ID used for 6to4-PMT would still operate under normal 6to4 operation.
図3は、プロバイダーが割り当てたグローバルに一意のプレフィックス（2001：db8 :: / 32）にマップされた、サブネットIDが「0000」の6to4プレフィックスを示しています。この単純な形式の変換では、プロバイダーが割り当てたプレフィックスごとに1つのサブネットIDのみがサポートされます。デプロイされたOSとゲートウェイの特性評価では、サブネットID「0000」が最も一般的なデフォルトのケースであり、その後にサブネットID「0001」が続きます。サブネットIDの使用は、[RFC4291]で参照できます。通常の6to4操作では、エンドポイント（ネットワーク）は65,536（16ビット）のサブネットIDにアクセスできることに注意してください。上記の図3のマッピングを使用した6to4-PMTのケースでは、6to4-PMTに使用される1つを除くすべてのサブネットIDは、通常の6to4動作で動作します。
Pre-Relayed Packet [Provider Access Network Side]
事前中継されたパケット[プロバイダーアクセスネットワーク側]
0 16 32 48 64 80 96 112 128 Bits
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
2002 : 0C98 : 2C01 : 0000 : xxxx : xxxx : xxxx : xxxx
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
| | | | | |
---- ---- | | | |
| | | | | |
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
2001 : 0db8 : 0c98 : 2c01 : xxxx : xxxx : xxxx : xxxx
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
Post-Relayed Packet [Internet Side]
中継後のパケット[インターネット側]
Figure 3: 6to4-PMT Prefix Mapping
図3：6to4-PMTプレフィックスマッピング
It is preferred that the overall system use deterministic prefix translation mappings such that stateless operation can be implemented. This allows the provider to place N number of relays within the network without the need to manage translation state. Deterministic translation also allows a customer to employ inward services using the translated (provider prefix) address.
システム全体がステートレスな動作を実装できるように、決定論的なプレフィックス変換マッピングを使用することが望ましい。これにより、プロバイダーは、変換状態を管理する必要なく、ネットワーク内にN個のリレーを配置できます。確定的変換では、変換された（プロバイダーのプレフィックス）アドレスを使用して、内部サービスを利用することもできます。
If stateful operation is chosen, the operator would need to validate state and routing requirements particular to that type of deployment. The full body of considerations for this type of deployment is not within this scope of this document.
ステートフル操作が選択された場合、オペレーターは、そのタイプのデプロイメントに固有の状態およびルーティング要件を検証する必要があります。このタイプの展開に関する考慮事項の全体は、このドキュメントのこの範囲には含まれません。
A provider enabling this function should offer a method to allow customers to opt-out of such a service should the customer choose to maintain normal 6to4 operation irrespective of degraded performance. In cases where the customer is behind a CGN device, the customer would not be advised to opt-out and can be assisted in turning off 6to4.
この機能を有効にするプロバイダーは、パフォーマンスの低下に関係なく、顧客が通常の6to4オペレーションを維持することを選択した場合に、顧客がそのようなサービスをオプトアウトできるようにする方法を提供する必要があります。お客様がCGNデバイスの背後にいる場合、お客様はオプトアウトするようにアドバイスされず、6to4をオフにするように支援されます。
Since the 6to4-PMT system is targeted at customers who are relatively unaware of IPv6 and IPv4, and normally run network equipment with a default configuration, an opt-out strategy is recommended. This method provides 6to4-PMT operation for non-IPv6 savvy customers whose equipment may turn on 6to4 automatically and allows savvy customers to easily configure their way around the 6to4-PMT function.
6to4-PMTシステムは、IPv6とIPv4を比較的知らず、通常はデフォルト構成でネットワーク機器を実行している顧客を対象としているため、オプトアウト戦略をお勧めします。この方法は、IPv6に精通していない顧客に6to4を自動的にオンにする機器がある6to4-PMT操作を提供し、精通した顧客が6to4-PMT機能の周りに簡単に設定できるようにします。
Capable customers can also disable anycast-based 6to4 entirely and use traditional 6to4 or other tunneling mechanisms if they are so inclined. This is not considered the normal case, and most endpoints with auto-6to4 functions will be subject to 6to4-PMT operation since most users are unaware of its existence. 6to4-PMT is targeted as an option for stable IPv6 connectivity for average consumers.
有能な顧客は、エニーキャストベースの6to4を完全に無効にし、従来の6to4または他のトンネリングメカニズムを使用することもできます。これは通常のケースとは見なされず、auto-6to4機能を持つほとんどのエンドポイントは、ほとんどのユーザーがその存在に気付いていないため、6to4-PMT操作の対象になります。 6to4-PMTは、平均的な消費者向けの安定したIPv6接続のオプションとして対象とされています。
6to4-PMT operation can also be used to mitigate a known problem with 6to4 occurring when shared address space [RFC6598] or Global Unicast Addresses (GUA) are used behind a CGN and not routed on the Internet. Non-RFC1918, yet unrouted (on interdomain links) address space would cause many deployed OSs and network equipment to potentially auto-enable 6to4 operation even without a valid return path (such as behind a CGN function). The operator's desire to use non-RFC1918 addresses, such as shared address space [RFC6598], is considered highly likely based on real world deployments.
6to4-PMT操作は、共有アドレス空間[RFC6598]またはグローバルユニキャストアドレス（GUA）がCGNの背後で使用され、インターネット上でルーティングされない場合に発生する6to4に関する既知の問題を軽減するためにも使用できます。 RFC1918以外で、まだルーティングされていない（ドメイン間リンク上）アドレス空間があると、有効な戻りパス（CGN関数の背後など）がなくても、展開された多くのOSとネットワーク機器が6to4操作を自動的に有効にする可能性があります。共有アドレス空間[RFC6598]など、RFC1918以外のアドレスを使用したいというオペレーターの要望は、実際の展開に基づいている可能性が非常に高いと考えられています。
Such hosts, in normal cases, would send 6to4 traffic to the IPv6 Internet via the anycast relay, which would in fact provide broken IPv6 connectivity, since the return path flow is built using an IPv4 address that is not routed or assigned to the source network. The use of 6to4-PMT would help reverse these effects by translating the 6to4 prefix to a provider-assigned prefix, masking this automatic and undesired behavior.
このようなホストは、通常の場合、エニーキャストリレーを介して6to4トラフィックをIPv6インターネットに送信します。これにより、実際には、IPv6接続が切断されます。リターンパスフローは、ソースネットワークにルーティングまたは割り当てられていないIPv4アドレスを使用して構築されているためです。 6to4-PMTを使用すると、6to4プレフィックスをプロバイダーが割り当てたプレフィックスに変換し、この自動で望ましくない動作をマスクすることにより、これらの影響を逆転させるのに役立ちます。
The 6to4-PMT mode of operation removes the traditional end-to-end transparency of 6to4. Remote hosts would connect to a 6to4-PMT-serviced host using a translated IPv6 address versus the original 6to4 address based on the 2002::/16 well-known prefix. This can be seen as a disadvantage of the 6to4-PMT system. This lack of transparency should also be contrasted with the normal operating state of 6to4 that provides connectivity that is uncontrolled and often prone to high latency. The lack of transparency is, however, a better form of operation when extreme poor performance, broken IPv6 connectivity, or no IPv6 connectivity is considered as the alternative.
6to4-PMTモードの操作では、6to4の従来のエンドツーエンドの透過性が排除されます。リモートホストは、2002 :: / 16既知のプレフィックスに基づく元の6to4アドレスではなく、変換されたIPv6アドレスを使用して6to4-PMTサービスのホストに接続します。これは、6to4-PMTシステムの欠点と見なすことができます。この透過性の欠如は、制御されずに待ち時間が長くなる傾向がある接続を提供する6to4の通常の動作状態とも対照的です。ただし、極端なパフォーマンスの低下、IPv6接続の破損、またはIPv6接続がないことが代替手段と見なされる場合は、透過性の欠如がより良い運用形態です。
The MTU will be subject to a reduced value due to standard 6to4 tunneling operation. Under normal 6to4 operation, the 6to4 service agent would send an ICMP Packet Too Big Message as part of Path MTU discovery as described in [RFC4443] and [RFC1981], respectively. In 6to4-PMT operation, the PMT Service agent should be aware of the reduced 6to4 MTU and send ICMP messages using the translated address accordingly.
標準の6to4トンネリング操作により、MTUの値が減少します。通常の6to4操作では、6to4サービスエージェントは、[RFC4443]と[RFC1981]でそれぞれ説明されているように、パスMTUディスカバリの一部としてICMPパケットビッグメッセージを送信します。 6to4-PMT操作では、PMTサービスエージェントは6to4 MTUの減少を認識し、それに応じて変換されたアドレスを使用してICMPメッセージを送信する必要があります。
It is also possible to pre-constrain the MTU at the upstream router from the 6to4-PMT service agents that would then have the upstream router send the appropriate ICMP Packet Too Big Messages.
6to4-PMTサービスエージェントから上流ルーターにMTUを事前に制限して、上流ルーターに適切なICMPパケットが大きすぎるメッセージを送信させることもできます。
Checksum management for 6to4-PMT can be implemented in one of two ways. The first deployment model is based on the stateless 6to4-PMT operational mode. In this case, checksum modifications are made using the method described in [RFC3022], Section 4.2. The checksum is modified to match the parameters of the translated address of the source 6to4-PMT host. In the second deployment model in which stateful 6to4-PMT translation is used, the vendor can implement checksum-neutral mappings as defined in [RFC6296].
6to4-PMTのチェックサム管理は、2つの方法のいずれかで実装できます。最初の配置モデルは、ステートレス6to4-PMT操作モードに基づいています。この場合、チェックサムの変更は、[RFC3022]、セクション4.2で説明されている方法を使用して行われます。チェックサムは、ソース6to4-PMTホストの変換されたアドレスのパラメーターと一致するように変更されます。ステートフルな6to4-PMT変換が使用される2番目の展開モデルでは、ベンダーは[RFC6296]で定義されているチェックサムニュートラルマッピングを実装できます。
Vendors can choose to deploy Application Layer Gateways (ALGs) on their platforms that perform 6to4-PMT if they so choose. No ALGs were deployed as part of the open source and vendor product deployments of 6to4-PMT. In the vendor deployment case, the same rules were used as with their NPTv6 [RFC6296] base code.
ベンダーは、必要に応じて、6to4-PMTを実行するプラットフォームにApplication Layer Gateway（ALG）を展開することを選択できます。 6to4-PMTのオープンソースおよびベンダー製品のデプロイメントの一部として、ALGはデプロイされませんでした。ベンダー展開のケースでは、NPTv6 [RFC6296]ベースコードと同じルールが使用されました。
The provider would need to advertise the well-known IP address range used for normal anycast 6to4 [RFC3068] operation within the local IPv4 routing environment. This advertisement would attract the 6to4 upstream traffic to a local relay. To control this environment and make sure all northbound traffic lands on a provider-controlled relay, the operator may filter the anycast range from being advertised from customer endpoints toward the local network (upstream propagation).
プロバイダーは、ローカルIPv4ルーティング環境内の通常のエニーキャスト6to4 [RFC3068]操作に使用される既知のIPアドレス範囲をアドバタイズする必要があります。このアドバタイズは、6to4アップストリームトラフィックをローカルリレーに引き付けます。この環境を制御し、すべてのノースバウンドトラフィックがプロバイダー制御のリレーに確実に到達するように、オペレーターはエニーキャスト範囲をフィルターして、顧客のエンドポイントからローカルネットワークに向けてアドバタイズする（アップストリームの伝播）ことができます。
The provider would not be able to control route advertisements inside the customer domain, but that use case is not in scope for this document. In that case, it is likely that the end network/customer understands 6to4 and is maintaining their own relay environment and therefore would not be subject to the operators 6to4 and/or PMT operation.
プロバイダーは顧客ドメイン内のルートアドバタイズメントを制御できませんが、その使用例はこのドキュメントの範囲外です。その場合、エンドネットワーク/顧客が6to4を理解し、独自のリレー環境を維持している可能性が高いため、オペレーター6to4やPMT操作の影響を受けません。
Within their own network, the provider would also likely want to advertise the 2002::/16 range to help bridge traditional 6to4 traffic within the network (native IPv6 to 6to4-PMT-based endpoint). It would also be advised that the local 6to4-PMT operator not leak the well-known 6to4 anycast IPv4 prefix to neighboring Autonomous Systems to prevent PMT operation for neighboring networks. Policy configuration on the local 6to4-PMT Relay can also be used to disallow PMT operation should the local provider service downstream customer networks.
プロバイダーは独自のネットワーク内で、2002 :: / 16範囲をアドバタイズして、ネットワーク内の従来の6to4トラフィック（ネイティブIPv6から6to4-PMTベースのエンドポイント）のブリッジを支援することもできます。また、ローカルの6to4-PMTオペレーターが、既知の6to4エニーキャストIPv4プレフィックスを隣接する自律システムに漏らさず、隣接するネットワークのPMT動作を防止することもお勧めします。ローカル6to4-PMTリレーのポリシー構成を使用して、ローカルプロバイダーが下流の顧客ネットワークにサービスを提供する場合にPMTの動作を禁止することもできます。
The 6to4-PMT function can be deployed onto existing 6to4 relays (if desired) to help minimize network complexity and cost. 6to4-PMT has already been developed on Linux-based platforms that are package add-ons to the traditional 6to4 code. The only additional considerations beyond normal 6to4 relay operation would include the need to route specific IPv6 provider prefix ranges used for 6to4-PMT operation towards peers and transit providers.
6to4-PMT機能を既存の6to4リレーにデプロイして（必要な場合）、ネットワークの複雑さとコストを最小限に抑えることができます。 6to4-PMTは、従来の6to4コードのパッケージアドオンであるLinuxベースのプラットフォームですでに開発されています。通常の6to4リレー操作以外の追加の考慮事項は、6to4-PMT操作に使用される特定のIPv6プロバイダープレフィックス範囲をピアおよび中継プロバイダーにルーティングする必要があることです。
6to4-PMT operation would be subject to the same security concerns as normal 6to4 operation as described in [RFC6169]. 6to4-PMT is also not plainly perceptible by external hosts, and local entities appear as native IPv6 hosts to the external hosts.
[RFC6169]で説明されているように、6to4-PMT操作は通常の6to4操作と同じセキュリティ上の問題の影響を受けます。 6to4-PMTは外部ホストからもはっきりと認識されず、ローカルエンティティは外部ホストに対してネイティブIPv6ホストとして表示されます。
Thanks to the following people for their textual contributions and/or guidance on 6to4 deployment considerations: Dan Wing, Wes George, Scott Beuker, JF Tremblay, John Brzozowski, Chris Metz, and Chris Donley.
6to4の展開に関する考慮事項に関するテキストによる貢献やガイダンスを提供してくれた次の人々に感謝します。DanWing、Wes George、Scott Beuker、JF Tremblay、John Brzozowski、Chris Metz、およびChris Donley。
Additional thanks to the following for assisting with the coding and testing of 6to4-PMT: Marc Blanchet, John Cianfarani, Tom Jefferd, Nik Lavorato, Robert Hutcheon, and Ida Leung.
6to4-PMTのコーディングとテストを支援してくれたMarc Blanchet、John Cianfarani、Tom Jefferd、Nik Lavorato、Robert Hutcheon、Ida Leungに感謝します。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B。およびK.ムーア、「IPv4クラウドを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[RFC3068] Huitema、C。、「Antocast Prefix for 6to4 Relay Routers」、RFC 3068、2001年6月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のパスMTUディスカバリ」、RFC 1981、1996年8月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022] Srisuresh、P。およびK. Egevang、「Traditional IP Network Address Translator（Traditional NAT）」、RFC 3022、2001年1月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、2006年2月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、編、「インターネットプロトコルバージョン6（IPv6）仕様のためのインターネット制御メッセージプロトコル（ICMPv6）」、RFC 4443、2006年3月。
[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 Infrastructures on IPv4 Infrastructures（6rd）-Protocol Specification」、RFC 5969、2010年8月。
[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月。
[RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, June 2011.
[RFC6264] Jiang、S.、Guo、D。、およびB. Carpenter、「Incremental Carrier-Grade NAT（CGN）for IPv6 Transition」、RFC 6264、2011年6月。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011.
[RFC6296] Wasserman、M。およびF. Baker、「IPv6-to-IPv6 Network Prefix Translation」、RFC 6296、2011年6月。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.
[RFC6333] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4枯渇後のデュアルスタックLiteブロードバンド展開」、RFC 6333、2011年8月。
[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", RFC 6343, August 2011.
[RFC6343]カーペンター、B。、「6to4展開に関する勧告ガイドライン」、RFC 6343、2011年8月。
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, April 2012.
[RFC6598] Weil、J.、Kuarsingh、V.、Donley、C.、Liljenstolpe、C。、およびM. Azinger、「IANA-Reserved IPv4 Prefix for Shared Address Space」、BCP 153、RFC 6598、2012年4月。
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012.
[RFC6724] Thaler、D.、Ed。、Draves、R.、Matsumoto、A。、およびT. Chown、「Default Protocol Selection for Internet Protocol Version 6（IPv6）」、RFC 6724、2012年9月。
Authors' Addresses
著者のアドレス
Victor Kuarsingh (editor) Rogers Communications 8200 Dixie Road Brampton, Ontario L6T 0C1 Canada
Victor Kuarsingh（編集者）Rogers Communications 8200 Dixie Roadブランプトンオンタリオ州L6T 0C1カナダ
EMail: victor.kuarsingh@gmail.com
URI: http://www.rogers.com
Yiu L. Lee Comcast One Comcast Center Philadelphia, PA 19103 U.S.A.
Yiu L. Lee Comcast One Comcast Center Philadelphia、PA 19103 U.S.A.
EMail: yiu_lee@cable.comcast.com
URI: http://www.comcast.com
Olivier Vautrin Juniper Networks 1194 N Mathilda Avenue Sunnyvale, CA 94089 U.S.A.
Olivier Vautrin Juniper Networks 1194 N Mathilda Avenue Sunnyvale、CA 94089 U.S.A.
EMail: olivier@juniper.net
URI: http://www.juniper.net