Internet Engineering Task Force (IETF) A. Durand
Request for Comments: 6333 Juniper Networks
Category: Standards Track R. Droms
ISSN: 2070-1721 Cisco
J. Woodyatt
Apple
Y. Lee
Comcast
August 2011
Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion
Abstract
抽象
This document revisits the dual-stack model and introduces the Dual-Stack Lite technology aimed at better aligning the costs and benefits of deploying IPv6 in service provider networks. Dual-Stack Lite enables a broadband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4- in-IPv6) and Network Address Translation (NAT).
この文書では、デュアルスタックモデルを再訪し、より良いサービスプロバイダーネットワークでIPv6を展開するコストと利益を揃えるに向けたデュアルスタックLiteの技術を導入しています。 IPでのIP（インIPv6のIPv4-）とネットワークアドレス変換（NAT）：デュアルスタックLiteは、2つのよく知られた技術を組み合わせることにより、顧客の間でIPv4アドレスを共有するブロードバンドサービスプロバイダーを可能にします。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（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/rfc6333.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6333で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
2. Requirements Language ...........................................4
3. Terminology .....................................................4
4. Deployment Scenarios ............................................4
4.1. Access Model ...............................................4
4.2. CPE ........................................................5
4.3. Directly Connected Device ..................................6
5. B4 Element ......................................................7
5.1. Definition .................................................7
5.2. Encapsulation ..............................................7
5.3. Fragmentation and Reassembly ...............................7
5.4. AFTR Discovery .............................................7
5.5. DNS ........................................................8
5.6. Interface Initialization ...................................8
5.7. Well-Known IPv4 Address ....................................8
6. AFTR Element ....................................................9
6.1. Definition .................................................9
6.2. Encapsulation ..............................................9
6.3. Fragmentation and Reassembly ...............................9
6.4. DNS .......................................................10
6.5. Well-Known IPv4 Address ...................................10
6.6. Extended Binding Table ....................................10
7. Network Considerations .........................................10
7.1. Tunneling .................................................10
7.2. Multicast Considerations ..................................10
8. NAT Considerations .............................................11
8.1. NAT Pool ..................................................11
8.2. NAT Conformance ...........................................11
8.3. Application Level Gateways (ALGs) .........................11
8.4. Sharing Global IPv4 Addresses .............................11
8.5. Port Forwarding / Keep Alive ..............................11
9. Acknowledgements ...............................................12
10. IANA Considerations ...........................................12
11. Security Considerations .......................................12
12. References ....................................................13
12.1. Normative References .....................................13
12.2. Informative References ...................................14
Appendix A. Deployment Considerations .............................16
A.1. AFTR Service Distribution and Horizontal Scaling ...........16
A.2. Horizontal Scaling .........................................16
A.3. High Availability ..........................................16
A.4. Logging ....................................................16
Appendix B. Examples ..............................................17
B.1. Gateway-Based Architecture .................................17
B.1.1. Example Message Flow ...................................19
B.1.2. Translation Details ....................................23
B.2. Host-Based Architecture ....................................24
B.2.1. Example Message Flow ...................................27
B.2.2. Translation Details ....................................31
The common thinking for more than 10 years has been that the transition to IPv6 will be based solely on the dual-stack model and that most things would be converted this way before we ran out of IPv4. However, this has not happened. The IANA free pool of IPv4 addresses has now been depleted, well before sufficient IPv6 deployment had taken place. As a result, many IPv4 services have to continue to be provided even under severely limited address space.
10年以上のための一般的な考え方は、IPv6への移行は、デュアルスタックモデルのみに基づいてされることを、私たちは、IPv4を使い果たした前にほとんどのものは、このように変換されることとなっています。しかし、これは起きていません。 IPv4アドレスのIANAフリー・プールは現在、十分なIPv6の展開が行われていただけでなく前に、枯渇しています。その結果、多くのIPv4サービスにも厳しく制限されたアドレス空間の下で提供され続ける必要があります。
This document specifies the Dual-Stack Lite technology, which is aimed at better aligning the costs and benefits in service provider networks. Dual-Stack Lite will enable both continued support for IPv4 services and incentives for the deployment of IPv6. It also de-couples IPv6 deployment in the service provider network from the rest of the Internet, making incremental deployment easier.
この文書では、より良いサービスプロバイダーネットワークでの費用と便益を整合させることを目的としているデュアルスタックLiteの技術を、指定します。デュアルスタックライトは、IPv4サービスとIPv6の展開のためのインセンティブのための両方の継続的なサポートを有効にします。また、より簡単に、増分展開を行う、インターネットの残りの部分から、サービスプロバイダーネットワークでのIPv6の展開 - カップルド。
Dual-Stack Lite enables a broadband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4-in-IPv6) and Network Address Translation (NAT).
IPでのIP（IPv4のインのIPv6）とネットワークアドレス変換（NAT）：デュアルスタックLiteは、2つのよく知られた技術を組み合わせることにより、顧客の間でIPv4アドレスを共有するブロードバンドサービスプロバイダーを可能にします。
This document makes a distinction between a dual-stack-capable and a dual-stack-provisioned device. The former is a device that has code that implements both IPv4 and IPv6, from the network layer to the applications. The latter is a similar device that has been provisioned with both an IPv4 and an IPv6 address on its interface(s). This document will also further refine this notion by distinguishing between interfaces provisioned directly by the service provider from those provisioned by the customer.
この文書では、デュアルスタック対応し、デュアルスタック・プロビジョニングされたデバイスを区別します。前者は、アプリケーションに、ネットワーク層から、IPv4とIPv6の両方を実装するコードを有する装置です。後者は、IPv4とそのインタフェース（複数可）のIPv6アドレスの両方でプロビジョニングされている類似の装置です。この文書は、さらなる顧客によってプロビジョニングされるものと、サービス・プロバイダによって直接プロビジョニングインタフェースを区別することによって、この概念を精緻化します。
Pure IPv6-only devices (i.e., devices that do not include an IPv4 stack) are outside of the scope of this document.
純粋なIPv6専用デバイス（IPv4スタックを含まない、すなわち、デバイス）は、この文書の範囲外です。
This document will first present some deployment scenarios and then define the behavior of the two elements of the Dual-Stack Lite technology: the Basic Bridging BroadBand (B4) element and the Address Family Transition Router (AFTR) element. It will then go into networking and NAT-ing considerations.
この文書では、最初のいくつかの展開シナリオを提示して、デュアルスタックライト技術の二つの要素の動作を定義します：基本的なブリッジングブロードバンド（B4）要素とアドレスファミリ移行ルータ（AFTR）の要素を。その後、ネットワーキングおよびNAT-ING考慮事項になります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
The technology described in this document is known as Dual-Stack Lite. The abbreviation "DS-Lite" will be used throughout this text.
本書に記載の技術は、デュアルスタックライトとして知られています。略語「DS-Liteは、」この文書全体で使用されます。
This document also introduces two new terms: the DS-Lite Basic Bridging BroadBand (B4) element and the DS-Lite Address Family Transition Router (AFTR) element.
DS-Liteの基本的なブリッジングブロードバンド（B4）要素とDS-Liteの家族の移行ルータアドレス（AFTR）要素：この文書では、2つの新しい用語を紹介します。
Dual-stack is defined in [RFC4213].
デュアルスタックは[RFC4213]で定義されています。
NAT-related terminology is defined in [RFC4787].
NAT関連用語は、[RFC4787]で定義されています。
CPE stands for Customer Premise Equipment. This is the layer 3 device in the customer premise that is connected to the service provider network. That device is often a home gateway. However, sometimes computers are directly attached to the service provider network. In such cases, such computers can be viewed as CPEs as well.
CPEは、顧客宅内機器の略です。これは、サービスプロバイダーのネットワークに接続された顧客宅内でのレイヤ3デバイスです。このデバイスは、多くの場合、ホームゲートウェイです。しかし、時々、コンピュータが直接サービスプロバイダーのネットワークに接続されています。このような場合には、そのようなコンピュータは、同様のCPEとみなすことができます。
Instead of relying on a cascade of NATs, the Dual-Stack Lite model is built on IPv4-in-IPv6 tunnels to cross the network to reach a carrier-grade IPv4-IPv4 NAT (the AFTR), where customers will share IPv4 addresses. There are a number of benefits to this approach:
代わりのNATカスケードに依存するので、デュアルスタックライトモデルは、顧客がIPv4アドレスを共有することになり、キャリアグレードのIPv4-IPv4のNAT（AFTR）を、到達するためにネットワークを横断するためのIPv4-で-IPv6トンネルの上に構築されています。この手法には多くの利点があります。
o This technology decouples the deployment of IPv6 in the service provider network (up to the customer premise equipment or CPE) from the deployment of IPv6 in the global Internet and in customer applications and devices.
Oこの技術は、世界的なインターネットで、顧客のアプリケーションやデバイスでのIPv6の展開から（顧客宅内機器やCPEまで）サービスプロバイダーネットワークでのIPv6の展開を切り離します。
o The management of the service provider access networks is simplified by leveraging the large IPv6 address space. Overlapping private IPv4 address spaces are not required to support very large customer bases.
Oサービスプロバイダーのアクセスネットワークの管理は、大規模なIPv6アドレス空間を活用することで簡略化されています。重複プライベートIPv4アドレス空間は、非常に大規模な顧客基盤をサポートする必要はありません。
o As tunnels can terminate anywhere in the service provider network, this architecture lends itself to horizontal scaling and provides some flexibility to adapt to changing traffic load. More discussion of horizontal scaling can be found in Appendix A.
トンネルは、サービスプロバイダーネットワーク内のどこにでも終了することができますOとして、このアーキテクチャは、水平方向のスケーリングに自分自身を貸すし、トラフィック負荷の変化に適応するためにある程度の柔軟性を提供します。水平スケーリングの詳しい議論は、付録Aに見つけることができます
o Tunnels provide a direct connection between B4 and the AFTR. This can be leveraged to enable customers and their applications to control how the NAT function of the AFTR is performed.
OトンネルB4とAFTRの間の直接接続を提供します。これはAFTRのNAT機能が実行される方法を制御するために、顧客とその応用を可能にするために活用することができます。
A key characteristic of this approach is that communications between end-nodes stay within their address family. IPv6 sources only communicate with IPv6 destinations, and IPv4 sources only communicate with IPv4 destinations. There is no protocol family translation involved in this approach. This simplifies greatly the task of applications that may carry literal IP addresses in their payloads.
このアプローチの重要な特徴は、エンドノード間の通信は、自分のアドレスファミリ内にとどまるということです。 IPv6のソースは、IPv6の宛先と通信する、とIPv4ソースはIPv4のみの宛先と通信します。このアプローチに関わる一切のプロトコルファミリの翻訳はありません。これは非常に彼らのペイロードにリテラルIPアドレスを運ぶことができるアプリケーションのタスクを簡素化します。
This section describes home Local Area networks characterized by the presence of a home gateway, or CPE, provisioned only with IPv6 by the service provider.
このセクションでは、サービスプロバイダによってIPv6のみでプロビジョニングホームゲートウェイ、またはCPEが存在することを特徴とホームローカルエリアネットワークを、説明しています。
A DS-Lite CPE is an IPv6-aware CPE with a B4 interface implemented in the WAN interface.
DS-LiteのCPEは、WANインターフェイスに実装B4インタフェースとIPv6の対応のCPEです。
A DS-Lite CPE SHOULD NOT operate a NAT function between an internal interface and a B4 interface, as the NAT function will be performed by the AFTR in the service provider's network. This will avoid accidentally operating in a double-NAT environment.
NAT機能は、サービスプロバイダのネットワークでAFTRによって実行されるように、DS-LiteのCPEは、内部インターフェイスおよびB4インタフェース間のNAT機能を作動しません。これは、誤って二重NAT環境で動作して避けることができます。
However, it SHOULD operate its own DHCP(v4) server handing out [RFC1918] address space (e.g., 192.168.0.0/16) to hosts in the home. It SHOULD advertise itself as the default IPv4 router to those home hosts. It SHOULD also advertise itself as a DNS server in the DHCP Option 6 (DNS Server). Additionally, it SHOULD operate a DNS proxy to accept DNS IPv4 requests from home hosts and send them using IPv6 to the service provider DNS servers, as described in Section 5.5.
しかし、それは家庭内のホストに独自のDHCP（V4）サーバ配って[RFC1918]のアドレス空間（例えば、192.168.0.0/16）を動作させるべきです。これは、これらの家庭のホストにデフォルトのIPv4ルータとして自分自身を宣伝すべきです。また、DHCPオプション6（DNSサーバー）でDNSサーバーとして自身を宣伝すべきです。さらに、それは、5.5節で説明したように、家庭のホストからのDNSのIPv4要求を受け入れ、サービスプロバイダのDNSサーバにIPv6を使用してそれらを送信するために、DNSプロキシを動作しなければなりません。
Note: If an IPv4 home host decides to use another IPv4 DNS server, the DS-Lite CPE will forward those DNS requests via the B4 interface, the same way it forwards any regular IPv4 packets. However, each DNS request will create a binding in the AFTR. A large number of DNS requests may have a direct impact on the AFTR's NAT table utilization.
注：IPv4ホームホストが別のIPv4 DNSサーバーを使用することを決定した場合、DS-LiteのCPEは、B4インタフェースを介して、それは任意の正規のIPv4パケットを転送するのと同じ方法でこれらのDNS要求を転送します。しかし、各DNS要求がAFTRにバインディングを作成します。 DNS要求の多くはAFTRのNATテーブルの使用率に直接影響を与える可能性があります。
IPv6-capable devices directly reach the IPv6 Internet. Packets simply follow IPv6 routing, they do not go through the tunnel, and they are not subject to any translation. It is expected that most IPv6-capable devices will also be IPv4 capable and will simply be configured with an IPv4 [RFC1918]-style address within the home network and access the IPv4 Internet the same way as the legacy IPv4- only devices within the home.
IPv6対応デバイスは、直接IPv6インターネットに到達します。パケットは、単に彼らがトンネルを通過していない、と彼らはあらゆる翻訳の対象ではない、IPv6ルーティングに従ってください。ほとんどのIPv6対応デバイスも可能ではIPv4になり、単にホームネットワーク内のIPv4 [RFC1918]スタイルのアドレスで構成され、IPv4インターネットに家庭内のデバイスのみIPv4-レガシーと同じようにアクセスすることが期待されます。
Pure IPv6-only devices (i.e., devices that do not include an IPv4 stack) are outside of the scope of this document.
純粋なIPv6専用デバイス（IPv4スタックを含まない、すなわち、デバイス）は、この文書の範囲外です。
In broadband home networks, some devices are directly connected to the broadband service provider. They are connected straight to a modem, without a home gateway. Those devices are, in fact, acting as CPEs.
ブロードバンドホームネットワークでは、一部のデバイスは、直接ブロードバンドサービスプロバイダに接続されています。これらは、ホームゲートウェイなしで、ストレートモデムに接続されています。これらのデバイスは、CPEのとして動作する、実際には、あります。
Under this scenario, the customer device is a dual-stack-capable host that is provisioned by the service provider with IPv6 only. The device itself acts as a B4 element, and the IPv4 service is provided by an IPv4-in-IPv6 tunnel, just as in the home gateway/CPE case. That device can run any combinations of IPv4 and/or IPv6 applications.
このシナリオでは、顧客のデバイスがIPv6のみでのサービスプロバイダによってプロビジョニングされたデュアルスタック対応のホストです。デバイス自体は、B4要素として作用し、IPv4サービスは、単にホームゲートウェイ/ CPEの場合のように、IPv4のインのIPv6トンネルによって提供されます。このデバイスは、IPv4および/またはIPv6アプリケーションの任意の組み合わせを実行することができます。
A directly connected DS-Lite device SHOULD send its DNS requests over IPv6 to the IPv6 DNS server it has been configured to use.
直接接続されているDS-Liteのデバイスは、使用するように設定されていたIPv6 DNSサーバーにIPv6を介してDNS要求を送信します。
Similarly to the previous sections, IPv6 packets follow IPv6 routing, they do not go through the tunnel, and they are not subject to any translation.
同様に、前のセクションに、IPv6パケットをIPv6ルーティングに従ってください、彼らはトンネルを通過していない、と彼らはあらゆる翻訳の対象にはなりません。
The support of IPv4-only devices and IPv6-only devices in this scenario is out of scope for this document.
このシナリオではIPv4のみの機器とIPv6のみのデバイスのサポートは、この文書の範囲外です。
The B4 element is a function implemented on a dual-stack-capable node, either a directly connected device or a CPE, that creates a tunnel to an AFTR.
B4要素はAFTRにトンネルを作成するデュアルスタック対応ノード上で実現される機能、直接接続されたデバイスまたはCPEのいずれか、です。
The tunnel is a multipoint-to-point IPv4-in-IPv6 tunnel ending on a service provider AFTR.
トンネルはAFTRサービスプロバイダに終了マルチポイントツーポイントのIPv4内IPv6のトンネルです。
See Section 7.1 for additional tunneling considerations.
追加のトンネリングの考慮事項については、セクション7.1を参照してください。
Note: At this point, DS-Lite only defines IPv4-in-IPv6 tunnels; however, other types of encapsulation could be defined in the future.
注意：この時点では、DS-Liteは、IPv4のみ・イン・IPv6のトンネルを定義します。しかし、カプセル化の他のタイプは、将来的に定義することができます。
Using an encapsulation (IPv4-in-IPv6 or anything else) to carry IPv4 traffic over IPv6 will reduce the effective MTU of the datagram. Unfortunately, path MTU discovery [RFC1191] is not a reliable method to deal with this problem.
IPv6の上でIPv4トラフィックを運ぶためにカプセル化（IPv4のインのIPv6または何か他のもの）を使用すると、データグラムの有効MTUを削減します。残念ながら、パスMTU探索[RFC1191]は、この問題に対処するための信頼性の高い方法ではありません。
A solution to deal with this problem is for the service provider to increase the MTU size of all the links between the B4 element and the AFTR elements by at least 40 bytes to accommodate both the IPv6 encapsulation header and the IPv4 datagram without fragmenting the IPv6 packet.
この問題に対処するための解決策は、IPv6パケットを断片化することなく、IPv6のカプセル化ヘッダとIPv4データグラムの両方を収容するようにB4要素と少なくとも40のバイトによってAFTR要素間のすべてのリンクのMTUサイズを増加させるために、サービスプロバイダのためのものです。
However, as not all service providers will be able to increase their link MTU, the B4 element MUST perform fragmentation and reassembly if the outgoing link MTU cannot accommodate the extra IPv6 header. The original IPv4 packet is not oversized. The packet is oversized after the IPv6 encapsulation. The inner IPv4 packet MUST NOT be fragmented. Fragmentation MUST happen after the encapsulation of the IPv6 packet. Reassembly MUST happen before the decapsulation of the IPv4 packet. A detailed procedure has been specified in [RFC2473] Section 7.2.
しかし、必ずしもすべてのサービスプロバイダが発信リンクMTUは、余分なIPv6ヘッダに対応できない場合は、B4要素が断片化と再構築を実行しなければなりません自分のリンクMTUを増やすことができるようになります。オリジナルのIPv4パケットは特大ではありません。パケットは、IPv6カプセル化した後、特大です。内側のIPv4パケットを断片化してはいけません。断片化は、IPv6パケットのカプセル化した後に行われる必要があります。再組み立ては、IPv4パケットのカプセル化解除前に発生しなければなりません。詳細な手順は、[RFC2473]セクション7.2で指定されています。
In order to configure the IPv4-in-IPv6 tunnel, the B4 element needs the IPv6 address of the AFTR element. This IPv6 address can be configured using a variety of methods, ranging from an out-of-band mechanism, manual configuration, or a variety of DHCPv6 options.
IPv4のインのIPv6トンネルを設定するために、B4要素はAFTR素子のIPv6アドレスを必要とします。このIPv6アドレスはアウトオブバンド機構、手動設定、またはDHCPv6オプションの種々の範囲の、種々の方法を使用して構成することができます。
In order to guarantee interoperability, a B4 element SHOULD implement the DHCPv6 option defined in [RFC6334].
相互運用性を保証するために、B4要素は[RFC6334]で定義されたDHCPv6のオプションを実装する必要があります。
A B4 element is only configured from the service provider with IPv6. As such, it can only learn the address of a DNS recursive server through DHCPv6 (or other similar method over IPv6). As DHCPv6 only defines an option to get the IPv6 address of such a DNS recursive server, the B4 element cannot easily discover the IPv4 address of such a recursive DNS server, and as such will have to perform all DNS resolution over IPv6.
B4要素は、IPv6のみを使用してサービスプロバイダから構成されています。そのようなものとして、それだけ（IPv6の上または他の類似の方法）のDHCPv6介してDNS再帰サーバのアドレスを知ることができます。 DHCPv6のが唯一のように、DNSの再帰サーバーのIPv6アドレスを取得するためのオプションを定義すると、B4要素は簡単な再帰的なDNSサーバのIPv4アドレスを発見することができない、そのようにIPv6を介し、すべてのDNS解決を実行する必要があります。
The B4 element can pass this IPv6 address to downstream IPv6 nodes, but not to downstream IPv4 nodes. As such, the B4 element SHOULD implement a DNS proxy, following the recommendations of [RFC5625].
B4要素は、下流IPv6ノードにではなく、下流のIPv4ノードにこのIPv6アドレスを渡すことができます。このように、B4要素は[RFC5625]の推奨に従って、DNSプロキシを実装する必要があります。
To support a security-aware resolver behind the B4 element, the DNS proxy in the B4 element must also be security aware. Details can be found in [RFC4033] Section 6.
B4要素の背後にあるセキュリティ対応リゾルバをサポートするために、B4要素内のDNSプロキシは、セキュリティに注意する必要があります。詳細は[RFC4033]のセクション6に記載されています。
The B4 element can be implemented in a host and CPE in conjunction with other technologies such as native dual-stack. The host and the CPE SHOULD select to start only one technology during initialization. For example, if the CPE selects to start in native dual-stack mode, it SHOULD NOT initialize the B4 element. This selection process is out of scope for this document.
B4要素は、ネイティブデュアルスタックなどの他の技術と併せてホストとCPEで実現することができます。ホストとCPEは、初期化中に一つだけの技術を開始するために選択する必要があります。 CPEは、ネイティブデュアルスタックモードで起動することを選択した場合、それはB4要素を初期化すべきではありません。この選択プロセスはこの文書の範囲外です。
Any locally unique IPv4 address could be configured on the IPv4-in-IPv6 tunnel to represent the B4 element. Configuring such an address is often necessary when the B4 element is sourcing IPv4 datagrams directly over the tunnel. In order to avoid conflicts with any other address, IANA has defined a well-known range, 192.0.0.0/29.
任意のローカルで一意のIPv4アドレスは、B4の要素を表すためのIPv4型のIPv6トンネルで構成することができます。 B4素子はトンネルの真上のIPv4データグラムを供給されたときにそのようなアドレスを設定することがしばしば必要です。他のアドレスとの競合を避けるために、IANAは、よく知られている範囲、192.0.0.0/29を定義しています。
192.0.0.0 is the reserved subnet address. 192.0.0.1 is reserved for the AFTR element, and 192.0.0.2 is reserved for the B4 element. If a service provider has a special configuration that prevents the B4 element from using 192.0.0.2, the B4 element MAY use any other addresses within the 192.0.0.0/29 range.
192.0.0.0は予約されたサブネットアドレスです。 192.0.0.1はAFTR要素のために予約され、そして192.0.0.2はB4要素のために予約されています。サービスプロバイダは192.0.0.2を使用してからB4要素を防ぐ特殊な構成を有している場合は、B4要素が192.0.0.0/29の範囲内の任意の他のアドレスを使用するかもしれません。
Note: A range of addresses has been reserved for this purpose. The intent is to accommodate nodes implementing multiple B4 elements.
注意：アドレスの範囲は、この目的のために予約されています。目的は、複数B4の要素を実装するノードに対応することです。
An AFTR element is the combination of an IPv4-in-IPv6 tunnel endpoint and an IPv4-IPv4 NAT implemented on the same node.
AFTR要素は、IPv4内IPv6のトンネルエンドポイントとIPv4-IPv4のNATの組み合わせが同じノード上に実装されます。
The tunnel is a point-to-multipoint IPv4-in-IPv6 tunnel ending at the B4 elements.
トンネルは、B4の要素で終わるポイント・ツー・マルチポイントのIPv4型のIPv6トンネルです。
See Section 7.1 for additional tunneling considerations.
追加のトンネリングの考慮事項については、セクション7.1を参照してください。
Note: At this point, DS-Lite only defines IPv4-in-IPv6 tunnels; however, other types of encapsulation could be defined in the future.
注意：この時点では、DS-Liteは、IPv4のみ・イン・IPv6のトンネルを定義します。しかし、カプセル化の他のタイプは、将来的に定義することができます。
As noted previously, fragmentation and reassembly need to be taken care of by the tunnel endpoints. As such, the AFTR MUST perform fragmentation and reassembly if the underlying link MTU cannot accommodate the encapsulation overhead. Fragmentation MUST happen after the encapsulation on the IPv6 packet. Reassembly MUST happen before the decapsulation of the IPv6 header. A detailed procedure has been specified in [RFC2473] Section 7.2.
先に述べたように、断片化および再アセンブリは、トンネルエンドポイントでの世話をする必要があります。基礎となるリンクMTUは、カプセル化のオーバーヘッドを収容することができない場合など、AFTRは断片化と再アセンブリを実行しなければなりません。断片化は、IPv6パケットでカプセル化した後に発生しなければなりません。再組み立ては、IPv6ヘッダのカプセル化解除前に発生しなければなりません。詳細な手順は、[RFC2473]セクション7.2で指定されています。
Fragmentation at the Tunnel Entry-Point is a lightweight operation. In contrast, reassembly at the Tunnel Exit-Point can be expensive. When the Tunnel Exit-Point receives the first fragmented packet, it must wait for the second fragmented packet to arrive in order to reassemble the two fragmented IPv6 packets for decapsulation. This requires the Tunnel Exit-Point to buffer and keep track of fragmented packets. Consider that the AFTR is the Tunnel Exit-Point for many tunnels. If many devices simultaneously source a large number of fragmented packets through the AFTR to its managed B4 elements, this will require the AFTR to buffer and consume enormous resources to keep track of the flows. This reassembly process will significantly impact the AFTR's performance. However, this impact only happens when many clients simultaneously source large IPv4 packets. Since we believe that the majority of the clients will receive large IPv4 packets (such as watching video streams) instead of sourcing large IPv4 packets (such as sourcing video streams), reassembly is only a fraction of the overall AFTR's workload.
トンネルエントリポイントでの断片化は軽量な操作です。これとは対照的に、トンネル出口ポイントの再構築は高価なことができます。トンネル出口ポイントは、最初のフラグメントパケットを受信すると、カプセル化解除用の2つの断片化されたIPv6パケットを再構成するために到着するために、第2のフラグメントパケットを待つ必要があります。これは、バッファおよびフラグメントパケットを追跡するためにトンネル出口ポイントが必要です。 AFTRは、多くのトンネルのトンネル出口ポイントであることを考えてみましょう。多くのデバイスが同時にその管理B4要素にAFTRを通じて断片化された大量のパケットを調達した場合、これは、バッファおよびフローを追跡するために多大なリソースを消費するAFTRが必要になります。この再構築プロセスが大幅AFTRのパフォーマンスに影響を与えます。多くのクライアントが同時に大きなIPv4パケットを調達する場合しかし、この影響はのみ発生します。私たちはクライアントの大半は、代わりに（例えば、ビデオストリームを調達など）大IPv4パケットを調達の（例えば、ビデオストリームを見ているような）大きなIPv4パケットを受信すると信じているので、再組み立ては、全体的なAFTRのワークロードのほんの一部です。
When the AFTR's resources are running below a pre-defined threshold, the AFTR SHOULD generate a notification to the administrator before the resources are completely exhausted. The threshold and notification procedures are implementation dependent and are out of scope for this document.
AFTRのリソースは、事前に定義されたしきい値を下回っ実行している場合は、リソースが完全に排出される前に、AFTRは、管理者への通知を生成する必要があります。しきい値と通知手順は、実装依存であり、この文書の範囲外です。
Methods to avoid fragmentation, such as rewriting the TCP Maximum Segment Size (MSS) option or using technologies such as the Subnetwork Encapsulation and Adaptation Layer as defined in [RFC5320], are out of scope for this document.
そのような[RFC5320]で定義されているTCP最大セグメントサイズ（MSS）オプションや、サブネットワークのカプセル化とアダプテーション層などの技術を使用しての書き換えなどの断片化を回避するための方法は、このドキュメントの範囲外です。
As noted previously, a DS-Lite node implementing a B4 element will perform DNS resolution over IPv6. As a result, DNS packets are not expected to go through the AFTR element.
先に述べたように、B4の要素を実装するDS-Liteのノードは、IPv6を超えるDNS解決を実行します。その結果、DNSパケットがAFTR要素を通過することが予想されていません。
The AFTR SHOULD use the well-known IPv4 address 192.0.0.1 reserved by IANA to configure the IPv4-in-IPv6 tunnel. That address can then be used to report ICMP problems and will appear in traceroute outputs.
AFTRは、IPv4内のIPv6トンネルを設定するためにIANAによって予約周知IPv4アドレス192.0.0.1を使用すべきです。このアドレスは、ICMPの問題を報告するために使用することができ、tracerouteの出力に表示されます。
The NAT binding table of the AFTR element is extended to include the source IPv6 address of the incoming packets. This IPv6 address is used to disambiguate between the overlapping IPv4 address space of the service provider customers.
AFTR要素のNATバインディングテーブルは、着信パケットの送信元IPv6アドレスを含むように拡張されます。このIPv6アドレスは、サービスプロバイダの顧客の重複IPv4アドレス空間の間で明確にするために使用されます。
By doing a reverse lookup in the extended IPv4 NAT binding table, the AFTR knows how to reconstruct the IPv6 encapsulation when the packets come back from the Internet. That way, there is no need to keep a static configuration for each tunnel.
拡張IPv4のNATバインディングテーブルの逆引きを行うことで、AFTRは、パケットがインターネットから戻ってきたときのIPv6カプセル化を再構築する方法を知っています。その方法は、各トンネルのための静的な構成を維持する必要はありません。
Tunneling MUST be done in accordance to [RFC2473] and [RFC4213]. Traffic classes ([RFC2474]) from the IPv4 headers MUST be carried over to the IPv6 headers and vice versa.
トンネリングは、[RFC2473]及び[RFC4213]に基づいて行わなければなりません。 IPv4のヘッダからトラフィッククラス（[RFC2474]）はIPv6のヘッダとその逆に引き継がなければなりません。
Discussion of multicast is out of scope for this document.
マルチキャストの議論はこの文書の範囲外です。
The AFTR MAY be provisioned with different NAT pools. The address ranges in the pools may be disjoint but MUST NOT be overlapped. Operators may implement policies in the AFTR to assign clients in different pools. For example, an AFTR can have two interfaces. Each interface will have a disjoint pool NAT assigned to it. In another case, a policy implemented on the AFTR may specify that one set of B4s will use NAT pool 1 and a different set of B4s will use NAT pool 2.
AFTRは異なるNATプールでプロビジョニングされるかもしれません。プール内のアドレス範囲は互いに素かもしれないが、重なってはなりません。オペレータは異なるプール内のクライアントを割り当てることがAFTRでポリシーを実装することができます。例えば、AFTR 2つのインターフェイスを有することができます。各インターフェイスには、それに割り当てられてばらばらプールNATを持っています。別の場合には、AFTR上に実装ポリシーは、B4Sの一組は、NATプール1及びNATプール2を使用するB4Sの異なるセットを使用することを指定することができます。
A Dual-Stack Lite AFTR MUST implement behavior conforming to the best current practice, currently documented in [RFC4787], [RFC5508], and [RFC5382]. More discussions about carrier-grade NATs can be found in [LSN-REQS].
デュアルスタックライトAFTRは現在のベストプラクティス、現在は[RFC4787]で文書化され、[RFC5508]、および[RFC5382]に準拠した振る舞いを実装しなければなりません。キャリアグレードNATの詳細については議論が[LSN-REQS]で見つけることができます。
The AFTR performs NAT-44 and inherits the limitations of NAT. Some protocols require ALGs in the NAT device to traverse through the NAT. For example, Active FTP requires the ALG to work properly. ALGs consume resources, and there are many different types of ALGs. The AFTR is a shared network device that supports a large number of B4 elements. It is impossible for the AFTR to implement every current and future ALG.
AFTRはNAT-44を実行し、NATの制約を継承します。一部のプロトコルはNATを横断するNATデバイスでのALGが必要です。例えば、アクティブFTPが正常に動作するALGが必要です。 ALGはリソースを消費し、のALGの多くの異なる種類があります。 AFTRはB4多数の要素をサポートする共有ネットワーク装置です。 AFTRは、すべての現在および将来のALGを実装することは不可能です。
The AFTR shares a single IP with multiple users. This helps to increase the IPv4 address utilization. However, it also brings some issues such as logging and lawful intercept. More considerations on sharing the port space of IPv4 addresses can be found in [RFC6269].
AFTR共有複数のユーザーを持つ単一のIP。これは、IPv4アドレスの利用率を高めるのに役立ちます。しかし、それはまた、伐採や合法的傍受などいくつかの問題をもたらします。 IPv4アドレスのポート空間を共有する上でより多くの考慮事項は、[RFC6269]で見つけることができます。
The PCP working group is standardizing a control plane to the carrier-grade NAT [LSN-REQS] in the IETF. The Port Control Protocol (PCP) enables applications to directly negotiate with the NAT to open ports and negotiate lifetime values to avoid keep-alive traffic. More on PCP can be found in [PCP-BASE].
PCPワーキンググループは、IETFのキャリアグレードNAT [LSN-REQS]に制御プレーンを標準化されています。ポート制御プロトコル（PCP）は、直接ポートを開いて、キープアライブトラフィックを避けるために、ライフタイム値を交渉するNATと交渉するアプリケーションを可能にします。 PCPの詳細は、[PCP-BASE]で見つけることができます。
The authors would like to acknowledge the role of Mark Townsley for his input on the overall architecture of this technology by pointing this work in the direction of [SNAT]. Note that this document results from a merging of [DURAND-DS-LITE] and [SNAT]. Also to be acknowledged are the many discussions with a number of people including Shin Miyakawa, Katsuyasu Toyama, Akihide Hiura, Takashi Uematsu, Tetsutaro Hara, Yasunori Matsubayashi, and Ichiro Mizukoshi. The authors would also like to thank David Ward, Jari Arkko, Thomas Narten, and Geoff Huston for their constructive feedback. Special thanks go to Dave Thaler and Dan Wing for their reviews and comments.
著者は、[SNAT]の方向にこの作業を指すことによって、この技術の全体的なアーキテクチャの彼の入力のためのマークTownsleyの役割を認識したいと思います。なお、[デュランDS-LITE]および[SNAT]の併合からこのドキュメントをもたらします。また、認められる宮川晋、Katsuyasu富山、明秀Hiura、隆植松、徹太郎原、保典松林、および一郎水越含めた人々の数は多くの議論があります。著者はまた、彼らの建設的なフィードバックのためのデビッド・ウォード、ヤリArkko、トーマスNarten氏、そしてジェフ・ヒューストンに感謝したいと思います。特別な感謝は彼らのレビューとコメントのためデーブターラーとダン・ウイングに行きます。
Per this document, IANA has allocated a well-known IPv4 192.0.0.0/29 network prefix. That range is used to number the Dual-Stack Lite interfaces. Reserving a /29 allows for 6 possible interfaces on a multi-home node. The IPv4 address 192.0.0.1 is reserved as the IPv4 address of the default router for such Dual-Stack Lite hosts.
このドキュメントごとに、IANAは、よく知られているIPv4の192.0.0.0/29ネットワークプレフィックスを割り当てました。その範囲は、デュアルスタックライトインターフェイスに番号を付けるために使用されます。 / 29を予約することは、マルチホーム・ノード上の6つの可能なインターフェースを可能にします。 IPv4アドレス192.0.0.1は、デュアルスタックLiteのホストのデフォルトルータのIPv4アドレスとして予約されています。
Security issues associated with NAT have long been documented. See [RFC2663] and [RFC2993].
NATに関連するセキュリティ上の問題は、長い文書化されています。 [RFC2663]と[RFC2993]を参照してください。
However, moving the NAT functionality from the CPE to the core of the service provider network and sharing IPv4 addresses among customers create additional requirements when logging data for abuse usage. With any architecture where an IPv4 address does not uniquely represent an end host, IPv4 addresses and timestamps are no longer sufficient to identify a particular broadband customer. The AFTR should have the capability to log the tunnel-id, protocol, ports/IP addresses, and the creation time of the NAT binding to uniquely identify the user sessions. Exact details of what is logged are implementation specific and out of scope for this document.
虐待の使用のためのデータをロギングする場合ただし、サービスプロバイダーネットワークのコアにCPEからNAT機能を動かすと顧客の間のIPv4アドレスを共有する追加の要件を作成します。 IPv4アドレスは、一意のエンドホストを表していない任意のアーキテクチャと、IPv4アドレス及びタイムスタンプは、もはや特定のブロードバンド顧客を識別するのに十分ではありません。 AFTRは、トンネルID、プロトコル、ポート/ IPアドレスを記録する機能、および一意のユーザセッションを識別するために結合NATの作成時間を有するべきです。ログに記録されているものの正確な詳細は、このドキュメントのための特定と範囲の外に実装されています。
The AFTR performs translation functions for interior IPv4 hosts using RFC 1918 addresses or the IANA reserved address range (192.0.0.0/29). In some circumstances, an ISP may provision policies in the AFTR and instruct the AFTR to bypass translation functions based on <IPv4 Address, port number, protocol>. When the AFTR receives a packet with matching information of the policy from the interior host, the AFTR can simply forward the packet without translation. The addresses, ports, and protocol information must be provisioned on the AFTR before receiving the packet. The provisioning mechanism is out of scope for this specification.
AFTRは、RFC 1918のアドレス又はIANA予約アドレス範囲（192.0.0.0/29）を使用してホストの内部IPv4の変換機能を実行します。いくつかの状況では、ISPはAFTRにおけるプロビジョニングポリシーとは、<、プロトコルのIPv4アドレス、ポート番号>に基づいて、変換関数をバイパスするAFTRを指示してもよいです。 AFTRは、内部ホストからポリシーの情報と一致したパケットを受信すると、AFTRは単に翻訳せずにパケットを転送することができます。アドレス、ポート、およびプロトコル情報は、パケットを受信する前にAFTRにプロビジョニングされなければなりません。プロビジョニング機構は、本明細書の範囲外です。
When decapsulating packets, the AFTR MUST only forward packets sourced by RFC 1918 addresses, an IANA reserved address range, or any other out-of-band pre-authorized addresses. The AFTR MUST drop all other packets. This prevents rogue devices from launching denial-of-service attacks using unauthorized public IPv4 addresses in the IPv4 source header field or an unauthorized transport port range in the IPv4 transport header field. For example, rogue devices could bombard a public web server by launching a TCP SYN ACK attack [RFC4987]. The victim will receive TCP SYN from random IPv4 source addresses at a rapid rate and deny TCP services to legitimate users.
RFC 1918アドレスをソースパケット、AFTRがなければならない唯一のフォワードパケットをデカプセル化するとき、IANAは、アドレス範囲、または任意の他の帯域外事前許可アドレスを予約しました。 AFTRは、他のすべてのパケットを廃棄しなければなりません。これは、IPv4ソースヘッダーフィールドまたはIPv4トランスポートヘッダフィールドの不正輸送ポート範囲内で不正パブリックIPv4アドレスを使用して、サービス拒否攻撃を起動から不正なデバイスのを防止します。例えば、不正デバイスは、TCP SYN ACK攻撃[RFC4987]を起動して、パブリックWebサーバに衝突可能性があります。被害者は急速にランダムのIPv4送信元アドレスからのTCP SYNを受信して、正当なユーザーにTCPサービスを拒否します。
With IPv4 addresses shared by multiple users, ports become a critical resource. As such, some mechanisms need to be put in place by an AFTR to limit port usage, either by rate-limiting new connections or putting a hard limit on the maximum number of ports usable by a single user. If this number is high enough, it should not interfere with normal usage and still provide reasonable protection of the shared pool. More considerations on sharing IPv4 addresses can be found in [RFC6269]. Other considerations and recommendations on logging can be found in [RFC6302].
複数のユーザーで共有IPv4アドレスを使用すると、ポートが重要なリソースとなります。そのため、いくつかのメカニズムは、いずれかの律速新しい接続を、または単一ユーザが使用可能なポートの最大数にハードリミットを置くことによって、ポートの使用を制限するAFTRによって所定の位置においておく必要があります。この数が十分に高い場合、それは通常の使用に干渉し、まだ共有プールの合理的な保護を提供するべきではありません。 IPv4アドレスを共有する上でより多くの考慮事項は、[RFC6269]で見つけることができます。ロギングのその他の考慮事項および勧告は、[RFC6302]で見つけることができます。
AFTRs should support ways to limit service only to registered customers. One simple option is to implement an IPv6 ingress filter on the AFTR's tunnel interface to accept only the IPv6 address range defined in the filter.
AFTRsは、登録ユーザのみにサービスを制限する方法をサポートする必要があります。一つの簡単なオプションは、フィルタで定義された唯一のIPv6アドレス範囲を受け入れるようにAFTRのトンネルインターフェイスでのIPv6イングレスフィルタを実装することです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473]コンタ、A.、およびS.デアリング、 "IPv6の仕様の汎用パケットトンネリング"、RFC 2473、1998年12月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmarkと、E.とR.ギリガン、 "IPv6ホストとルータのための基本的な変遷メカニズム"、RFC 4213、2005年10月。
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, August 2009.
[RFC5625]ベリス、R.、 "DNSプロキシ実装ガイドライン"、BCP 152、RFC 5625、2009年8月。
[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", RFC 6334, August 2011.
[RFC6334]ハンキンズ、D.とT. Mrugalski、 "IPv6の動的ホスト構成プロトコル（DHCPv6）デュアルスタックLiteのオプション"、RFC 6334、2011年8月。
[DURAND-DS-LITE] Durand, A., "Dual-stack lite broadband deployments post IPv4 exhaustion", Work in Progress, July 2008.
[DURAND-DS-LITE]デュランは、A.は、進歩、2008年7月に仕事を "デュアルスタックliteのブロードバンドの導入は、IPv4枯渇を投稿します"。
[LSN-REQS] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common requirements for Carrier Grade NAT (CGN)", Work in Progress, July 2011.
[LSN-REQS]ペロー、S.、エド。、山形、I.、宮川、S.、中川、A.、およびH.芦田、 "キャリアグレードNAT（CGN）のための一般的な要件"、進歩、7月に作業2011。
[PCP-BASE] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", Work in Progress, July 2011.
[PCP-BASE]ウイング、D.、エド。、チェシャー、S.、Boucadair、M.、Penno、R.、およびP.セルカーク、 "ポート制御プロトコル（PCP）"、進歩、2011年7月での作業。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、B.、Karrenberg、D.、グルート、G.、およびE.リアド、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh、P.とM.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993]ハイン、T.、 "NATの建築的意味"、RFC 2993、2000年11月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。
[RFC4787] Audet, F., Ed., and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787] Audet、F.、エド。、およびC.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、BCP 127、RFC 4787、2007年1月。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007.
[RFC4987]エディ、W.、 "TCPのSYNフラッド攻撃と共通の軽減策"、RFC 4987、2007年8月。
[RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", RFC 5320, February 2010.
[RFC5320]テンプリン、F.、エド。、 "サブネットワークのカプセル化とアダプテーション層（SEAL）"、RFC 5320、2010年2月。
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[RFC5382]グハ、S.、エド。、ビスワス、K.、フォード、B.、シバクマー、S.、およびP. Srisuresh、 "TCPのためのNATの行動の要件"、BCP 142、RFC 5382、2008年10月。
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, April 2009.
[RFC5508] Srisuresh、P.、フォード、B.、シバクマー、S.、およびS.グハ、 "ICMPのためのNAT行動要件"、BCP 148、RFC 5508、2009年4月。
[RFC5571] Storer, B., Pignataro, C., Ed., Dos Santos, M., Stevant, B., Ed., Toutain, L., and J. Tremblay, "Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2)", RFC 5571, June 2009.
[RFC5571]のStorer、B.、Pignataro、C.、エド。、ドス・サントス、M.、Stevant、B.、編。、Toutain、L.、及びJ.トレンブレイ、「Softwireハブおよびレイヤ2つと展開フレームワークのスポークはトンネリングプロトコルバージョン2（L2TPv2）」、RFC 5571、2009年6月。
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
[RFC6269]フォード、M.、Boucadair、M.、デュラン、A.、リーバイス、P.、およびP.ロバーツ、RFC 6269、2011年6月、 "IPアドレスの共有に関する問題"。
[RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, "Logging Recommendations for Internet-Facing Servers", BCP 162, RFC 6302, June 2011.
[RFC6302]デュラン、A.、Gashinsky、I.、リー、D.、およびS.シェパード、 "インターネットに接続しているサーバーのログ勧告"、BCP 162、RFC 6302、2011年6月。
[SNAT] Droms, R. and B. Haberman, "Softwires Network Address Translation (SNAT)", Work in Progress, July 2008.
[SNAT] Droms、R.とB.ハーバーマン、 "Softwiresネットワークアドレス変換（SNAT）"、進歩、2008年7月に作業。
Appendix A. Deployment Considerations
付録A.展開の考慮事項
A.1. AFTR Service Distribution and Horizontal Scaling
A.1。サービス分配および水平スケーリングAFTR
One of the key benefits of the Dual-Stack Lite technology lies in the fact that it is a tunnel-based solution. As such, tunnel endpoints can be anywhere in the service provider network.
デュアルスタックライト技術の主な利点の一つは、トンネルベースのソリューションであるという事実にあります。このように、トンネルエンドポイントは、サービスプロバイダネットワーク内のどこであってもよいです。
Using the DHCPv6 tunnel endpoint option [RFC6334], service providers can create groups of users sharing the same AFTR. Those groups can be merged or divided at will. This leads to a horizontally scaled solution, where more capacity is added with more AFTRs. As those groups of users can evolve over time, it is best to make sure that AFTRs do not require per-user configuration in order to provide service.
DHCPv6のトンネルエンドポイントオプション[RFC6334]を使用して、サービスプロバイダは同じAFTRを共有するユーザーのグループを作成することができます。これらのグループは、合併や意志で分割することができます。これは、より多くの容量をよりAFTRsが付加され、水平スケーリング溶液をもたらします。ユーザーのこれらのグループは、時間をかけて進化することができるように、それはAFTRsがサービスを提供するために、ユーザごとの設定を必要としないことを確認する最善の方法です。
A.2. Horizontal Scaling
A.2。水平方向のスケーリング
A service provider can start using just a few centralized AFTRs. Later, when more capacity is needed, more AFTRs can be added and pushed closer to the edges of the access network.
サービスプロバイダは、わずか数の集中AFTRsを使用して起動することができます。より多くの容量が必要な場合、後で、よりAFTRsを添加し、アクセスネットワークのエッジに近い押し込むことができます。
A.3. High Availability
A.3。ハイアベイラビリティ
An important element in the design of the Dual-Stack Lite technology is the simplicity of implementation on the customer side. An IP4-in-IPv6 tunnel and a default route over it in the B4 element are all that is needed to get IPv4 connectivity. It is assumed that high availability is the responsibility of the service provider, not the customer devices implementing Dual-Stack Lite. As such, a single IPv6 address of the tunnel endpoint is provided in the DHCPv6 option defined in [RFC6334]. Specific means to achieve high availability on the service provider side are outside the scope of this specification.
デュアルスタックライト技術の設計における重要な要素は、顧客側での実装が簡単です。 IP4インのIPv6トンネルとB4の要素で、それ以上のデフォルトルートは、IPv4接続を取得するために必要なことすべてです。高可用性、サービスプロバイダの責任ではなく、デュアルスタックライトを実装し、顧客のデバイスであるとします。このように、トンネルエンドポイントの単一のIPv6アドレスは[RFC6334]で定義されたDHCPv6オプションで提供されます。サービスプロバイダ側で高可用性を実現するための具体的手段は、本明細書の範囲外です。
A.4. Logging
A.4。ロギング
DS-Lite AFTR implementation should offer the functionality to log NAT binding creations or other ways to keep track of the ports/IP addresses used by customers. This is both to support troubleshooting, which is very important to service providers trying to figure out why something may not be working, and to meet region-specific requirements for responding to legally binding requests for information from law enforcement authorities.
実装AFTR DS-Liteは、NATバインディング創造や顧客が使用するポート/ IPアドレスを追跡する他の方法をログに記録する機能を提供すべきです。これは、両方のは、何かが働いてないかもしれない理由を把握しようとしているサービスプロバイダにとって非常に重要である、トラブルシューティングをサポートするために、法執行当局からの情報のための法的拘束力の要求に対応するための地域固有の要件を満たすことです。
Appendix B. Examples
付録B.例
B.1. Gateway-Based Architecture
B.1。ゲートウェイベースのアーキテクチャ
This architecture is targeted at residential broadband deployments but can be adapted easily to other types of deployment where the installed base of IPv4-only devices is important.
このアーキテクチャは、家庭用ブロードバンドの展開を対象としていますが、IPv4専用デバイスのインストールベースが重要であり、展開の他のタイプに容易に適合させることができます。
Consider a scenario where a Dual-Stack Lite CPE is provisioned only with IPv6 in the WAN port, not IPv4. The CPE acts as an IPv4 DHCP server for the LAN (wireline and wireless) handing out [RFC1918] addresses. In addition, the CPE may support IPv6 Auto-Configuration and/or a DHCPv6 server for the LAN. When an IPv4-only device connects to the CPE, that CPE will hand out a [RFC1918] address to the device. When a dual-stack-capable device connects to the CPE, that CPE will hand out a [RFC1918] address and a global IPv6 address to the device. Besides, the CPE will create an IPv4-in-IPv6 softwire tunnel [RFC5571] to an AFTR that resides in the service provider network.
デュアルスタックLiteのCPE WANポートのみでのIPv6、IPv4のではないがプロビジョニングされているシナリオを考えてみましょう。 CPEは、[RFC1918]のアドレスを配っLAN（有線および無線）のIPv4 DHCPサーバとして機能します。また、CPEは、IPv6自動設定および/またはLANのためのDHCPv6サーバをサポートすることができます。 IPv4のみのデバイスは、CPEデバイスに[RFC1918]アドレスを配るすること、CPEに接続したとき。デュアルスタック可能なデバイスは、CPEに接続すると、そのCPEは、[RFC1918]アドレス及びデバイスに対してグローバルIPv6アドレスを配るであろう。また、CPEは、サービスプロバイダネットワーク内に存在AFTRへのIPv4型のIPv6 softwireトンネル[RFC5571]を作成します。
When the device accesses IPv6 service, it will send the IPv6 datagram to the CPE natively. The CPE will route the traffic upstream to the IPv6 default gateway.
デバイスがIPv6サービスにアクセスすると、それはネイティブCPEへのIPv6データグラムを送信します。 CPEは、上流IPv6デフォルトゲートウェイへのトラフィックをルーティングされます。
When the device accesses IPv4 service, it will source the IPv4 datagram with the [RFC1918] address and send the IPv4 datagram to the CPE. The CPE will encapsulate the IPv4 datagram inside the IPv4-in-IPv6 softwire tunnel and forward the IPv6 datagram to the AFTR. This is in contrast to what the CPE normally does today, which is to NAT the [RFC1918] address to the public IPv4 address and route the datagram upstream. When the AFTR receives the IPv6 datagram, it will decapsulate the IPv6 header and perform an IPv4-to-IPv4 NAT on the source address.
デバイスがIPv4サービスにアクセスする場合、それは[RFC1918]アドレスとのIPv4データグラムのソースおよびCPEへのIPv4データグラムを送信します。 CPEは、IPv4内IPv6のsoftwireトンネル内のIPv4データグラムをカプセル化しAFTRにIPv6データグラムを転送します。これは、CPEは、通常、データグラム上流のパブリックIPv4アドレスとルートに[RFC1918]アドレスがNATにある、今日何をするかとは対照的です。 AFTRがIPv6データグラムを受信すると、IPv6ヘッダをデカプセル化し、送信元アドレスでIPv4対IPv4のNATを実行します。
As illustrated in Figure 1, this Dual-Stack Lite deployment model consists of three components: the Dual-Stack Lite home router with a B4 element, the AFTR, and a softwire between the B4 element acting as softwire initiator (SI) [RFC5571] in the Dual-Stack Lite home router and the softwire concentrator (SC) [RFC5571] in the AFTR. The AFTR performs IPv4-IPv4 NAT translations to multiplex multiple subscribers through a pool of global IPv4 addresses. Overlapping address spaces used by subscribers are disambiguated through the identification of tunnel endpoints.
B4要素を有するデュアルスタックライトホームルータ、AFTR、及びsoftwire開始剤（SI）として作用B4要素[RFC5571]の間softwire図1に示すように、このデュアルスタックLiteの配置モデルは、3つの成分からなりますデュアルスタックライトホームルータとAFTRでsoftwireコンセントレータ（SC）[RFC5571]インチAFTRは、グローバルIPv4アドレスのプールを介して複数の加入者を多重化するのIPv4-IPv4のNAT変換を実行します。加入者によって使用される重複アドレス空間は、トンネルエンドポイントの識別を介して非曖昧化されています。
+-----------+
| Host |
+-----+-----+
|10.0.0.1
|
|
|10.0.0.2
+---------|---------+
| | |
| Home router |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
|||2001:db8:0:1::1
|||
|||<-IPv4-in-IPv6 softwire
|||
-------|||-------
/ ||| \
| ISP core network |
\ ||| /
-------|||-------
|||
|||2001:db8:0:2::1
+--------|||--------+
| AFTR |
|+--------+--------+|
|| Concentrator ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
|192.0.2.1
|
--------|--------
/ | \
| Internet |
\ | /
--------|--------
|
|198.51.100.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 1: Gateway-Based Architecture
図1：ゲートウェイベースのアーキテクチャ
Notes:
ノート：
o The Dual-Stack Lite home router is not required to be on the same link as the host.
Oデュアルスタックライトホームルータはホストと同じリンク上にある必要はありません。
o The Dual-Stack Lite home router could be replaced by a Dual-Stack Lite router in the service provider network.
Oデュアルスタックライトホームルータは、サービスプロバイダーネットワークのデュアルスタックLiteのルータに置き換えることができます。
The resulting solution accepts an IPv4 datagram that is translated into an IPv4-in-IPv6 softwire datagram for transmission across the softwire. At the corresponding endpoint, the IPv4 datagram is decapsulated, and the translated IPv4 address is inserted based on a translation from the softwire.
得られた溶液をsoftwire横切る送信のためのIPv4型のIPv6 softwireデータグラムに変換されたIPv4データグラムを受け入れます。対応するエンドポイントでのIPv4データグラムはデカプセル化され、そして翻訳IPv4アドレスはsoftwireからの翻訳に基づいて挿入されています。
B.1.1. Example Message Flow
B.1.1。例メッセージフロー
In the example shown in Figure 2, the translation tables in the AFTR are configured to forward between IP/TCP (10.0.0.1/10000) and IP/TCP (192.0.2.1/5000). That is, a datagram received by the Dual-Stack Lite home router from the host at address 10.0.0.1, using TCP DST port 10000, will be translated to a datagram with IPv4 SRC address 192.0.2.1 and TCP SRC port 5000 in the Internet.
図2に示す例では、AFTRにおける変換テーブルは、IP / TCP（10.0.0.1/10000）およびIP / TCP（192.0.2.1/5000）との間で転送するように構成されています。これは、TCP DSTポート10000を使用してアドレス10.0.0.1のホストからデュアルスタックライトホームルータが受信したデータグラムは、インターネットでのIPv4 SRCアドレス192.0.2.1およびTCP SRCポート5000でデータグラムに変換されますされます。
+-----------+
| Host |
+-----+-----+
| |10.0.0.1
IPv4 datagram 1 | |
| |
v |10.0.0.2
+---------|---------+
| | |
| home router |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
| |||2001:db8:0:1::1
IPv6 datagram 2| |||
| |||<-IPv4-in-IPv6 softwire
-----|-|||-------
/ | ||| \
| ISP core network |
\ | ||| /
-----|-|||-------
| |||
| |||2001:db8:0:2::1
+------|-|||--------+
| | AFTR |
| v ||| |
|+--------+--------+|
|| Concentrator ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
| |192.0.2.1
IPv4 datagram 3 | |
| |
-----|--|--------
/ | | \
| Internet |
\ | | /
-----|--|--------
| |
v |198.51.100.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 2: Outbound Datagram
図2：送信データグラム
+-----------------+--------------+-----------------+
| Datagram | Header field | Contents |
+-----------------+--------------+-----------------+
| IPv4 datagram 1 | IPv4 Dst | 198.51.100.1 |
| | IPv4 Src | 10.0.0.1 |
| | TCP Dst | 80 |
| | TCP Src | 10000 |
| --------------- | ------------ | ------------- |
| IPv6 datagram 2 | IPv6 Dst | 2001:db8:0:2::1 |
| | IPv6 Src | 2001:db8:0:1::1 |
| | IPv4 Dst | 198.51.100.1 |
| | IPv4 Src | 10.0.0.1 |
| | TCP Dst | 80 |
| | TCP Src | 10000 |
| --------------- | ------------ | ------------- |
| IPv4 datagram 3 | IPv4 Dst | 198.51.100.1 |
| | IPv4 Src | 192.0.2.1 |
| | TCP Dst | 80 |
| | TCP Src | 5000 |
+-----------------+--------------+-----------------+
Datagram Header Contents
データグラムヘッダーの内容
When datagram 1 is received by the Dual-Stack Lite home router, the B4 element encapsulates the datagram in datagram 2 and forwards it to the Dual-Stack Lite carrier-grade NAT over the softwire.
データグラム1は、デュアルスタックライトホームルータによって受信されると、B4要素は、データグラム2にデータグラムをカプセル化し、softwireオーバーデュアルスタックライトキャリアグレードNATに転送します。
When the tunnel concentrator in the AFTR receives datagram 2, it forwards the IPv4 datagram to the NAT, which determines from its NAT table that the datagram received on the softwire with TCP SRC port 10000 should be translated to datagram 3 with IPv4 SRC address 192.0.2.1 and TCP SRC port 5000.
AFTRトンネルコンセントレータがデータグラム2を受信すると、TCP SRCポート10000とsoftwire上で受信されたデータグラムは、IPv4 SRCでデータグラム3に変換する必要があることを、そのNATテーブルから決定NAT、へのIPv4データグラムを転送192.0に対処。 2.1およびTCP SRCポート5000。
Figure 3 shows an inbound message received at the AFTR. When the NAT function in the AFTR receives datagram 1, it looks up the IP/TCP DST information in its translation table. In the example in Figure 3, the NAT changes the TCP DST port to 10000, sets the IP DST address to 10.0.0.1, and forwards the datagram to the softwire. The B4 in the home router decapsulates the IPv4 datagram from the inbound softwire datagram and forwards it to the host.
図3は、AFTRで受信インバウンド・メッセージを示しています。 AFTRでのNAT機能は、データグラム1を受信すると、その変換テーブルにIP / TCP DST情報を検索します。図3の例では、NATが10000 TCP DSTポートを変更し、10.0.0.1にIP DSTアドレスを設定し、softwireにデータグラムを転送します。ホームルータでのB4は、インバウンドsoftwireデータグラムからのIPv4データグラムのカプセル化を解除し、ホストに転送します。
+-----------+
| Host |
+-----+-----+
^ |10.0.0.1
IPv4 datagram 3 | |
| |
| |10.0.0.2
+---------|---------+
| +-+-+ |
| home router |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
^ |||2001:db8:0:1::1
IPv6 datagram 2 | |||
| |||<-IPv4-in-IPv6 softwire
| |||
-----|-|||-------
/ | ||| \
| ISP core network |
\ | ||| /
-----|-|||-------
| |||
| |||2001:db8:0:2::1
+------|-|||--------+
| AFTR |
|+--------+--------+|
|| Concentrator ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
^ |192.0.2.1
IPv4 datagram 1 | |
| |
-----|--|--------
/ | | \
| Internet |
\ | | /
-----|--|--------
| |
| |198.51.100.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 3: Inbound Datagram
図3：受信データグラム
+-----------------+--------------+-----------------+
| Datagram | Header field | Contents |
+-----------------+--------------+-----------------+
| IPv4 datagram 1 | IPv4 Dst | 192.0.2.1 |
| | IPv4 Src | 198.51.100.1 |
| | TCP Dst | 5000 |
| | TCP Src | 80 |
| --------------- | ------------ | ------------- |
| IPv6 datagram 2 | IPv6 Dst | 2001:db8:0:1::1 |
| | IPv6 Src | 2001:db8:0:2::1 |
| | IPv4 Dst | 10.0.0.1 |
| | IPv4 Src | 198.51.100.1 |
| | TCP Dst | 10000 |
| | TCP Src | 80 |
| --------------- | ------------ | ------------- |
| IPv4 datagram 3 | IPv4 Dst | 10.0.0.1 |
| | IPv4 Src | 198.51.100.1 |
| | TCP Dst | 10000 |
| | TCP Src | 80 |
+-----------------+--------------+-----------------+
Datagram Header Contents
データグラムヘッダーの内容
B.1.2. Translation Details
B.1.2。翻訳の詳細
The AFTR has a NAT that translates between softwire/port pairs and IPv4-address/port pairs. The same translation is applied to IPv4 datagrams received on the device's external interface and from the softwire endpoint in the device.
AFTRはsoftwire /ポートのペアとIPv4アドレス/ポートのペアの間で変換するNATを持っています。同一の翻訳は、デバイスの外部インターフェイスに、デバイスにおけるsoftwireエンドポイントから受信したIPv4データグラムに適用されます。
In Figure 2, the translator network interface in the AFTR is on the Internet, and the softwire interface connects to the Dual-Stack Lite home router. The AFTR translator is configured as follows:
図2では、AFTRにおける翻訳者のネットワーク・インタフェースは、インターネット上で、softwireインターフェイスはデュアルスタックLiteのホームルータに接続します。次のようにAFTR翻訳者が設定されています。
Network interface: Translate IPv4 destination address and TCP destination port to the softwire identifier and TCP destination port
ネットワークインターフェイス：IPv4宛先アドレスおよびTCP宛先ポートはsoftwire識別子およびTCP宛先ポートに翻訳します
Softwire interface: Translate softwire identifier and TCP source port to IPv4 source address and TCP source port
Softwireインタフェース：IPv4ソースアドレスとTCP送信元ポートにsoftwire識別子とTCP送信元ポートを翻訳
Here is how the translation in Figure 3 works:
図3の翻訳がどのように動作するかここにあります：
o Datagram 1 is received on the AFTR translator network interface. The translator looks up the IPv4-address/port pair in its translator table, rewrites the IPv4 destination address to 10.0.0.1 and the TCP source port to 10000, and forwards the datagram to the softwire.
Oデータグラム1はAFTRトランスレータネットワークインターフェイス上で受信されます。翻訳者が翻訳テーブル内のIPv4アドレス/ポートのペアを検索し、10000に10.0.0.1へのIPv4宛先アドレスとTCP送信元ポートを書き換え、softwireにデータグラムを転送します。
o The IPv4 datagram is received on the Dual-Stack Lite home router B4. The B4 function extracts the IPv4 datagram, and the Dual-Stack Lite home router forwards datagram 3 to the host.
OのIPv4データグラムは、デュアルスタックLiteのホームルータのB4に受信されます。 B4機能は、IPv4データグラムを抽出し、デュアルスタックライトホームルータはホストにデータグラム3を転送します。
+------------------------------------+--------------------+
| Softwire-Id/IPv4/Prot/Port | IPv4/Prot/Port |
+------------------------------------+--------------------+
| 2001:db8:0:1::1/10.0.0.1/TCP/10000 | 192.0.2.1/TCP/5000 |
+------------------------------------+--------------------+
Dual-Stack Lite Carrier-Grade NAT Translation Table
デュアルスタックLiteのキャリアグレードNAT変換テーブル
The Softwire-Id is the IPv6 address assigned to the Dual-Stack Lite CPE. Hosts behind the same Dual-Stack Lite home router have the same Softwire-Id. The source IPv4 address is the [RFC1918] address assigned by the Dual-Stack home router and is unique to each host behind the CPE. The AFTR would receive packets sourced from different IPv4 addresses in the same softwire tunnel. The AFTR combines the Softwire-Id and IPv4 address/port [Softwire-Id, IPv4+ Port] to uniquely identify the host behind the same Dual-Stack Lite home router.
Softwire-IdはデュアルスタックLiteのCPEに割り当てられたIPv6アドレスです。同じデュアルスタックライトホームルータの背後にあるホストは同じSoftwire-IDを持っています。送信元IPv4アドレスは、デュアルスタックホームルータによって割り当てられた[RFC1918]アドレスであり、CPEの背後にある各ホストに固有のものです。 AFTRは同じsoftwireトンネルに異なるIPv4アドレスから発信パケットを受信します。 AFTRは一意に同じデュアルスタックライトホームルータの背後にあるホストを識別するために、[Softwire-ID、IPv4の+ポート] Softwire-IDとIPv4アドレス/ポートを兼ね備えています。
B.2. Host-Based Architecture
B.2。ホストベースのアーキテクチャ
This architecture is targeted at new, large-scale deployments of dual-stack-capable devices implementing a Dual-Stack Lite interface.
このアーキテクチャは、デュアルスタックLiteのインタフェースを実装するデュアルスタック対応デバイスの新しい、大規模な展開を対象としています。
Consider a scenario where a Dual-Stack Lite host device is directly connected to the service provider network. The host device is dual-stack capable but only provisioned with an IPv6 global address. Besides, the host device will pre-configure a well-known IPv4 non-routable address; see Section 10 (IANA Considerations). This well-known IPv4 non-routable address is similar to the 127.0.0.1 loopback address. Every host device that implements Dual-Stack Lite will pre-configure the same address. This address will be used to source the IPv4 datagram when the device accesses IPv4 services. Besides, the host device will create an IPv4-in-IPv6 softwire tunnel to an AFTR. The carrier-grade NAT will reside in the service provider network.
デュアルスタックLiteのホストデバイスは、サービスプロバイダのネットワークに直接接続されているシナリオを考えてみましょう。ホストデバイスはデュアルスタック対応だけIPv6グローバルアドレスがプロビジョニングされています。また、ホスト装置は、周知のIPv4ルーティング不可能なアドレスを事前に設定します。第10節（IANAの考慮事項）を参照してください。これはよく知られているIPv4のルーティング不能アドレスは、127.0.0.1のループバックアドレスに似ています。デュアルスタックライトを実装するすべてのホストデバイスは、同じアドレスを事前に設定します。デバイスがIPv4サービスにアクセスしたときに、このアドレスは、IPv4データグラムを供給するために使用されます。また、ホスト装置はAFTRへのIPv4型のIPv6 softwireトンネルを作成します。キャリアグレードNATは、サービスプロバイダーのネットワークに存在します。
When the device accesses IPv6 service, the device will send the IPv6 datagram natively to the default gateway.
デバイスがIPv6サービスにアクセスすると、デバイスはデフォルトゲートウェイにネイティブIPv6データグラムを送信します。
When the device accesses IPv4 service, it will source the IPv4 datagram with the well-known non-routable IPv4 address. Then, the host device will encapsulate the IPv4 datagram inside the IPv4-in-IPv6 softwire tunnel and send the IPv6 datagram to the AFTR. When the AFTR receives the IPv6 datagram, it will decapsulate the IPv6 header and perform IPv4-to-IPv4 NAT on the source address.
デバイスは、IPv4サービスにアクセスすると、それがよく知られている非ルーティング可能なIPv4アドレスとIPv4のデータグラムを供給します。次に、ホスト装置は、IPv4内IPv6のsoftwireトンネル内のIPv4データグラムをカプセル化しAFTRにIPv6データグラムを送信します。 AFTRがIPv6データグラムを受信すると、IPv6ヘッダをデカプセル化し、送信元アドレスでIPv4対IPv4のNATを実行します。
This scenario works on both wireline and wireless networks. A typical wireless device will connect directly to the service provider without a CPE in between.
このシナリオでは、有線ネットワークと無線ネットワークの両方で動作します。典型的な無線装置は、間にCPEことなく、サービスプロバイダに直接接続します。
As illustrated in Figure 4, this Dual-Stack Lite deployment model consists of three components: the Dual-Stack Lite host, the AFTR, and a softwire between the softwire initiator B4 in the host and the softwire concentrator in the AFTR. The Dual-Stack Lite host is assumed to have IPv6 service and can exchange IPv6 traffic with the AFTR.
デュアルスタックライトホスト、AFTR、および宿主におけるsoftwireイニシエータB4とAFTRでsoftwireコンセントレータ間softwire：図4に示すように、このデュアルスタックLiteの配置モデルは、3つの成分からなります。デュアルスタックLiteのホストがIPv6サービスを持っていると仮定され、AFTRでIPv6トラフィックを交換することができます。
The AFTR performs IPv4-IPv4 NAT translations to multiplex multiple subscribers through a pool of global IPv4 addresses. Overlapping IPv4 address spaces used by the Dual-Stack Lite hosts are disambiguated through the identification of tunnel endpoints.
AFTRは、グローバルIPv4アドレスのプールを介して複数の加入者を多重化するのIPv4-IPv4のNAT変換を実行します。デュアルスタックライトホストによって使用される重複IPv4アドレス空間は、トンネルエンドポイントの識別を介して非曖昧化されています。
In this situation, the Dual-Stack Lite host configures the IPv4 address 192.0.0.2 out of the well-known range 192.0.0.0/29 (defined by IANA) on its B4 interface. It also configures the first non-reserved IPv4 address of the reserved range, 192.0.0.1, as the address of its default gateway.
この状況では、デュアルスタックライトホストは、B4のインターフェイス上で（IANAによって定義される）は、周知の範囲192.0.0.0/29のうちIPv4アドレス192.0.0.2を設定します。それはまた、そのデフォルトゲートウェイのアドレスとして、予約された範囲の最初の非予約IPv4アドレス192.0.0.1を構成します。
+-------------------+
| |
| Host 192.0.0.2 |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
|||2001:db8:0:1::1
|||
|||<-IPv4-in-IPv6 softwire
|||
-------|||-------
/ ||| \
| ISP core network |
\ ||| /
-------|||-------
|||
|||2001:db8:0:2::1
+--------|||--------+
| AFTR |
|+--------+--------+|
|| Concentrator ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
|192.0.2.1
|
--------|--------
/ | \
| Internet |
\ | /
--------|--------
|
|198.51.100.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 4: Host-Based Architecture
図4：ホストベースのアーキテクチャ
The resulting solution accepts an IPv4 datagram that is translated into an IPv4-in-IPv6 softwire datagram for transmission across the softwire. At the corresponding endpoint, the IPv4 datagram is decapsulated, and the translated IPv4 address is inserted based on a translation from the softwire.
得られた溶液をsoftwire横切る送信のためのIPv4型のIPv6 softwireデータグラムに変換されたIPv4データグラムを受け入れます。対応するエンドポイントでのIPv4データグラムはデカプセル化され、そして翻訳IPv4アドレスはsoftwireからの翻訳に基づいて挿入されています。
B.2.1. Example Message Flow
B.2.1。例メッセージフロー
In the example shown in Figure 5, the translation tables in the AFTR are configured to forward between IP/TCP (192.0.0.2/10000) and IP/TCP (192.0.2.1/5000). That is, a datagram received from the host at address 192.0.0.2, using TCP DST port 10000, will be translated to a datagram with IPv4 SRC address 192.0.2.1 and TCP SRC port 5000 in the Internet.
図5に示す例では、AFTRにおける変換テーブルは、IP / TCP（192.0.0.2/10000）およびIP / TCP（192.0.2.1/5000）との間で転送するように構成されています。これは、TCP DSTポート10000を使用して、アドレス192.0.0.2のホストから受信したデータグラムは、インターネットでのIPv4 SRCアドレス192.0.2.1およびTCP SRCポート5000でデータグラムに変換されますされています。
+-------------------+
| |
|Host 192.0.0.2 |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
| |||2001:db8:0:1::1
IPv6 datagram 1| |||
| |||<-IPv4-in-IPv6 softwire
| |||
-----|-|||-------
/ | ||| \
| ISP core network |
\ | ||| /
-----|-|||-------
| |||
| |||2001:db8:0:2::1
+------|-|||--------+
| | AFTR |
| v ||| |
|+--------+--------+|
|| Concentrator ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
| |192.0.2.1
IPv4 datagram 2 | |
-----|--|--------
/ | | \
| Internet |
\ | | /
-----|--|--------
| |
v |198.51.100.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 5: Outbound Datagram
図5：送信データグラム
+-----------------+--------------+-----------------+
| Datagram | Header field | Contents |
+-----------------+--------------+-----------------+
| IPv6 datagram 1 | IPv6 Dst | 2001:db8:0:2::1 |
| | IPv6 Src | 2001:db8:0:1::1 |
| | IPv4 Dst | 198.51.100.1 |
| | IPv4 Src | 192.0.0.2 |
| | TCP Dst | 80 |
| | TCP Src | 10000 |
| --------------- | ------------ | ------------- |
| IPv4 datagram 2 | IPv4 Dst | 198.51.100.1 |
| | IPv4 Src | 192.0.2.1 |
| | TCP Dst | 80 |
| | TCP Src | 5000 |
+-----------------+--------------+-----------------+
Datagram Header Contents
データグラムヘッダーの内容
When sending an IPv4 packet, the Dual-Stack Lite host encapsulates it in datagram 1 and forwards it to the AFTR over the softwire.
IPv4パケットを送信する場合、デュアルスタックLiteのホストは、データグラムの1でそれをカプセル化し、softwire以上AFTRに転送します。
When it receives datagram 1, the concentrator in the AFTR hands the IPv4 datagram to the NAT, which determines from its translation table that the datagram received on the softwire with TCP SRC port 10000 should be translated to datagram 3 with IPv4 SRC address 192.0.2.1 and TCP SRC port 5000.
それは、TCP SRCポート10000でsoftwire上で受信したデータグラムは、IPv4 SRCアドレス192.0.2.1にデータグラム3に変換する必要があることをその変換テーブルから決定NATにデータグラム1、AFTR手にコンセントレータのIPv4データグラムを受信すると、およびTCPポートSRC 5000。
Figure 6 shows an inbound message received at the AFTR. When the NAT function in the AFTR receives datagram 1, it looks up the IP/TCP DST in its translation table. In the example in Figure 6, the NAT translates the TCP DST port to 10000, sets the IP DST address to 192.0.0.2, and forwards the datagram to the softwire. The B4 inside the host decapsulates the IPv4 datagram from the inbound softwire datagram, and forwards it to the host's application layer.
図6は、AFTRで受信された受信メッセージを示します。 AFTRでのNAT機能は、データグラム1を受信すると、その変換テーブルにIP / TCPのDSTを検索します。図6の例では、NATは、10000 TCP DSTポートを変換192.0.0.2にIP DSTアドレスを設定し、softwireにデータグラムを転送します。ホスト内のB4は、インバウンドsoftwireデータグラムからのIPv4データグラムのカプセル化を解除し、ホストのアプリケーション層に転送します。
+-------------------+
| |
|Host 192.0.0.2 |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
^ |||2001:db8:0:1::1
IPv6 datagram 2 | |||
| |||<-IPv4-in-IPv6 softwire
| |||
-----|-|||-------
/ | ||| \
| ISP core network |
\ | ||| /
-----|-|||-------
| |||
| |||2001:db8:0:2::1
+------|-|||--------+
| AFTR |
| | ||| |
|+--------+--------+|
|| Concentrator ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
^ |192.0.2.1
IPv4 datagram 1 | |
-----|--|--------
/ | | \
| Internet |
\ | | /
-----|--|--------
| |
| |198.51.100.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 6: Inbound Datagram
図6：受信データグラム
+-----------------+--------------+-----------------+
| Datagram | Header field | Contents |
+-----------------+--------------+-----------------+
| IPv4 datagram 1 | IPv4 Dst | 192.0.2.1 |
| | IPv4 Src | 198.51.100.1 |
| | TCP Dst | 5000 |
| | TCP Src | 80 |
| --------------- | ------------ | ------------- |
| IPv6 datagram 2 | IPv6 Dst | 2001:db8:0:1::1 |
| | IPv6 Src | 2001:db8:0:2::1 |
| | IPv4 Dst | 192.0.0.2 |
| | IPv4 Src | 198.51.100.1 |
| | TCP Dst | 10000 |
| | TCP Src | 80 |
+-----------------+--------------+-----------------+
Datagram Header Contents
データグラムヘッダーの内容
B.2.2. Translation Details
B.2.2。翻訳の詳細
The AFTR translation steps are the same as in Appendix B.1.2. One difference is that all the host-based B4s will use the same well-known IPv4 address 192.0.0.2. To uniquely identify the host-based B4, the AFTR will use the host-based B4's IPv6 address, which is unique for the host.
AFTR翻訳の手順は、付録B.1.2と同じです。 1つの違いは、すべてのホストベースのB4Sは同じよく知られているIPv4アドレス192.0.0.2を使用することです。ユニークなホストベースのB4を特定するには、AFTRは、ホストに固有のホストベースのB4のIPv6アドレスを使用します。
+-------------------------------------+--------------------+
| Softwire-Id/IPv4/Prot/Port | IPv4/Prot/Port |
+-------------------------------------+--------------------+
| 2001:db8:0:1::1/192.0.0.2/TCP/10000 | 192.0.2.1/TCP/5000 |
+-------------------------------------+--------------------+
Dual-Stack Lite Carrier-Grade NAT Translation Table
デュアルスタックLiteのキャリアグレードNAT変換テーブル
The Softwire-Id is the IPv6 address assigned to the Dual-Stack host. Each host has a unique Softwire-Id. The source IPv4 address is one of the well-known IPv4 addresses. The AFTR could receive packets from different hosts sourced from the same IPv4 well-known address from different softwire tunnels. Similar to the gateway architecture, the AFTR combines the Softwire-Id and IPv4 address/port [Softwire-Id, IPv4+Port] to uniquely identify the individual host.
Softwire-Idはデュアルスタックホストに割り当てられたIPv6アドレスです。各ホストは独自のSoftwire-IDを持っています。送信元IPv4アドレスは、よく知られているIPv4アドレスの一つです。 AFTRは異なるsoftwireトンネルから同じIPv4の周知のアドレスから発信異なるホストからのパケットを受信することができます。ゲートウェイ・アーキテクチャーと同様、AFTR一意個々のホストを識別するために、[Softwire-ID、IPv4の+ポート] Softwire-IDとIPv4アドレス/ポートの組み合わせ。
Authors' Addresses
著者のアドレス
Alain Durand Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089-1206 USA
アラン・デュランジュニパーネットワークスの1194北マチルダアベニューサニーベール、CA 94089から1206 USA
EMail: adurand@juniper.net
メールアドレス：adurand@juniper.net
Ralph Droms Cisco 1414 Massachusetts Avenue Boxborough, MA 01714 USA
ラルフDromsシスコ1414マサチューセッツアベニューボックスボロー、MA 01714 USA
EMail: rdroms@cisco.com
メールアドレス：rdroms@cisco.com
James Woodyatt Apple 1 Infinite Loop Cupertino, CA 95014 USA
ジェームズWoodyattアップル1無限ループクパチーノ、CA 95014 USA
EMail: jhw@apple.com
メールアドレス：jhw@apple.com
Yiu L. Lee Comcast One Comcast Center Philadelphia, PA 19103 USA
耀輝L.リーComcastの一つコムキャストセンター、フィラデルフィア、PA 19103 USA
EMail: yiu_lee@cable.comcast.com
メールアドレス：yiu_lee@cable.comcast.com