[要約] RFC 6333は、IPv4アドレスの枯渇後のデュアルスタックライトブロードバンド展開に関するガイドラインです。このRFCの目的は、IPv4アドレスの不足を解決するために、デュアルスタックライト技術を使用してIPv6を導入する方法を提案することです。
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
IPv4疲労後のデュアルスタックライトブロードバンド展開
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を展開するコストと利点をより適切に調整することを目的としたデュアルスタックライトテクノロジーを導入します。デュアルスタックライトを使用すると、ブロードバンドサービスプロバイダーは、IP（IPv4- in-IPV6）とネットワークアドレスの翻訳（NAT）の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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................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（IPv4-in-IPv6）とネットワークアドレス翻訳（NAT）の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.
このドキュメントでは、最初にいくつかの展開シナリオを提示し、次にデュアルスタックライトテクノロジーの2つの要素の動作を定義します：基本的なブリッジングブロードバンド（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 Basic Bridging Broadband（B4）ElementとDS-Lite Address Family Transition Router（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:
ナットのカスケードに依存する代わりに、デュアルスタックライトモデルはIPv4-in-IPV6トンネル上に構築され、ネットワークを横断してキャリアグレードのIPv4-IPV4 NAT（AFTR）に到達し、顧客がIPv4アドレスを共有します。このアプローチには多くの利点があります。
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.
DS-LITE CPEは、NAT関数がサービスプロバイダーのネットワークのAFTRによって実行されるため、内部インターフェイスとB4インターフェイスの間の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.
ただし、自宅のホストにアドレス空間（例：192.168.0.0/16）を配布する独自のDHCP（V4）サーバーを操作する必要があります。デフォルトのIPv4ルーターとして、それらのホームホストに宣伝する必要があります。また、DHCPオプション6（DNSサーバー）のDNSサーバーとしても宣伝する必要があります。さらに、DNSプロキシを操作して、セクション5.5で説明されているように、在宅ホストからDNS IPv4要求を受け入れ、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は、通常のIPv4パケットを転送するのと同じように、B4インターフェイスを介してそれらの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-in-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サーバーにDNS要求をIPv6を介して送信する必要があります。
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要素は、直接接続されたデバイスまたはCPEのいずれかのデュアルスタック対応ノードに実装された関数であり、AFTRへのトンネルを作成します。
The tunnel is a multipoint-to-point IPv4-in-IPv6 tunnel ending on a service provider AFTR.
トンネルは、サービスプロバイダーAFTRで終了するマルチポイントからポイントへのIPv4-in-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-in-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.
カプセル化（IPv4-in-IPV6など）を使用してIPv4を介してIPv4トラフィックを運ぶと、データグラムの有効なMTUが減少します。残念ながら、Path MTU Discovery [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.
この問題に対処する解決策は、サービスプロバイダーがB4要素とAFTR要素の間のすべてのリンクのMTUサイズを少なくとも40バイト増加させることです。IPv6パケットを断片化することなくIPv6カプセル化ヘッダーとIPv4データグラムの両方に対応することです。。
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を増やすことができるわけではないため、発信リンクMTUが追加のIPv6ヘッダーに対応できない場合、B4要素はフラグメンテーションと再組み立てを実行する必要があります。元の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-in-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を使用してサービスプロバイダーからのみ構成されています。そのため、DHCPV6（またはIPv6を介した他の同様の方法）を介して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アドレスをダウンストリームIPv6ノードに渡すことができますが、ダウンストリームIPv4ノードには渡すことはできません。そのため、[RFC5625]の推奨に従って、B4要素は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は、初期化中に1つのテクノロジーのみを起動するように選択する必要があります。たとえば、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-in-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要素に予約されています。サービスプロバイダーにB4要素が192.0.0.2を使用するのを防ぐ特別な構成がある場合、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-in-IPV6トンネルエンドポイントとIPv4-IPV4 NATの組み合わせです。
The tunnel is a point-to-multipoint IPv4-in-IPv6 tunnel ending at the B4 elements.
トンネルは、B4要素で終わるポイントツーマルチポイントIPv4-in-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-in-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つの断片化されたパケットが到着するのを待つ必要があります。これには、断片化されたパケットをバッファ化して追跡するには、トンネル出口ポイントが必要です。AFTRは、多くのトンネルのトンネル出口ポイントであると考えてください。多くのデバイスがAFTRを介して管理されたB4要素に多数の断片化されたパケットを同時に調達する場合、これにより、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.
TCP最大セグメントサイズ（MSS）オプションの書き換えや、[RFC5320]で定義されているサブネットワークのカプセル化および適応層などのテクノロジーを使用するなど、断片化を回避する方法は、このドキュメントの範囲外です。
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は、IANAが予約した有名なIPv4アドレス192.0.0.1を使用して、IPv4-in-IPv6トンネルを構成する必要があります。そのアドレスを使用して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つのインターフェイスがあります。各インターフェイスには、それに割り当てられたばらつきのプールがあります。別のケースでは、AFTRに実装されているポリシーでは、1セットのB4SがNATプール1を使用し、B4Sの異なるセットがNATプール2を使用することを指定する場合があります。
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].
デュアルスタックLITE 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デバイス内のALGがNATを通過する必要があります。たとえば、アクティブなFTPでは、ALGを適切に動作させる必要があります。アルグはリソースを消費し、さまざまな種類のアルグがあります。AFTRは、多数のB4要素をサポートする共有ネットワークデバイスです。AFTRがすべての現在および将来のアルグを実装することは不可能です。
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ベース]で見つけることができます。
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]の方向に向けて、この技術の全体的なアーキテクチャに関する彼の意見について、マークタウンズリーの役割を認めたいと考えています。このドキュメントは、[durand-ds-lite]と[snat]のマージに起因することに注意してください。また、認められるべきことは、宮川清、屋下屋、akihide hiura、uematsu島、谷山ティツタロハラ、松下島、井田島などを含む多くの人々との多くの議論があります。著者はまた、建設的なフィードバックをしてくれたDavid Ward、Jari Arkko、Thomas Narten、Geoff Hustonにも感謝したいと思います。レビューとコメントをしてくれたDave ThalerとDan Wingに感謝します。
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ネットワークプレフィックスを割り当てています。その範囲は、デュアルスタックライトインターフェイスを番号にするために使用されます。A /29の予約により、マルチホームノードで6つの可能なインターフェイスが可能になります。IPv4アドレス192.0.0.1は、このようなデュアルスタックライトホストのデフォルトルーターの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.
ただし、NAT機能をCPEからサービスプロバイダーネットワークのコアに移動し、顧客間で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でポリシーを提供し、AFTRに<IPv4アドレス、ポート番号、プロトコル>に基づいて翻訳関数をバイパスするよう指示することができます。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.
パケットを脱カプセル化する場合、AFTRは、RFC 1918アドレス、IANA予約アドレス範囲、またはその他の帯域外の事前に許可されたアドレスによって供給されたパケットのみを転送する必要があります。AFTRは他のすべてのパケットをドロップする必要があります。これにより、Rogueデバイスは、IPv4ソースヘッダーフィールドの不正なパブリックIPv4アドレスまたはIPv4トランスポートヘッダーフィールドで許可されていないトランスポートポート範囲を使用して、サービス拒否攻撃を開始することを防ぎます。たとえば、Rogueデバイスは、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は、登録された顧客にのみサービスを制限する方法をサポートする必要があります。簡単なオプションの1つは、AFTRのトンネルインターフェイスにIPv6イングレスフィルターを実装して、フィルターで定義されたIPv6アドレス範囲のみを受け入れることです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473] Conta、A。およびS. Deering、「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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「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. Gilligan、「IPv6ホストとルーターの基本的な遷移メカニズム」、RFC 4213、2005年10月。
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, August 2009.
[RFC5625] Bellis、R。、「DNS Proxy実装ガイドライン」、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] Hankins、D。およびT. Mrugalski、「Dual Stack LiteのIPv6（DHCPV6）オプションの動的ホスト構成プロトコル」、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] Durand、A。、「IPv4疲労後のデュアルスタックLite Broadband Deployments」、2008年7月、進行中の作業。
[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] Perreault、S.、Ed。、Yamagata、I.、Miyakawa、S.、Nakagawa、A。、およびH. Ashida、「キャリアグレードNAT（CGN）の共通要件」、進行中の作業、7月、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] Wing、D.、Ed。、Cheshire、S.、Boucadair、M.、Penno、R.、およびP. Selkirk、「ポートコントロールプロトコル（PCP）」、2011年7月の作業。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、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.、Moskowitz、B.、Karrenberg、D.、De Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、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. Holdrege、「IPネットワークアドレス翻訳者（NAT）用語と考慮事項」、RFC 2663、1999年8月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993] Hain、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] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「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.、ed。、およびC. Jennings、「Unicast UDPのネットワークアドレス変換（NAT）行動要件」、BCP 127、RFC 4787、2007年1月。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007.
[RFC4987] Eddy、W。、「TCP Syn Flooding Attacks and Common Mitigations」、RFC 4987、2007年8月。
[RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", RFC 5320, February 2010.
[RFC5320] Templin、F.、ed。、「サブネットワークのカプセル化と適応層（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] Guha、S.、Ed。、Biswas、K.、Ford、B.、Sivakumar、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.、Ford、B.、Sivakumar、S。、およびS. Guha、「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.、Ed。、Dos Santos、M.、Stevant、B.、Ed。、Toutain、L.、およびJ. Tremblay、 "Softwire Hub and Skoke Deployment Framework with Layer Twoトンネルプロトコルバージョン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] Ford、M.、Boucadair、M.、Durand、A.、Levis、P。、およびP. Roberts、「IPアドレス共有の問題」、RFC 6269、2011年6月。
[RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, "Logging Recommendations for Internet-Facing Servers", BCP 162, RFC 6302, June 2011.
[RFC6302] Durand、A.、Gashinsky、I.、Lee、D。、およびS. Sheppard、「インターネット向けサーバーの推奨事項」、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. Haberman、「ソフトウェアネットワークアドレス翻訳（SNAT）」、2008年7月の作業。
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.
デュアルスタックライトテクノロジーの重要な利点の1つは、トンネルベースのソリューションであるという事実にあります。そのため、トンネルのエンドポイントは、サービスプロバイダーネットワークのどこにでもあります。
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を共有するユーザーのグループを作成できます。これらのグループは、統合または自由に分割することができます。これにより、水平方向にスケーリングされたソリューションが発生し、より多くのAFTRで容量が追加されます。ユーザーのグループは時間の経過とともに進化できるため、AFTRがサービスを提供するためにユーザーごとの構成を必要としないことを確認することをお勧めします。
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.
サービスプロバイダーは、いくつかの集中AFTRの使用を開始できます。後で、より多くの容量が必要な場合、より多くのAFTRを追加し、アクセスネットワークのエッジの近くに押し込むことができます。
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.
デュアルスタックLiteテクノロジーの設計における重要な要素は、顧客側での実装のシンプルさです。IP4-in-IPV6トンネルとB4要素の上のデフォルトルートは、IPv4接続を取得するために必要なすべてです。高可用性は、デュアルスタックライトを実装する顧客デバイスではなく、サービスプロバイダーの責任であると想定されています。そのため、[RFC6334]で定義されたDHCPV6オプションでトンネルエンドポイントの単一のIPv6アドレスが提供されています。サービスプロバイダー側で高可用性を達成するための特定の手段は、この仕様の範囲外です。
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.
DS-Lite AFTR実装は、顧客が使用するポート/IPアドレスを追跡するためのNATバインド作成またはその他の方法を記録する機能を提供する必要があります。これは、トラブルシューティングをサポートするためのものです。これは、何かが機能しない理由を理解しようとするサービスプロバイダーにとって非常に重要であり、法執行機関からの情報に対する法的拘束力のある要求に応答するための地域固有の要件を満たすためです。
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がIPv4ではなくWANポートのIPv6のみでプロビジョニングされるシナリオを考えてみましょう。CPEは、LAN（Wireline and Wireless）のアドレスを配るLAN（Wireline and Wireless）のIPv4 DHCPサーバーとして機能します。さらに、CPEは、LANのIPv6自動構成および/またはDHCPV6サーバーをサポートする場合があります。IPv4のみのデバイスがCPEに接続すると、そのCPEは[RFC1918]アドレスをデバイスに配ります。デュアルスタックで利用可能なデバイスがCPEに接続すると、そのCPEは[RFC1918]アドレスとグローバルIPv6アドレスをデバイスに配ります。その上、CPEは、IPv4-in-IPV6ソフトワイヤートンネル[RFC5571]をサービスプロバイダーネットワークに存在するAFTRに作成します。
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サービスにアクセスすると、IPv6データグラムがネイティブにCPEに送信されます。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データグラムを調達し、IPv4データグラムをCPEに送信します。CPEは、IPv4-in-IPV6ソフトワイヤートンネル内のIPv4データグラムをカプセル化し、IPv6データグラムをAFTRに転送します。これは、CPEが今日通常行うこととは対照的です。これは、[RFC1918]アドレスをパブリックIPv4アドレスにアドレスし、データグラムを上流にルーティングすることです。AFTRがIPv6データグラムを受信すると、IPv6ヘッダーを脱カプセル化し、ソースアドレスでIPv4-to-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.
図1に示すように、このデュアルスタックライト展開モデルは、B4要素を備えたデュアルスタックライトホームルーター、AFTR、およびB4要素の間のソフトワイヤーの3つのコンポーネントで構成されています。AFTRのデュアルスタックLite Home RouterとSoftwire Concentator（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 デュアルスタックライトホームルーターは、サービスプロバイダーネットワークのデュアルスタックライトルーターに置き換えることができます。
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.
結果のソリューションは、ソフトワイヤ全体に送信するためにIPv4-in-IPV6ソフトワイヤーデータグラムに変換されるIPv4データグラムを受け入れます。対応するエンドポイントでは、IPv4データグラムが脱カプセル化され、翻訳されたIPv4アドレスがソフトワイヤからの翻訳に基づいて挿入されます。
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.
Datagram 1がデュアルスタックLite Homeルーターによって受信されると、B4要素はデータグラム2のデータグラムをカプセル化し、ソフトワイヤーの上にデュアルスタックライトキャリアグレード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を受信すると、IPv4データグラムをNATに転送します。これは、TCP SRCポート10000を使用してソフトワイヤーで受信したデータグラムがIPv4 SRCアドレス192.0を搭載したデータグラム3に翻訳する必要があることをNATテーブルから決定します。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機能がDatagram 1を受信すると、翻訳テーブルのIP/TCP DST情報を調べます。図3の例では、NATはTCP DSTポートを10000に変更し、IP DSTアドレスを10.0.0.1に設定し、データグラムをソフトワイヤーに転送します。ホームルーターのB4は、インバウンドソフトワイヤーデータグラムから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
データグラムヘッダーの内容
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/PortペアとIPv4-Address/ポートペアの間に翻訳されるNATがあります。同じ翻訳は、デバイスの外部インターフェイスとデバイスのソフトワイヤーエンドポイントで受信した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 Homeルーターに接続されています。AFTR翻訳者は次のように構成されています。
Network interface: Translate IPv4 destination address and TCP destination port to the softwire identifier and TCP destination port
ネットワークインターフェイス：IPv4宛先アドレスとTCP宛先ポートをソフトワイヤー識別子とTCP宛先ポートに翻訳します
Softwire interface: Translate softwire identifier and TCP source port to IPv4 source address and TCP source port
Softwire Interface：Softwire IdentifierとTCPソースポートをIPv4ソースアドレスと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 Translator Networkインターフェイスで受信されます。翻訳者は、翻訳者テーブルでIPv4-Address/ポートペアを調べ、IPv4宛先アドレスを10.0.0.1に書き換え、TCPソースポートを10000に書き、データグラムをソフトワイヤーに転送します。
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データグラムは、デュアルスタックライトホームルーター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
デュアルスタックライトキャリアグレードの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アドレスです。同じデュアルスタックLite Homeルーターの背後にあるホストには、同じSoftwire-IDがあります。ソースIPv4アドレスは、デュアルスタックホームルーターによって割り当てられた[RFC1918]アドレスであり、CPEの背後にある各ホストに固有です。AFTRは、同じソフトワイヤートンネルの異なるIPv4アドレスから供給されたパケットを受け取ります。AFTRは、Softwire-IDとIPv4アドレス/ポート[Softwire-ID、IPv4ポート]を組み合わせて、同じデュアルスタックLite Homeルーターの背後にあるホストを一意に識別します。
This architecture is targeted at new, large-scale deployments of dual-stack-capable devices implementing a Dual-Stack Lite interface.
このアーキテクチャは、デュアルスタックライトインターフェイスを実装するデュアルスタック対応デバイスの新しい大規模な展開を対象としています。
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-in-IPV6ソフトワイヤートンネルを作成します。キャリアグレードの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-in-IPV6ソフトワイヤートンネル内のIPv4データグラムをカプセル化し、IPv6データグラムをAFTRに送信します。AFTRがIPv6データグラムを受信すると、IPv6ヘッダーを脱カプセル化し、ソースアドレスでIPv4-to-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の間に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.
図4に示すように、このデュアルスタックライト展開モデルは、デュアルスタックライトホスト、AFTR、およびホストのソフトワイヤーイニシエーターB4とAFTRのソフトワイヤーコンセントレーターの間の3つのコンポーネントで構成されています。デュアルスタックライトホストは、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.
この状況では、デュアルスタックLITEホストは、B4インターフェイスで有名な範囲192.0.0.0/29（IANAで定義）のうち、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.
結果のソリューションは、ソフトワイヤ全体に送信するためにIPv4-in-IPV6ソフトワイヤーデータグラムに変換されるIPv4データグラムを受け入れます。対応するエンドポイントでは、IPv4データグラムが脱カプセル化され、翻訳されたIPv4アドレスがソフトワイヤからの翻訳に基づいて挿入されます。
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パケットを送信すると、デュアルスタックライトホストはDatagram 1にカプセル化し、ソフトワイヤーを介して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.
Datagram 1を受信すると、AFTRの濃縮器がIPv4データグラムをNATに渡します。これは、TCP SRCポート10000を使用してソフトワイヤーで受信したデータグラムがIPv4 SRCアドレス192.0.2.11でデータグラム3に翻訳する必要があることを変換表から決定します。および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機能がDatagram 1を受信すると、翻訳テーブルでIP/TCP DSTを検索します。図6の例では、NATはTCP DSTポートを10000に変換し、IP DSTアドレスを192.0.0.2に設定し、データグラムをソフトワイヤーに転送します。ホスト内のB4は、インバウンドソフトワイヤーデータグラムから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
データグラムヘッダーの内容
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
デュアルスタックライトキャリアグレードの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アドレスの1つです。AFTRは、異なるソフトワイヤートンネルから同じIPv4のよく知られたアドレスから供給されたさまざまなホストからパケットを受信できます。ゲートウェイアーキテクチャと同様に、AFTRはSoftwire-IDとIPv4アドレス/ポート[SoftWire-ID、IPv4ポート]を組み合わせて、個々のホストを一意に識別します。
Authors' Addresses
著者のアドレス
Alain Durand Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089-1206 USA
Alain Durand Juniper Networks 1194 North Mathilda Avenue Sunnyvale、CA 94089-1206 USA
EMail: adurand@juniper.net
Ralph Droms Cisco 1414 Massachusetts Avenue Boxborough, MA 01714 USA
Ralph Droms Cisco 1414 Massachusetts Avenue Boxborough、MA 01714 USA
EMail: rdroms@cisco.com
James Woodyatt Apple 1 Infinite Loop Cupertino, CA 95014 USA
James Woodyatt Apple 1 Infinite Loop Cupertino、CA 95014 USA
EMail: jhw@apple.com
Yiu L. Lee Comcast One Comcast Center Philadelphia, PA 19103 USA
Yiu L. Lee Comcast One Comcast Center Philadelphia、PA 19103 USA
EMail: yiu_lee@cable.comcast.com