[要約] RFC 6908は、Dual-Stack Lite（DS-Lite）の展開に関する考慮事項を提供するものであり、IPv4とIPv6の両方をサポートするネットワーク環境の設計と展開に役立ちます。要約：DS-Liteの展開に関する考慮事項を提供するRFC。 目的：IPv4とIPv6の両方をサポートするネットワーク環境の設計と展開を支援する。
Internet Engineering Task Force (IETF) Y. Lee
Request for Comments: 6908 Comcast
Category: Informational R. Maglione
ISSN: 2070-1721 Cisco Systems
C. Williams
MCSR Labs
C. Jacquenet
M. Boucadair
France Telecom
March 2013
Deployment Considerations for Dual-Stack Lite
Dual-Stack Liteの導入に関する考慮事項
Abstract
概要
This document discusses the deployment issues of and the requirements for the deployment and operation of Dual-Stack Lite (DS-Lite). This document describes the various deployment considerations and applicability of the DS-Lite architecture.
このドキュメントでは、Dual-Stack Lite（DS-Lite）の展開に関する問題と、展開と操作の要件について説明します。このドキュメントでは、DS-Liteアーキテクチャのさまざまな導入に関する考慮事項と適用性について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6908.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6908で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Overview ........................................................3
2. AFTR Deployment Considerations ..................................3
2.1. Interface Consideration ....................................3
2.2. MTU and Fragmentation Considerations .......................4
2.3. Logging at the AFTR ........................................4
2.4. Blacklisting a Shared IPv4 Address .........................5
2.5. AFTR's Policies ............................................5
2.5.1. Outgoing Policy .....................................5
2.5.2. Incoming Policy .....................................6
2.6. AFTR Impacts on Accounting Process .........................6
2.7. Reliability Considerations of AFTR .........................7
2.8. Strategic Placement of AFTR ................................8
2.9. AFTR Considerations for Geographically Aware Services ......8
2.10. Impacts on QoS Policy .....................................9
2.11. Port Forwarding Considerations ............................9
2.12. DS-Lite Tunnel Security ..................................10
2.13. IPv6-Only Network Considerations .........................10
3. B4 Deployment Considerations ...................................10
3.1. DNS Deployment Considerations .............................11
3.2. IPv4 Service Monitoring ...................................11
3.2.1. B4 Remote Management ...............................11
3.2.2. IPv4 Connectivity Check ............................11
4. Security Considerations ........................................12
5. Acknowledgements ...............................................12
6. References .....................................................12
6.1. Normative References ......................................12
6.2. Informative References ....................................12
DS-Lite [RFC6333] is a transition technique that enables operators to multiplex public IPv4 addresses while provisioning only IPv6 to users. DS-Lite is designed to continue offering IPv4 services while operators upgrade their networks incrementally to IPv6. DS-Lite combines IPv4-in-IPv6 softwire [RFC2473] and Network Address Translator IPv4/IPv4 (NAT44) [RFC3022] to enable more than one user to share a public IPv4 address.
DS-Lite [RFC6333]は、オペレーターがIPv6のみをユーザーにプロビジョニングしながら、パブリックIPv4アドレスを多重化できる移行技術です。 DS-Liteは、オペレーターがネットワークをIPv6に段階的にアップグレードする間、IPv4サービスを提供し続けるように設計されています。 DS-Liteは、IPv4-in-IPv6ソフトワイヤー[RFC2473]とネットワークアドレス変換IPv4 / IPv4（NAT44）[RFC3022]を組み合わせて、複数のユーザーがパブリックIPv4アドレスを共有できるようにします。
While Appendix A of [RFC6333] explains how to deploy DS-Lite within specific scenarios, the purpose of this document is to describe problems that arise when deploying DS-Lite and what guidance should be taken to mitigate those issues. The information is based on real deployment experience and is compiled in one comprehensive document so that operators aren't required to search through various RFCs deciding which sections are applicable and impact their DS-Lite deployment.
[RFC6333]の付録Aでは特定のシナリオでDS-Liteを導入する方法を説明していますが、このドキュメントの目的は、DS-Liteを導入する際に発生する問題と、それらの問題を軽減するために取るべきガイダンスについて説明することです。情報は実際の導入経験に基づいており、1つの包括的なドキュメントにまとめられているため、オペレーターは適用可能なセクションを決定し、DS-Liteの導入に影響を与えるさまざまなRFCを検索する必要がありません。
Address Family Transition Router (AFTR) is a network element that is deployed inside the operator's network. An AFTR can be a stand-alone device or be embedded into a router. The AFTR is the IPv4-in-IPv6 tunnel termination point and the NAT44 device. It is deployed at the IPv4-IPv6 network border where the tunnel interface is IPv6 and the external NAT44 interface is IPv4. The Basic Bridging BroadBand (B4) element [RFC6333] is a function implemented on a dual-stack-capable node (either a host device or a home gateway) that creates a tunnel to an AFTR. Although an operator can configure both softwire tunnel termination and interface for NAT44 functions on a single physical interface (yet, keep them logically separated), there are scenarios we recommend to configure two individual interfaces (i.e., one dedicated for IPv4 and one dedicated for IPv6) to segregate the functions.
アドレスファミリトランジションルーター（AFTR）は、オペレーターのネットワーク内に展開されるネットワーク要素です。 AFTRは、スタンドアロンデバイスにすることも、ルーターに埋め込むこともできます。 AFTRは、IPv4-in-IPv6トンネルターミネーションポイントおよびNAT44デバイスです。これは、トンネルインターフェースがIPv6で外部NAT44インターフェースがIPv4であるIPv4-IPv6ネットワーク境界に配置されます。基本的なブリッジングBroadBand（B4）要素[RFC6333]は、AFTRへのトンネルを作成するデュアルスタック対応ノード（ホストデバイスまたはホームゲートウェイ）に実装される機能です。オペレーターは単一の物理インターフェイス上でNAT44機能のソフトワイヤートンネル終端とインターフェイスの両方を構成できます（ただし、論理的に分離したままにしてください）。 ）関数を分離します。
o The access network between the B4 and AFTR is an IPv6-only network, and the network between the AFTR and IPv4 network is an IPv4-only network. In this deployment scenario, the AFTR interface to the IPv6-only network and the interface to the IPv4 network should use two physical interfaces on the AFTR.
o B4とAFTRの間のアクセスネットワークはIPv6のみのネットワークであり、AFTRとIPv4ネットワークの間のネットワークはIPv4のみのネットワークです。この展開シナリオでは、IPv6のみのネットワークへのAFTRインターフェイスとIPv4ネットワークへのインターフェイスは、AFTRで2つの物理インターフェイスを使用する必要があります。
o Operators may use Operations Support System (OSS) tools (e.g., Multi Router Traffic Grapher) to collect interface data packet count information. If an operator wants to separate the softwire function and NAT44 function on different physical interfaces for collecting a data packet count, and the AFTR does not support packet count for logical interfaces, they should use two physical interfaces on the AFTR.
oオペレーターは、オペレーションサポートシステム（OSS）ツール（マルチルータートラフィックグラフなど）を使用して、インターフェースデータパケットカウント情報を収集できます。オペレーターがデータパケットカウントを収集するために異なる物理インターフェイスでソフトワイヤー機能とNAT44機能を分離する必要があり、AFTRが論理インターフェイスのパケットカウントをサポートしていない場合、AFTRで2つの物理インターフェイスを使用する必要があります。
DS-Lite is part tunneling protocol. Tunneling introduces overhead to the packet and decreases the effective MTU size after encapsulation. DS-Lite users may experience problems with applications such as not being able to download Internet pages or transfer large files.
DS-Liteは、一部のトンネリングプロトコルです。トンネリングにより、パケットにオーバーヘッドが発生し、カプセル化後に有効なMTUサイズが減少します。 DS-Liteユーザーは、インターネットページをダウンロードしたり、大きなファイルを転送したりできないなど、アプリケーションで問題が発生する可能性があります。
Since fragmentation and reassembly is not optimal, the operator should do everything possible to eliminate the need for it. If the operator uses simple IPv4-in-IPv6 softwire [RFC2473], it is recommended that the MTU size of the IPv6 network between the B4 and the AFTR accounts for the additional overhead (40 bytes). If the access network MTU size is fixed and cannot be changed, the operator should be aware that the B4 and the AFTR must support fragmentation as defined in [RFC6333]. The operator should also be aware that reassembly at the Tunnel Exit-Point is resource intensive as a large number of B4 may terminate on the same AFTR. Scalability of the AFTR is advised in this scenario.
断片化と再構成は最適ではないので、オペレーターは必要をなくすためにあらゆることを行う必要があります。オペレーターが単純なIPv4-in-IPv6ソフトワイヤー[RFC2473]を使用する場合、B4とAFTR間のIPv6ネットワークのMTUサイズが追加のオーバーヘッド（40バイト）を占めるようにすることをお勧めします。アクセスネットワークのMTUサイズが固定されていて変更できない場合、オペレータは、B4とAFTRが[RFC6333]で定義されているフラグメンテーションをサポートする必要があることを認識しておく必要があります。オペレーターはまた、トンネル出口ポイントでの再組み立ては、大量のB4が同じAFTRで終了する可能性があるため、リソースを大量に消費することにも注意する必要があります。このシナリオでは、AFTRのスケーラビリティが推奨されます。
A source-specific log is essential for backtracking specific hosts when a problem is identified with one of the AFTR's NAT-ed addresses. The source-specific log contains the B4 IPv6 source address, transport protocol, source port, and source IPv4 address after it has been NAT-ed. Using the source-specific log, operators can uniquely identify a specific host when a DS-Lite host experiences problems accessing the IPv4 network. To maximize IPv4 shared ratio, an operator may configure a short timeout value for NAT44 entries. This will result in a large number of logs created by the AFTR. For operators who desire to aggregate the logs, they can configure the AFTR to preallocate a range of ports to each B4. This range of ports will be used in the NAT44 function, and the AFTR will create one log entry for the whole port range. This aggregation can significantly reduce the log size for source-specific logging.
ソース固有のログは、AFTRのNAT処理されたアドレスの1つで問題が特定された場合に、特定のホストをバックトラックするために不可欠です。ソース固有のログには、B4 IPv6ソースアドレス、トランスポートプロトコル、ソースポート、NAT変換後のソースIPv4アドレスが含まれます。 DS-LiteホストでIPv4ネットワークへのアクセスに問題が発生した場合、オペレーターはソース固有のログを使用して、特定のホストを一意に識別できます。 IPv4共有比率を最大化するために、オペレーターはNAT44エントリーの短いタイムアウト値を構成できます。これにより、AFTRによって多数のログが作成されます。ログを集約することを望むオペレーターは、各B4にポートの範囲を事前に割り当てるようにAFTRを構成できます。このポート範囲はNAT44機能で使用され、AFTRはポート範囲全体に対して1つのログエントリを作成します。この集計により、ソース固有のログのログサイズを大幅に削減できます。
Some operators may require logging both source and destination information for a host's connections. This is called a destination-specific log. A destination-specific log contains the B4's IPv6 address, transport protocol, source port, source IPv4 address after it has been NAT-ed, destination port, and destination IPv4 address. A destination-specific log is session-based; the operators should be aware that they will not be able to aggregate log entries. When using a destination-specific log, the operator must be careful of the large number of log entries created by the AFTR. Some AFTR implementations may keep the logs in their main memory. This may be CPU and memory resource intensive. The operators should configure the AFTR to periodically send logs to storage facility and then purge them from the AFTR.
一部のオペレーターは、ホストの接続のソースと宛先の両方の情報をログに記録する必要がある場合があります。これは、宛先固有のログと呼ばれます。宛先固有のログには、B4のIPv6アドレス、トランスポートプロトコル、ソースポート、NAT変換後のソースIPv4アドレス、宛先ポート、および宛先IPv4アドレスが含まれます。宛先固有のログはセッションベースです。オペレーターは、ログエントリを集計できないことに注意してください。宛先固有のログを使用する場合、オペレーターはAFTRによって作成される多数のログエントリに注意する必要があります。一部のAFTR実装では、ログをメインメモリに保持する場合があります。これは、CPUおよびメモリリソースを大量に消費する可能性があります。オペレーターは、ログをストレージ施設に定期的に送信し、AFTRからログをパージするようにAFTRを構成する必要があります。
The AFTR is a NAT device. It enables multiple B4s to share a single public IPv4 address. [RFC6269] discusses some considerations when sharing an IPv4 address. When a public IPv4 address is blacklisted by a remote peer, this may affect multiple users or hosts. Operators deploying DS-Lite should be aware that Internet hosts may not be aware that a given single IPv4 address is actually shared by multiple B4s. A content provider might block services for a shared IPv4 address and this would then impact all B4s sharing this particular IPv4 address. The operator would be likely to receive calls related to service outage and would then need to take appropriate corrective actions. [RFC6302] describes necessary information required to identify a user or host in shared address environment. It is also worth mention that [NAT-REVEAL] analyses different approaches to identify a user or host in a shared address environment.
AFTRはNATデバイスです。複数のB4が単一のパブリックIPv4アドレスを共有できるようにします。 [RFC6269]は、IPv4アドレスを共有する際の考慮事項について説明しています。パブリックIPv4アドレスがリモートピアによってブラックリストに登録されている場合、これは複数のユーザーまたはホストに影響を与える可能性があります。 DS-Liteを展開するオペレーターは、インターネットホストが特定の単一のIPv4アドレスが実際に複数のB4によって共有されていることを認識していない場合があることに注意する必要があります。コンテンツプロバイダーが共有IPv4アドレスのサービスをブロックする場合、これはこの特定のIPv4アドレスを共有するすべてのB4に影響を与えます。オペレーターは、サービスの停止に関連する問い合わせを受ける可能性が高く、適切な修正措置を講じる必要があります。 [RFC6302]は、共有アドレス環境でユーザーまたはホストを識別するために必要な情報を記述しています。 [NAT-REVEAL]は、共有アドレス環境でユーザーまたはホストを識別するためのさまざまなアプローチを分析することにも言及する価値があります。
There are two types of AFTR policies:
AFTRポリシーには2つのタイプがあります。
o Outgoing Policies apply to packets originating from B4 to the AFTR. These policies should be provisioned on the AFTR's IPv6 interface that is connected to the B4s.
o 発信ポリシーは、B4からAFTRに発信されるパケットに適用されます。これらのポリシーは、B4に接続されているAFTRのIPv6インターフェースでプロビジョニングする必要があります。
o Incoming Policies apply to packets originating from IPv4 networks to B4s. These policies should be provisioned on the IPv4 interface connected to the IPv4 network.
o 着信ポリシーは、IPv4ネットワークからB4に送信されるパケットに適用されます。これらのポリシーは、IPv4ネットワークに接続されたIPv4インターフェイスでプロビジョニングする必要があります。
Outgoing Policies may include Access Control List (ACL) and Quality of Service (QoS) settings. These policies control the packets from B4s to the AFTR. For example, the operator may configure the AFTR only to accept B4 connections that originated from specific IPv6 prefixes configured in the AFTR. More discussion of this use case can be found in Section 2.12. An operator may configure the AFTR to give priority to the packets marked by certain Differentiated Services Code Point (DSCP) values [RFC2475]. Furthermore, an AFTR may also apply an Outgoing Policy to limit the rate of port allocation for a single B4's IPv6 address.
送信ポリシーには、アクセス制御リスト（ACL）とサービス品質（QoS）の設定が含まれる場合があります。これらのポリシーは、B4からAFTRへのパケットを制御します。たとえば、オペレーターは、AFTRで構成された特定のIPv6プレフィックスから発信されたB4接続のみを受け入れるようにAFTRを構成できます。この使用例の詳細については、セクション2.12を参照してください。オペレーターは、特定のDiffServコードポイント（DSCP）値[RFC2475]によってマークされたパケットを優先するようにAFTRを構成できます。さらに、AFTRは、送信ポリシーを適用して、単一のB4のIPv6アドレスに対するポート割り当てのレートを制限することもできます。
Some operators offer different service level agreements (SLAs) to users to meet their requirements. Some users may require more ports and some may require different service priority. In this deployment scenario, the operator can implement Outgoing Policies specified to a user's B4 or a group of B4s sharing the same policies.
一部の事業者は、ユーザーの要件を満たすためにさまざまなサービスレベルアグリーメント（SLA）をユーザーに提供しています。より多くのポートが必要なユーザーもいれば、異なるサービス優先度が必要なユーザーもいます。この展開シナリオでは、オペレーターは、ユーザーのB4または同じポリシーを共有するB4のグループに指定された送信ポリシーを実装できます。
Similar to the Outgoing Policy, an Incoming Policy may also include ACL and QoS settings. The Outgoing Policy controls packets coming from the IPv4 network to the B4s. Incoming packets are normally treated equally, so these policies are globally applied. For example, an operator wants to use a predefined DSCP value to signal the IPv6 access network to apply certain traffic policies. In this deployment scenario, the operator can configure the AFTR to mark the incoming packets with the predefined DSCP value. This policy will apply to all incoming packets from the IPv4 network.
送信ポリシーと同様に、受信ポリシーにもACLおよびQoS設定が含まれる場合があります。送信ポリシーは、IPv4ネットワークからB4に送信されるパケットを制御します。着信パケットは通常同等に扱われるため、これらのポリシーはグローバルに適用されます。たとえば、オペレータは、事前定義されたDSCP値を使用して、特定のトラフィックポリシーを適用するようにIPv6アクセスネットワークに信号を送りたいと考えています。この展開シナリオでは、オペレーターは、事前定義されたDSCP値で着信パケットをマークするようにAFTRを構成できます。このポリシーは、IPv4ネットワークからのすべての着信パケットに適用されます。
This section discusses IPv4 and IPv6 traffic accounting in the DS-Lite environment. In a typical broadband access scenario (e.g., DSL or Cable), the B4 is embedded in a Residential Gateway. The edge router for the B4s in the provider's network is an IPv6 edge router. The edge router is usually responsible for IPv6 accounting and the user management functions such as authentication, authorization, and accounting (AAA). However, given the fact that IPv4 traffic is encapsulated in an IPv6 packet at the B4 and only decapsulated at the AFTR, the edge router will require additional functionality to associate IPv4 accounting information to the B4 IPv6 address. If DS-Lite is the only application using the IPv4-in-IPv6 protocol in the IPv6 access network, the operator can configure the edge router to check the IPv6 Next Header field in the IPv6 header, identify the protocol type (i.e., 0x04), and collect IPv4 accounting information.
このセクションでは、DS-Lite環境でのIPv4およびIPv6トラフィックアカウンティングについて説明します。一般的なブロードバンドアクセスシナリオ（DSLやケーブルなど）では、B4は住宅用ゲートウェイに組み込まれています。プロバイダーのネットワーク内のB4のエッジルーターはIPv6エッジルーターです。エッジルーターは通常、IPv6アカウンティングと、認証、承認、アカウンティング（AAA）などのユーザー管理機能を担当します。ただし、IPv4トラフィックがB4でIPv6パケットにカプセル化され、AFTRでのみカプセル化解除されるという事実を考慮すると、エッジルーターには、IPv4アカウンティング情報をB4 IPv6アドレスに関連付ける追加機能が必要になります。 DS-LiteがIPv6アクセスネットワークでIPv4-in-IPv6プロトコルを使用する唯一のアプリケーションである場合、オペレーターはIPv6ヘッダーのIPv6次ヘッダーフィールドをチェックし、プロトコルタイプ（つまり0x04）を特定するようにエッジルーターを構成できます。 、およびIPv4アカウンティング情報を収集します。
Alternatively, the AFTR may perform accounting for IPv4 traffic. However, operators must be aware that this will introduce some challenges, especially in DSL deployment. In DSL deployment, the AAA transaction normally happens between the edge router (i.e., Broadband Network Gateway) and AAA server. [RFC6333] does not require the AFTR to interact with the AAA server or edge router. Thus, the AFTR may not have the AAA parameters (e.g., Account Session ID) associated with B4s to generate an IPv4 accounting record. IPv4 traffic accounting at the AFTR is not recommended when the AAA parameters necessary to generate complete IPv4 accounting records are not available. The accounting process at the AFTR is only necessary if the operator requires separating per-B4 accounting records for IPv4 and IPv6 traffic. If the per-B4 IPv6 accounting records, collected by the edge router, are sufficient, then the additional complexity of enabling IPv4 accounting at the AFTR is not required. It is important to notice that, since the IPv4 traffic is encapsulated in IPv6 packets, the data collected by the edge router for IPv6 traffic already contains the total amount of traffic (i.e., IPv4 and IPv6).
または、AFTRはIPv4トラフィックのアカウンティングを実行する場合があります。ただし、オペレーターは、これにより、特にDSLの展開において、いくつかの課題が生じることを認識しておく必要があります。 DSL展開では、AAAトランザクションは通常、エッジルーター（つまり、ブロードバンドネットワークゲートウェイ）とAAAサーバーの間で発生します。 [RFC6333]は、AFTRがAAAサーバーまたはエッジルーターと対話することを必要としません。したがって、AFTRには、IPv4アカウンティングレコードを生成するためのB4に関連付けられたAAAパラメータ（アカウントセッションIDなど）がない場合があります。完全なIPv4アカウンティングレコードを生成するために必要なAAAパラメータが利用できない場合、AFTRでのIPv4トラフィックアカウンティングは推奨されません。 AFTRでのアカウンティングプロセスは、オペレーターがIPv4トラフィックとIPv6トラフィックのB4ごとのアカウンティングレコードを分離する必要がある場合にのみ必要です。エッジルーターによって収集されたB4ごとのIPv6アカウンティングレコードで十分な場合は、AFTRでIPv4アカウンティングを有効にするための追加の複雑さは不要です。 IPv4トラフィックはIPv6パケットにカプセル化されているため、エッジルーターがIPv6トラフィック用に収集したデータには、トラフィックの合計量（IPv4とIPv6）がすでに含まれていることに注意してください。
Even if detailed accounting records collection for IPv4 traffic may not be required, it would be useful for an operator, in some scenarios, to have information that the edge router generates for the IPv6 traffic. This information can be used to identify the AFTR who is handling the IPv4 traffic for that B4. This can be achieved by adding additional information to the IPv6 accounting records. For example, operators can use RADIUS attribute information specified in [RFC6519] or a new attribute to be specified in Internet Protocol Detailed Record (IPDR).
IPv4トラフィックの詳細なアカウンティングレコードの収集が不要な場合でも、一部のシナリオでは、オペレーターがエッジルーターがIPv6トラフィック用に生成する情報があると便利です。この情報は、そのB4のIPv4トラフィックを処理しているAFTRを識別するために使用できます。これは、IPv6アカウンティングレコードに追加情報を追加することで実現できます。たとえば、オペレーターは[RFC6519]で指定されたRADIUS属性情報、またはインターネットプロトコル詳細レコード（IPDR）で指定される新しい属性を使用できます。
For robustness, reliability, and load distribution purposes, operators may deploy multiple AFTRs. In such cases, the IPv6 prefixes and algorithm to build the tunneling mechanisms configured on each of these AFTRs will be the same. In [RFC6333], Appendix A.3 mentions that High Availability (HA) is the operator's responsibility. Since DS-Lite is a stateful mechanism, all requirements for load-balancing and failover mechanisms apply. There are many ways to implement HA in a stateful mechanism; the most common are Cold Standby mode and Hot Standby mode. More discussion on deploying these two modes for NAT can be found in [NAT-STANDBY]. In Cold Standby mode, the AFTR states are not replicated from the Primary AFTR to the Backup AFTR. When the Primary AFTR fails, all the existing established sessions will be flushed out. The internal hosts are required to reestablish sessions with the external hosts. In Hot Standby mode, the session's states are replicated on-the-fly from the Primary AFTR to the Backup AFTR. When the Primary AFTR fails, the Backup AFTR will take over all the existing established sessions. In this mode, the internal hosts are not required to reestablish sessions with the external hosts.
堅牢性、信頼性、および負荷分散の目的で、オペレーターは複数のAFTRを展開できます。そのような場合、これらの各AFTRで構成されたトンネリングメカニズムを構築するためのIPv6プレフィックスとアルゴリズムは同じになります。 [RFC6333]の付録A.3では、高可用性（HA）はオペレーターの責任であると述べています。 DS-Liteはステートフルメカニズムであるため、ロードバランシングおよびフェイルオーバーメカニズムのすべての要件が適用されます。ステートフルメカニズムでHAを実装する方法はたくさんあります。最も一般的なのは、コールドスタンバイモードとホットスタンバイモードです。 NATのこれら2つのモードの展開に関する詳細は、[NAT-STANDBY]を参照してください。コールドスタンバイモードでは、AFTRの状態はプライマリAFTRからバックアップAFTRに複製されません。プライマリAFTRが失敗すると、既存の確立されたすべてのセッションがフラッシュされます。内部ホストは、外部ホストとのセッションを再確立するために必要です。ホットスタンバイモードでは、セッションの状態がプライマリAFTRからバックアップAFTRにその場で複製されます。プライマリAFTRに障害が発生すると、バックアップAFTRが既存の確立済みセッションをすべて引き継ぎます。このモードでは、内部ホストは外部ホストとのセッションを再確立する必要はありません。
For operators, the decision to use Cold Standby mode or Hot Standby mode depends on the trade-off between capital cost and operational cost. Cold Standby mode does not require a Backup Standby AFTR to synchronize session states. This simplifies the operational model. When the Primary AFTR goes down, any AFTR with extra capacity can take over. Hot Standby mode provides a smoother failover experience to users; the cost for the operators is more careful failover planning. For most deployment scenarios, we believe that Cold Standby mode should be sufficient enough and is thus recommended.
オペレーターにとって、コールドスタンバイモードとホットスタンバイモードのどちらを使用するかは、資本コストと運用コストのトレードオフに依存します。コールドスタンバイモードでは、セッションステートを同期するためにバックアップスタンバイAFTRは必要ありません。これにより、運用モデルが簡素化されます。プライマリAFTRがダウンすると、追加の容量を持つAFTRが引き継ぐことができます。ホットスタンバイモードは、よりスムーズなフェールオーバーエクスペリエンスをユーザーに提供します。オペレーターのコストは、より慎重なフェイルオーバー計画です。ほとんどの展開シナリオでは、コールドスタンバイモードで十分であると考えられるため、このモードをお勧めします。
In the DS-Lite environment, the AFTR is the logical next-hop router of the B4s to access the IPv4 network, so the placement of the AFTR will affect the traffic flows in the access network and overall network design. In general, there are two placement models to deploy an AFTR. Model One deploys the AFTR at the edge of the network to cover a small region. Model Two deploys the AFTR at the core of the network to cover a large region.
DS-Lite環境では、AFTRはIPv4ネットワークにアクセスするためのB4の論理ネクストホップルーターであるため、AFTRの配置は、アクセスネットワークのトラフィックフローと全体的なネットワーク設計に影響します。一般に、AFTRを配置するには2つの配置モデルがあります。 Model Oneは、AFTRをネットワークのエッジに配置して、小さな領域をカバーします。モデル2では、AFTRをネットワークのコアに配置して、広い領域をカバーしています。
When an operator considers where to deploy the AFTR, the operator must make trade-offs. The AFTR in Model One serves fewer B4s; thus, it requires a less powerful AFTR. Moreover, the traffic flows are more evenly distributed to the AFTRs. However, it requires deploying more AFTRs to cover the entire network. Often, the operation cost increases proportionally with the amount of network equipment.
オペレーターがAFTRの配置場所を検討する場合、オペレーターはトレードオフを行う必要があります。モデル1のAFTRは、提供するB4が少ないです。したがって、必要なAFTRはそれほど強力ではありません。さらに、トラフィックフローはAFTRにより均等に分散されます。ただし、ネットワーク全体をカバーするには、AFTRをさらに展開する必要があります。多くの場合、運用コストはネットワーク機器の数に比例して増加します。
The AFTR in Model Two covers a larger area; thus, it serves more B4s. The operator could deploy only a few AFTRs to support the entire user base. However, this model requires a more powerful AFTR to sustain the load at peak hours. Since the AFTR would support B4s from different regions, the AFTR would be deployed closer to the core network.
モデル2のAFTRはより広い領域をカバーしています。したがって、より多くのB4を提供します。オペレーターは、ユーザーベース全体をサポートするために、ほんの数個のAFTRを展開できました。ただし、このモデルでは、ピーク時に負荷を維持するために、より強力なAFTRが必要です。 AFTRはさまざまな地域のB4をサポートするため、AFTRはコアネットワークの近くに配置されます。
DS-Lite framework can be incrementally deployed. An operator may consider starting with Model Two. When the demand increases, the operator can push the AFTR closer to the edge, which would effectively become Model One.
DS-Liteフレームワークは段階的に展開できます。オペレーターは、モデル2から開始することを検討できます。需要が増えると、オペレーターはAFTRをエッジに近づけることができ、事実上モデル1になります。
By centralizing public IPv4 addresses in the AFTR, remote services can no longer rely on an IPv4 address and IPv4 routing information to derive a host's geographical information. For example, the IPv6 access network and the AFTR may be in two different cities. If the remote services rely on the IPv4 address to locate a host, they may have thought the host was in a different city. [RFC6269] Section 7 describes the problem in more detail. Applications could explicitly ask users to enter location information, such as postal code or telephone number, before offering geographical service. In contrast, applications could use HTTP-Enabled Location Delivery (HELD) [RFC5985] to get the location information from the Location Information Server and give this information to the remote peer. [RFC6280] describes an architecture to enable location-based services. However, to mitigate the impact, we recommend that operators deploy the AFTR as close to B4s as possible.
パブリックIPv4アドレスをAFTRに一元化することにより、リモートサービスはIPv4アドレスとIPv4ルーティング情報に依存してホストの地理情報を導出できなくなります。たとえば、IPv6アクセスネットワークとAFTRが2つの異なる都市にある場合があります。リモートサービスがホストを見つけるためにIPv4アドレスに依存している場合、ホストが別の都市にいると考えていた可能性があります。 [RFC6269]セクション7では、問題についてさらに詳しく説明しています。アプリケーションは、地理的なサービスを提供する前に、郵便番号や電話番号などの位置情報の入力をユーザーに明示的に要求することができます。対照的に、アプリケーションはHTTP対応のロケーション配信（HELD）[RFC5985]を使用してロケーション情報サーバーからロケーション情報を取得し、この情報をリモートピアに提供できます。 [RFC6280]は、ロケーションベースのサービスを可能にするアーキテクチャを説明しています。ただし、影響を緩和するために、オペレーターはAFTRをできるだけB4の近くに配置することをお勧めします。
This section describes the application of [RFC2983] to the DS-Lite deployment model. Operators must ensure that the QoS policy that is in place operates properly within the DS-Lite deployment. In this regard, operators commonly use DSCP [RFC2475] to classify and prioritize different types of traffic in their networks. DS-Lite tunnel can be seen as a particular case of uniform conceptual tunnel model, as described in Section 3.1 of [RFC2983]. The uniform model views an IP tunnel only as a necessary mechanism to forward traffic to its destination: the tunnel has no significant impact on traffic conditioning. In this model, any packet has exactly one DSCP field that is used for traffic conditioning at any point, and it is the field in the outermost IP header. In the DS-Lite model, this is the Traffic Class field in the IPv6 header. According to [RFC2983], implementations of this model copy the DSCP value to the outer IP header at encapsulation and copy the outer header's DSCP value to the inner IP header at decapsulation.
このセクションでは、DS-Lite展開モデルへの[RFC2983]の適用について説明します。オペレーターは、配置されているQoSポリシーがDS-Lite展開内で適切に動作することを確認する必要があります。この点で、事業者は通常、DSCP [RFC2475]を使用して、ネットワーク内のさまざまなタイプのトラフィックを分類し、優先順位を付けます。 [RFC2983]のセクション3.1で説明されているように、DS-Liteトンネルは、統一概念トンネルモデルの特定のケースと見なすことができます。統一モデルは、IPトンネルをトラフィックをその宛先に転送するために必要なメカニズムとしてのみ見なします。トンネルはトラフィック調整に大きな影響を与えません。このモデルでは、どのパケットにも、任意の時点でトラフィック調整に使用される1つのDSCPフィールドがあり、これは最も外側のIPヘッダーのフィールドです。 DS-Liteモデルでは、これはIPv6ヘッダーのトラフィッククラスフィールドです。 [RFC2983]によると、このモデルの実装は、カプセル化時にDSCP値を外部IPヘッダーにコピーし、カプセル化解除時に外部ヘッダーのDSCP値を内部IPヘッダーにコピーします。
Operators should use this model by provisioning the network such that the AFTR copies the DSCP value in the IPv4 header to the Traffic Class field in the IPv6 header, after the encapsulation for the downstream traffic. Similarly, the B4 copies the DSCP value in the IPv4 header to the Traffic Class field to the IPv6 header, after the encapsulation for the upstream traffic. Traffic identification and classification can be done by examining the outer IPv6 header in the IPv6 access network.
オペレーターは、ダウンストリームトラフィックのカプセル化後に、AFTRがIPv4ヘッダーのDSCP値をIPv6ヘッダーのトラフィッククラスフィールドにコピーするようにネットワークをプロビジョニングして、このモデルを使用する必要があります。同様に、B4は、アップストリームトラフィックのカプセル化後に、IPv4ヘッダーのDSCP値をIPv6ヘッダーのトラフィッククラスフィールドにコピーします。トラフィックの識別と分類は、IPv6アクセスネットワークの外部IPv6ヘッダーを調べることで実行できます。
Some applications behind the B4 require the B4 to accept incoming requests. If the remote application wants to communicate to the application behind the B4, the remote application must know both the NAT-ed IPv4 address used by the B4 and the IPv4 destination port. Some applications use Universal Plug and Play (UPnP) (e.g., popular gaming consoles) or Interactive Community Establishment (ICE) [RFC5245] to request incoming ports. Some applications rely on Application Level Gateway (ALG) or manual port configuration to reserve a port in the NAT. For the DS-Lite deployment scenario whereby the B4 does not own a full IPv4 address, the operator will manage port-forwarding in the serving AFTR. Operators may use Port Control Protocol (PCP) [PCP-BASE] as guidance to provide port forwarding service. Operators will deploy PCP client in the B4s. PCP permits the PCP server to be deployed in a stand-alone server. However, we recommend that operators consider deploying the PCP server in the AFTR. This will ease the overhead to design a global configuration for the PCP server for many AFTRs because each PCP server will be dedicated to the collocated AFTR.
B4の背後にある一部のアプリケーションでは、B4が着信要求を受け入れる必要があります。リモートアプリケーションがB4の背後にあるアプリケーションと通信する場合、リモートアプリケーションは、B4で使用されるNAT化されたIPv4アドレスとIPv4宛先ポートの両方を認識している必要があります。一部のアプリケーションは、ユニバーサルプラグアンドプレイ（UPnP）（たとえば、人気のあるゲームコンソール）またはInteractive Community Establishment（ICE）[RFC5245]を使用して、着信ポートを要求します。一部のアプリケーションは、NATでポートを予約するために、アプリケーションレベルゲートウェイ（ALG）または手動ポート構成に依存しています。 B4が完全なIPv4アドレスを所有していないDS-Lite展開シナリオの場合、オペレーターはサービングAFTRでポート転送を管理します。オペレーターは、ポート転送サービスを提供するためのガイダンスとして、ポート制御プロトコル（PCP）[PCP-BASE]を使用できます。オペレーターは、B4にPCPクライアントを展開します。 PCPを使用すると、PCPサーバーをスタンドアロンサーバーに展開できます。ただし、オペレーターはPCPサーバーをAFTRに配置することを検討することをお勧めします。これにより、各PCPサーバーが連結されたAFTR専用になるため、多くのAFTRのPCPサーバーのグローバル構成を設計するためのオーバーヘッドが緩和されます。
When sharing an IPv4 address, not all of the ports are available to a B4. Some restricted ports (i.e., 0-1023) are well known such as TCP port 25 and 80. Many users may want to be provisioned with the restricted ports. For fairness, we recommend that operators configure the AFTR and not allocate the restricted ports to regular DS-Lite B4s. This operation model ensures that DS-Lite B4s will have uniform configuration, which can simplify provisioning and operation. For users who want to use the restricted ports, operators can consider provisioning a full IPv4 address to those users' B4s. If an operator still wants to provision restricted ports to specific B4s, it may require implementing a static B4's configuration in the AFTR to match the B4's IPv6 address to the NAT rules. Alternatively, the B4 may dynamically allocate the ports, and the AFTR authenticates the session's request using PCP [PCP-BASE].
IPv4アドレスを共有する場合、すべてのポートがB4で使用できるわけではありません。 TCPポート25や80など、一部の制限付きポート（0〜1023など）はよく知られています。多くのユーザーは、制限付きポートをプロビジョニングする必要がある場合があります。公平を期すために、オペレーターはAFTRを構成し、制限されたポートを通常のDS-Lite B4に割り当てないことをお勧めします。この運用モデルにより、DS-Lite B4の構成が統一され、プロビジョニングと運用を簡素化できます。制限されたポートを使用するユーザーの場合、オペレーターはそれらのユーザーのB4に完全なIPv4アドレスをプロビジョニングすることを検討できます。オペレーターが制限付きポートを特定のB4にプロビジョニングしたい場合は、B4のIPv6アドレスをNATルールに一致させるために、AFTRに静的B4の構成を実装する必要がある場合があります。あるいは、B4はポートを動的に割り当てることができ、AFTRはPCP [PCP-BASE]を使用してセッションの要求を認証します。
[RFC6333], Section 11 describes security issues associated with the DS-Lite mechanism. To restrict the service offered by the AFTR only to registered B4s, an operator can implement the Outgoing Policy on the AFTR's tunnel interface to accept only the IPv6 prefixes defined in the policy. For static provisioning, the operator will need to know in advance the IPv6 prefixes provisioned to the B4s for the softwire in order to configure the policy. To simplify operation, operators should configure the AFTRs in the same region with the same IPv6 prefixes' Outgoing Policy. The AFTRs will accept both regular connections and failover connections from the B4s in the same service region.
[RFC6333]、セクション11では、DS-Liteメカニズムに関連するセキュリティの問題について説明しています。 AFTRによって提供されるサービスを登録済みのB4のみに制限するために、オペレーターはAFTRのトンネルインターフェースに送信ポリシーを実装して、ポリシーで定義されたIPv6プレフィックスのみを受け入れることができます。静的プロビジョニングの場合、オペレーターは、ポリシーを構成するために、ソフトワイヤーのB4にプロビジョニングされたIPv6プレフィックスを事前に知っておく必要があります。操作を簡単にするために、オペレーターは同じIPv6プレフィックスの送信ポリシーを使用して、同じリージョンにAFTRを構成する必要があります。 AFTRは、同じサービスリージョンのB4からの通常の接続とフェイルオーバー接続の両方を受け入れます。
In environments where the operator wants to deploy the AFTR in an IPv6-only network, the AFTR nodes may not have direct IPv4 connectivity. In this scenario, the operator extends the IPv6-only boundary to the border of the network and only the border routers have IPv4 connectivity. For both scalability and performance purposes, the AFTR is located in the IPv6-only network closer to B4s. In this scenario, the AFTR has only IPv6 connectivity and must be able to send and receive IPv4 packets. Enhancements to the DS-Lite AFTR are required to achieve this. [DS-LITE] describes such issues and enhancements to DS-Lite in IPv6-only deployments.
オペレーターがAFTRをIPv6のみのネットワークに展開したい環境では、AFTRノードはIPv4に直接接続できない場合があります。このシナリオでは、オペレーターはIPv6のみの境界をネットワークの境界まで拡張し、境界ルーターのみがIPv4接続を備えています。スケーラビリティとパフォーマンスの両方の目的で、AFTRはB4に近いIPv6のみのネットワークに配置されます。このシナリオでは、AFTRにはIPv6接続のみがあり、IPv4パケットを送受信できる必要があります。これを実現するには、DS-Lite AFTRの拡張が必要です。 [DS-LITE]では、IPv6のみの展開におけるDS-Liteのこのような問題と機能強化について説明しています。
In order to configure the IPv4-in-IPv6 tunnel, the B4 needs the IPv6 address of the AFTR. This IPv6 address can be configured using a variety of methods ranging from an out-of-band mechanism, manual configuration, and DHCPv6 option to RADIUS. If an operator uses DHCPv6 to provision the B4, the B4 must implement the DHCPv6 option defined in [RFC6334]. If an operator uses RADIUS to provision the B4, the B4 must implement [RFC6519].
IPv4-in-IPv6トンネルを構成するには、B4にAFTRのIPv6アドレスが必要です。このIPv6アドレスは、アウトオブバンドメカニズム、手動構成、DHCPv6オプションからRADIUSまでのさまざまな方法を使用して構成できます。オペレーターがDHCPv6を使用してB4をプロビジョニングする場合、B4は[RFC6334]で定義されているDHCPv6オプションを実装する必要があります。事業者がRADIUSを使用してB4をプロビジョニングする場合、B4は[RFC6519]を実装する必要があります。
[RFC6333] recommends that the B4 send DNS queries to an external recursive resolver over IPv6. The B4 should implement a proxy resolver that will proxy a DNS query from IPv4 transport to the DNS server in the IPv6 network. [RFC6333] does not describe the DNS proxy behavior. In deployment, the operator must ensure that the DNS proxy implementation must follow [RFC5625]. This is important especially for operators who have deployed, or will consider deploying, DNSSEC [RFC4035].
[RFC6333]は、B4がDNSクエリをIPv6経由で外部の再帰リゾルバに送信することを推奨しています。 B4は、IPv4トランスポートからのDNSクエリをIPv6ネットワークのDNSサーバーにプロキシするプロキシリゾルバを実装する必要があります。 [RFC6333]はDNSプロキシの動作を説明していません。展開では、オペレーターはDNSプロキシの実装が[RFC5625]に従う必要があることを確認する必要があります。これは、DNSSEC [RFC4035]を導入した、または導入を検討するオペレーターにとって特に重要です。
Some operators may want to give hosts behind the B4 an IPv4 address of an external DNS recursive resolver. The B4 will treat the DNS packets as normal IP packets and forward them over the softwire. Note that there is no effective way to provision an IPv4 DNS address to the B4 over IPv6; operators who use this DNS deployment model must be aware that how to provision an IPv4 DNS address over an IPv6 network is undefined, so it will introduce additional complexity in B4 provisioning. Moreover, this will increase the load to the AFTR by creating entries in the NAT table for DNS sessions. Operators may deploy a local DNS caching resolver in the AFTR to reduce the load in the NAT table. Nonetheless, this DNS model is not covered in [RFC6333] and is not recommended.
一部のオペレーターは、B4の背後にあるホストに、外部DNS再帰リゾルバーのIPv4アドレスを与えたい場合があります。 B4はDNSパケットを通常のIPパケットとして扱い、ソフトワイヤーを介して転送します。 IPv4 DNSアドレスをIPv6 over B4にプロビジョニングする効果的な方法はないことに注意してください。このDNS展開モデルを使用するオペレーターは、IPv6ネットワークを介してIPv4 DNSアドレスをプロビジョニングする方法が定義されていないため、B4プロビジョニングがさらに複雑になることに注意する必要があります。さらに、DNSセッションのNATテーブルにエントリを作成することにより、AFTRへの負荷が増加します。オペレーターは、AFTRにローカルDNSキャッシングリゾルバーを導入して、NATテーブルの負荷を軽減できます。それにもかかわらず、このDNSモデルは[RFC6333]でカバーされておらず、推奨されません。
B4 is connected to the IPv6 access network to offer IPv4 services. When users experience IPv4 connectivity issues, operators must be able to remotely access (e.g., TR-069) the B4 to verify its configuration and status. Operators should access B4s using native IPv6. Operators should not access B4 over the softwire.
B4はIPv6アクセスネットワークに接続され、IPv4サービスを提供します。ユーザーがIPv4接続の問題を経験した場合、オペレーターはB4にリモートでアクセス（例：TR-069）して、その構成とステータスを確認できる必要があります。オペレーターは、ネイティブIPv6を使用してB4にアクセスする必要があります。オペレーターは、ソフトワイヤーを介してB4にアクセスしないでください。
The DS-Lite framework provides IPv4 services over the IPv6 access network. Operators and users must be able to check the IPv4 connectivity from the B4 to its AFTR using ping and IPv4 traceroute. The AFTR should be configured with an IPv4 address to enable a PING test and a Traceroute test. Operators should assign the same IPv4 address (e.g., 192.0.0.2/32 [RFC6333]) to all AFTRs. IANA has allocated the 192.0.0.0/29 network prefix to provide IPv4 addresses for this purpose [RFC6333].
DS-Liteフレームワークは、IPv6アクセスネットワークを介してIPv4サービスを提供します。オペレーターとユーザーは、pingとIPv4 tracerouteを使用して、B4からそのAFTRへのIPv4接続を確認できる必要があります。 PINGテストとTracerouteテストを有効にするには、AFTRをIPv4アドレスで構成する必要があります。オペレーターは、すべてのAFTRに同じIPv4アドレス（192.0.0.2/32 [RFC6333]など）を割り当てる必要があります。 IANAは192.0.0.0/29ネットワークプレフィックスを割り当てて、この目的のためにIPv4アドレスを提供しています[RFC6333]。
This document does not present any new security issues. [RFC6333] discusses DS-Lite related security issues.
このドキュメントには、新しいセキュリティ問題はありません。 [RFC6333]では、DS-Liteに関連するセキュリティの問題について説明しています。
Thanks to Mr. Nejc Skoberne and Dr. Maoke Chen for their thorough review and helpful comments. We also want to thank Mr. Hu Jie for sharing his DS-Lite deployment experience with us. He gave us recommendations of what his company learned while testing DS-Lite in the production network.
Nejc Skoberne氏とMaoke Chen博士の徹底したレビューと有益なコメントに感謝します。また、DS-Liteの展開経験を共有してくれたHu Jie氏にも感謝します。彼は私たちに、本番ネットワークでDS-Liteをテストしている間に彼の会社が学んだことの推奨を与えました。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.
[RFC6333] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4枯渇後のデュアルスタックLiteブロードバンド展開」、RFC 6333、2011年8月。
[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、「Dynamic Host Configuration Protocol for IPv6（DHCPv6）Option for Dual-Stack Lite」、RFC 6334、2011年8月。
[RFC6519] Maglione, R. and A. Durand, "RADIUS Extensions for Dual-Stack Lite", RFC 6519, February 2012.
[RFC6519] Maglione、R。およびA. Durand、「デュアルスタックライト用のRADIUS拡張機能」、RFC 6519、2012年2月。
[DS-LITE] Boucadair, M., Jacquenet, C., Grimault, J., Kassi-Lahlou, M., Levis, P., Cheng, D., and Y. Lee, "Deploying Dual-Stack Lite in IPv6 Network", Work in Progress, April 2011.
[DS-LITE] Boucadair、M.、Jacquenet、C.、Grimault、J.、Kassi-Lahlou、M.、Levis、P.、Cheng、D.、and Y. Lee、 "Deploying Dual-Stack Lite in IPv6ネットワーク」、作業中、2011年4月。
[NAT-REVEAL] Boucadair, M., Touch, J., Levis, P., and R. Penno, "Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments", Work in Progress, March 2013.
[NAT-REVEAL] Boucadair、M.、Touch、J.、Levis、P。、およびR. Penno、「Analysis of Solution Candidates to Be a Host Identifier（HOST_ID）in Hosted Address Deployments」、Work in Progress、2013年3月。
[NAT-STANDBY] Xu, X., Boucadair, M., Lee, Y., and G. Chen, "Redundancy Requirements and Framework for Stateful Network Address Translators (NAT)", Work in Progress, October 2010.
[NAT-STANDBY] Xu、X.、Boucadair、M.、Lee、Y。、およびG. Chen、「冗長性の要件とステートフルネットワークアドレストランスレータ（NAT）のフレームワーク」、作業中、2010年10月。
[PCP-BASE] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", Work in Progress, November 2012.
[PCP-BASE] Wing、D.、Cheshire、S.、Boucadair、M.、Penno、R。、およびP. Selkirk、「Port Control Protocol（PCP）」、Work in Progress、2012年11月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473] Conta、A。およびS. Deering、「Generic Packet Tunneling in IPv6 Specification」、RFC 2473、1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「An Architecture for Differentiated Services」、RFC 2475、1998年12月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983] Black、D。、「Differentiated Services and Tunnels」、RFC 2983、2000年10月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022] Srisuresh、P。およびK. Egevang、「Traditional IP Network Address Translator（Traditional NAT）」、RFC 3022、2001年1月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Extensionsのプロトコル変更」、RFC 4035、2005年3月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245] Rosenberg、J。、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal for Offer / Answer Protocols」、RFC 5245、2010年4月。
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, August 2009.
[RFC5625] Bellis、R。、「DNSプロキシ実装ガイドライン」、BCP 152、RFC 5625、2009年8月。
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
[RFC5985] Barnes、M。、「HTTP-Enabled Location Delivery（HELD）」、RFC 5985、2010年9月。
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
[RFC6269]フォード、M。、ブーカデア、M。、デュランド、A。、リーバイス、P。、およびP.ロバーツ、「IPアドレスの共有に関する問題」、RFC 6269、2011年6月。
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011.
[RFC6280] Barnes、R.、Lepinski、M.、Cooper、A.、Morris、J.、Tschofenig、H。、およびH. Schulzrinne、「An Internet Location in Location and Location Privacy in Internet Applications」、BCP 160、RFC 6280、2011年7月。
[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月。
Authors' Addresses
著者のアドレス
Yiu L. Lee Comcast One Comcast Center Philadelphia, PA 19103 U.S.A.
Yiu L. Lee Comcast One Comcast Center Philadelphia、PA 19103 U.S.A.
EMail: yiu_lee@cable.comcast.com
URI: http://www.comcast.com
Roberta Maglione Cisco Systems 181 Bay Street Toronto, ON M5J 2T3 Canada
Roberta Sweater Cisco Systems 181 Bay Street Toronto、ON M5J 2T3 Canada
EMail: robmgl@cisco.com
Carl Williams MCSR Labs U.S.A.
かｒｌ うぃっぃあｍｓ ＭＣＳＲ ぁｂｓ う。Ｓ。あ。
EMail: carlw@mcsr-labs.org
Christian Jacquenet France Telecom Rennes France
Christian Jacquenet France Telecom Rennes France
EMail: christian.jacquenet@orange.com
Mohamed Boucadair France Telecom Rennes France
Mohamed Boucadair France Telecom Rennes France
EMail: mohamed.boucadair@orange.com