Internet Engineering Task Force (IETF) R. Bush, Ed.
Request for Comments: 6346 Internet Initiative Japan
Category: Experimental August 2011
ISSN: 2070-1721
The Address plus Port (A+P) Approach to the IPv4 Address Shortage
住所プラスポート（A + P）IPv4アドレスの不足へのアプローチ
Abstract
抽象
We are facing the exhaustion of the IANA IPv4 free IP address pool. Unfortunately, IPv6 is not yet deployed widely enough to fully replace IPv4, and it is unrealistic to expect that this is going to change before the depletion of IPv4 addresses. Letting hosts seamlessly communicate in an IPv4 world without assigning a unique globally routable IPv4 address to each of them is a challenging problem.
私たちは、IANAのIPv4無料のIPアドレスプールの枯渇に直面しています。残念ながら、IPv6はまだ完全にはIPv4を置き換えるために、広く十分に展開されていない、そしてIPv4アドレスの枯渇前に変更しようとしていることを期待するのは非現実的です。ホストがシームレスにそれらのそれぞれにユニークなグローバルにルーティング可能なIPv4アドレスを割り当てずにIPv4の世界でのコミュニケーションまかせ困難な問題です。
This document proposes an IPv4 address sharing scheme, treating some of the port number bits as part of an extended IPv4 address (Address plus Port, or A+P). Instead of assigning a single IPv4 address to a single customer device, we propose to extend the address field by using bits from the port number range in the TCP/UDP header as additional endpoint identifiers, thus leaving a reduced range of ports available to applications. This means assigning the same IPv4 address to multiple clients (e.g., Customer Premises Equipment (CPE), mobile phones), each with its assigned port range. In the face of IPv4 address exhaustion, the need for addresses is stronger than the need to be able to address thousands of applications on a single host. If address translation is needed, the end-user should be in control of the translation process -- not some smart boxes in the core.
この文書では、拡張されたIPv4アドレス（アドレス+ポート、又はA + P）の一部としてポート番号ビットのいくつかを処理する、IPv4のアドレスを共有する方式を提案します。代わりに、単一の顧客装置への単一のIPv4アドレスを割り当てる、我々は、このようなアプリケーションに使用可能なポートの減少範囲を残し、追加のエンドポイント識別子としてTCP / UDPヘッダのポート番号の範囲からのビットを使用してアドレスフィールドを拡張することを提案します。これは、複数のクライアントに同じIPv4アドレスを割り当てる手段（例えば、顧客宅内機器（CPE）、携帯電話）、その割り当てられたポート範囲がそれぞれ。 IPアドレス枯渇問題に直面して、アドレスの必要性は、単一のホスト上のアプリケーションの数千人に対処することができるようにする必要性よりも強いです。アドレス変換が必要な場合は、エンドユーザーは、翻訳プロセスの制御にする必要があります - コアでなく、いくつかのスマートな箱。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc6346.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6346で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Problems with Carrier Grade NATs . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Design Constraints and Functions . . . . . . . . . . . . . . . 6
3.1. Design Constraints . . . . . . . . . . . . . . . . . . . . 6
3.2. A+P Functions . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Overview of the A+P Solution . . . . . . . . . . . . . . . 8
3.3.1. Signaling . . . . . . . . . . . . . . . . . . . . . . 9
3.3.2. Address Realm . . . . . . . . . . . . . . . . . . . . 11
3.3.3. Reasons for Allowing Multiple A+P Gateways . . . . . . 15
3.3.4. Overall A+P Architecture . . . . . . . . . . . . . . . 16
3.4. A+P Experiments . . . . . . . . . . . . . . . . . . . . . 17
4. Stateless A+P Mapping Function . . . . . . . . . . . . . . . . 18
4.1. Stateless A+P Mapping (SMAP) Gateway Function
Description . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. Implementation Mode . . . . . . . . . . . . . . . . . . . 20
4.3. Towards IPv6-Only Networks . . . . . . . . . . . . . . . . 22
4.4. PRR: On Stateless and Binding Table Modes . . . . . . . . 22
4.5. General Recommendations on SMAP . . . . . . . . . . . . . 23
5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 24
5.1. A+P Deployment Models . . . . . . . . . . . . . . . . . . 24
5.1.1. A+P for Broadband Providers . . . . . . . . . . . . . 24
5.1.2. A+P for Mobile Providers . . . . . . . . . . . . . . . 24
5.1.3. A+P from the Provider Network Perspective . . . . . . 25
5.2. Dynamic Allocation of Port Ranges . . . . . . . . . . . . 27
5.3. Example of A+P-Forwarded Packets . . . . . . . . . . . . . 28
5.3.1. Forwarding of Standard Packets . . . . . . . . . . . . 32
5.3.2. Handling ICMP . . . . . . . . . . . . . . . . . . . . 32
5.3.3. Fragmentation . . . . . . . . . . . . . . . . . . . . 33
5.3.4. Limitations of the A+P Approach . . . . . . . . . . . 33
5.3.5. Port Allocation Strategy Agnostic . . . . . . . . . . 34
6. Security Considerations . . . . . . . . . . . . . . . . . . . 34
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.1. Normative References . . . . . . . . . . . . . . . . . . . 35
8.2. Informative References . . . . . . . . . . . . . . . . . . 35
9. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 37
This document describes a technique to deal with the imminent IPv4 address space exhaustion. Many large Internet Service Providers (ISPs) face the problem that their networks' customer edges are so large that it will soon not be possible to provide each customer with a unique public IPv4 address. Therefore, although undesirable, address sharing, in the same molds as NAT, is inevitable.
この文書では、差し迫ったIPv4アドレス空間の枯渇に対処するための技術が記載されています。多くの大手インターネットサービスプロバイダ（ISP）は、自社のネットワークの顧客のエッジが、すぐに独自のパブリックIPv4アドレスを持つ各顧客に提供することはできないように大きい問題に直面しています。したがって、望ましくないものの、アドレスの共有は、NATと同じ金型では、避けられません。
To allow end-to-end connectivity between IPv4-speaking applications, we propose to extend the semantics of the IPv4 address with bits from the UDP/TCP header. Assuming we could limit the applications' port addressing to any number of bits lower than 16, we can increase the effective size of an IPv4 address by remaining additional bits of up to 16. In this scenario, 1 to 65536 customers could be multiplexed on the same IPv4 address, while allowing them a fixed or dynamic range of 1 to 65536 ports. Customers could, for example, receive an initial fixed port range, defined by the operator, and dynamically request additional blocks, depending on their contract. We call this "extended addressing" or "A+P" (Address plus Port) addressing. The main advantage of A+P is that it preserves the Internet "end-to-end" paradigm by not requiring translation (at least for some ports) of an IP address.
IPv4の話すアプリケーション間のエンドツーエンドの接続を可能にするために、我々は、UDP / TCPヘッダからのビットのIPv4アドレスの意味論を拡張することを提案します。我々は16よりも低い任意のビット数にアドレッシングアプリケーションのポートを制限する可能性があると仮定すると、我々は、1 65536顧客が上で多重化することができ、このシナリオでは、最大16の追加ビットを残存することにより、IPv4アドレスの有効サイズを増加させることができます同一のIPv4アドレス、それらを1 65536にポートの固定またはダイナミックレンジを可能にします。顧客は、例えば、オペレータによって定義された初期固定ポート範囲を、受信し、動的に契約に応じて、追加のブロックを要求することができます。私たちは、この「拡張アドレッシング」または「A + P」（住所プラスポート）アドレス指定を呼び出します。 A + Pの主な利点は、それがIPアドレスの（少なくともいくつかのポートの）翻訳を必要としないことにより、インターネット「エンドツーエンド」パラダイムを保持することです。
Various forms of NATs will be installed at different levels and places in the IPv4 Internet to achieve address compression. This document argues for mechanisms where this happens as close to the edge of the network as possible, thereby minimizing damage to the End-to-End Principle and allowing end-customers to retain control over the address and port translation. Therefore, it is essential to create mechanisms to "bypass" NATs in the core, when applicable, and keep the control at the end-user.
NATの様々な形式のアドレス圧縮を達成するためにIPv4インターネットでのさまざまなレベルと場所に設置されます。この文書は、それによってエンド・ツー・エンド原理への損傷を最小限にし、エンド顧客がアドレス及びポート変換の制御を保持することができ、これはできるだけネットワークのエッジの近く起こるメカニズムを主張します。したがって、コア、適用可能な場合に「バイパス」のNATのメカニズムを作成し、エンドユーザの制御を維持することが不可欠です。
With Carrier Grade NATs (CGNs) in the core of the network, the user is trapped behind unchangeable application policies, and the deployment of new applications is hindered by the need to implement the corresponding Application Level Gateways (ALGs) on the CGNs. This is the opposite of the "end-to-end" model of the Internet.
ネットワークのコア内のキャリアグレードNATの（CGNを）を使用すると、ユーザーは不変アプリケーションポリシーの後ろにトラップされ、そして新しいアプリケーションの展開は、CGNを上の対応するアプリケーションレベルゲートウェイ（のALG）を実装する必要性によって妨げられます。これは、インターネットの「エンド・ツー・エンド」モデルの反対です。
With the smarts at the edges, one can easily deploy new applications between consenting endpoints by merely tweaking the NATs at the corresponding CPE, or even upgrading them to a new version that supports a specific ALG.
縁で知性と、人は簡単だけで対応するCPEでのNATを微調整、あるいは特定のALGをサポートする新しいバージョンにそれらをアップグレードすることで同意したエンドポイント間の新しいアプリケーションを展開することができます。
Today's NATs are typically mitigated by offering the customers limited control over them, e.g., port forwarding, Universal Plug and Play or the NAT Port Mapping Protocol (UPnP/NAT-PMP). However, this is not expected to work with CGNs. CGN proposals -- other than DS-Lite [RFC6333] with A+P or the Port Control Protocol (PCP) [PCP-BASE] -- admit that it is not expected that applications that require specific port assignment or port mapping from the NAT box will keep working.
今日のNATのは、一般的に、顧客がそれらの上に制限された制御を提供することによって軽減例えば、ポートフォワーディング、ユニバーサルプラグアンドプレイやNATポートマッピングプロトコル（UPnPの/ NAT-PMP）されています。しかし、これはCGNをで動作するように期待されていません。 CGNの提案 - + Pまたはポート制御プロトコル（PCP）[PCP-BASE]とDS-Liteの[RFC6333]以外は - それが期待されていないことを認めているNATから特定のポートの割り当てやポートマッピングを必要とするアプリケーションボックスには、作業を続けます。
Another issue with CGNs is the trade-off between session state and network placement. The farther from the edge the CGN is placed, the more session state needs to be kept due to larger subscriber aggregation and the more disruption that occurs in the case of a failure. In order to reduce the state, CGNs would end up somewhere closer to the edge. Thus, the CGN trades scalability for the amount of state that needs to be kept, which makes optimally placing a CGN a hard engineering problem.
CGNを持つもう一つの問題は、セッション状態とネットワークの配置とのトレードオフです。遠いCGNが配置される端部から、より多くのセッション状態が原因大きな加入者凝集および障害が発生した場合に発生するより破壊に維持する必要があります。状態を軽減するために、CGNをどこかに近いエッジに終わるでしょう。このように、CGNは最適CGNにハードエンジニアリングの問題を置くことになり保たれる必要がある状態の量、スケーラビリティのための売買を行っています。
In some deployment scenarios, a CGN can be seen as the single point of failure, and therefore the availability of delivered services can be impacted by a single CGN device. Means to ensure state synchronization and failover would be required to allow for service continuity whenever a failure occurs.
いくつかの展開シナリオでは、CGNは、単一障害点として見ることができるので、提供されるサービスの利用可能性は、単一CGNデバイスによって影響を受けることができます。障害が発生するたびに状態の同期化およびフェイルオーバーがサービスの継続を可能にするために必要とされるであろうことを確認することを意味します。
Intra-domain paths may not be optimal for communications between two nodes connected to the same domain deploying CGNs; they may lead to path stretches.
ドメイン内経路がCGNをを展開同じドメインに接続された2つのノード間の通信のために最適ではないかもしれません。彼らはパスのストレッチにつながる可能性があります。
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]に記載されているように解釈されます。
This document makes use of the following terms:
このドキュメントでは、次の用語を使用します：
Public Realm: This realm contains only public routable IPv4 addresses. Packets in this realm are forwarded based on the destination IPv4 address.
公共レルム：このレルムは唯一の公共ルーティング可能なIPv4アドレスが含まれています。この分野でのパケットは、宛先IPv4アドレスに基づいて転送されます。
A+P Realm: This realm contains both public routable IPv4 and A+P addresses.
+ Pレルム：このレルムは、公共ルーティング可能なIPv4およびA + Pアドレスの両方が含まれています。
A+P Packet: A regular IPv4 packet is forwarded based on the destination IPv4 address and the TCP/UDP port numbers.
+ Pパケット：通常のIPv4パケットが宛先IPv4アドレスおよびTCP / UDPポート番号に基づいて転送されます。
Private Realm: This realm contains IPv4 addresses that are not globally routed. They may be taken from the [RFC1918] range. However, this document does not make such an assumption. We regard as private address space any IPv4 address that needs to be translated in order to gain global connectivity, irrespective of whether or not it falls in [RFC1918] space.
プライベートレルム：このレルムは、グローバルにルーティングされていないIPv4アドレスが含まれています。彼らは[RFC1918]の範囲から得ることができます。しかし、この文書では、このような仮定を行うことはありません。私たちは、プライベートアドレス空間としてかかわらず、それは[RFC1918]空間であるか否かの、グローバルな接続を得るために翻訳する必要が任意のIPv4アドレスを考えています。
Port-Range Router (PRR): A device that forwards A+P packets.
ポートレンジルータ（PRR）：+ Pパケットを転送する装置。
Customer Premises Equipment (CPE): cable or DSL modem.
顧客宅内機器（CPE）：ケーブルまたはDSLモデム。
Provider Edge (PE) Router: Customer aggregation router.
プロバイダーエッジ（PE）ルータ：カスタマー集約ルータ。
Provider Border Router (BR): Provider's edge to other providers.
プロバイダーボーダールータ（BR）：他のプロバイダへのプロバイダーのエッジ。
Network Core Routers (Core): Provider routers that are not at the edges.
ネットワークコアルータ（コア）：エッジではないプロバイダールータ。
The problem of address space shortage is first felt by providers with a very large end-user customer base, such as broadband providers and mobile service providers. Though the cases and requirements are slightly different, they share many commonalities. In the following text, we develop a set of overall design constraints for solutions addressing the IPv4 address shortage problem.
アドレス空間の不足の問題は、まず、このようなブロードバンドプロバイダやモバイルサービスプロバイダーのような非常に大規模なエンドユーザーの顧客基盤を持つプロバイダによって感じられます。ケースと要件が若干異なりますが、彼らは多くの共通点を共有しています。以下のテキストでは、IPv4アドレスの不足の問題に対処するソリューションの全体的な設計制約のセットを開発します。
We regard several constraints as important for our design:
私たちは、私たちのデザインのために重要であるといくつかの制約を考えます：
1) End-to-end is under customer control: Customers shall have the ability to deploy new application protocols at will. IPv4 address shortage should not be a license to break the Internet's end-to-end paradigm.
1）エンド・ツー・エンドの顧客の制御下にある：お客様が自由に新しいアプリケーションプロトコルを展開する能力を持たなければなりません。 IPv4アドレスの不足は、インターネットのエンド・ツー・エンドのパラダイムを破るためのライセンスではありません。
2) Backward compatibility: Approaches should be transparent to unaware users. Devices or existing applications should be able to work without modification. Emergence of new applications should not be limited.
2）下位互換性：アプローチは気づいていないユーザーに対して透明であるべきです。デバイスまたは既存のアプリケーションは変更なしで動作することができるはずです。新しいアプリケーションの出現は限定されるべきではありません。
3) Highly scalable and minimal state core: Minimal state should be kept inside the ISP's network. If the operator is rolling out A+P incrementally, it is understood there may be state in the core in the non-A+P part of such a roll-out.
3）高度にスケーラブルかつ最小限の状態のコア：最小限の状態は、ISPのネットワーク内に保持されなければなりません。オペレータが増分+ Pをロールアウトされている場合、このようなロールアウトの非A + P部におけるコア状態が存在してもよいと理解されます。
4) Efficiency versus complexity: Operators should have the flexibility to trade off port multiplexing efficiency and scalability and end-to-end transparency.
4）複雑対効率：オペレータは、ポート多重化効率およびスケーラビリティとエンド・ツー・エンドの透明性をトレードオフするための柔軟性を有するべきです。
5) "Double-NAT" should be avoided: Multiple gateway devices might be present in a path, and once one has done some translation, those packets should not be retranslated.
複数のゲートウェイデバイスがパスに存在する可能性がある、もう1つは、いくつかの翻訳を行っていると、それらのパケットを再変換するべきではありません。5）「ダブルNAT」は避けるべきです。
6) Legal traceability: ISPs must be able to provide the identity of a customer from the knowledge of the IPv4 public address and the port. This should have as low an impact as is reasonable on storage by the ISP. We assume that NATs on customer premises do not pose much of a problem, while provider NATs need to keep additional logs.
6）法的トレーサビリティ：ISPは、IPv4のパブリックアドレスとポートの知識から、顧客の身元を提供できなければなりません。これは、ISPによってストレージ上妥当であると低い影響力を持っている必要があります。我々は、プロバイダのNATのは、追加のログを保持する必要がある一方で、顧客の敷地内にNATのは、問題の多くを提起しないことを前提としています。
7) IPv6 deployment should be encouraged. NAT444 strongly biases the users to the deployment of RFC 1918 addressing.
7）IPv6の展開が奨励されるべきです。 NAT444は強く対処するRFC 1918の展開にユーザーにバイアスをかけます。
Constraint 5 is important: while many techniques have been deployed to allow applications to work through a NAT, traversing cascaded NATs is crucial if NATs are being deployed in the core of a provider network.
制約5は重要である：多くの技術は、アプリケーションがNATを介して動作できるようにするために展開されてきたがNATのは、プロバイダーネットワークのコアに展開されている場合は、カスケード接続のNATを通過することが重要です。
The A+P architecture can be split into three distinct functions: encaps/decaps, NAT, and signaling.
ENCAPS / decaps、NAT、およびシグナル：A + P・アーキテクチャは、3つの異なる機能に分割することができます。
Encaps/decaps function: is used to forward port-restricted A+P packets over intermediate legacy devices. The encapsulation function takes an IPv4 packet, looks up the IP and TCP/UDP headers, and puts the packet into the appropriate tunnel. The state needed to perform this action is comparable to a forwarding table. The decapsulation device SHOULD check if the source address and port of packets coming out of the tunnel are legitimate (e.g., see [BCP38]). Based on the result of such a check, the packet MAY be forwarded untranslated, MAY be discarded, or MAY be NATed. In this document, we refer to a device that provides this encaps/decaps functionality as a Port-Range Router (PRR).
ENCAPS / decaps関数は中間レガシーデバイス上ポート制限A + Pパケットを転送するために使用されます。カプセル化機能は、IPv4パケットを受け取り、IPおよびTCP / UDPヘッダを検索し、適切なトンネルにパケットを置きます。このアクションを実行するために必要な状態が転送テーブルに匹敵します。送信元アドレス及びトンネルから出てくるパケットのポートが正当である場合にデカプセル化装置（例えば、[BCP38]参照）を確認する必要があります。そのようなチェックの結果に基づいて、パケットは、非翻訳転送することができ、廃棄されてもよいし、NAT処理されるかもしれません。この文書では、我々はこれがENCAPS提供するデバイスを参照してください/ポートレンジルータ（PRR）としての機能をdecaps。
Network Address Translation (NAT) function: is used to connect legacy end-hosts. Unless upgraded, end-hosts or end-systems are not aware of A+P restrictions and therefore assume a full IP address. The NAT function performs any address or port translation, including Application Level Gateways (ALGs) whenever required. The state that has to be kept to implement this function is the mapping for which external addresses and ports have been mapped to which internal addresses and ports, just as in CPEs embedding NAT today. A subtle, but very important, difference should be noted here: the customer has control over the NATing process or might choose to "bypass" the NAT. If this is done, we call the NAT a Large-Scale NAT (LSN). However, if the NAT does NOT allow the customer to control the translation process, we call it a CGN.
ネットワークアドレス変換（NAT）機能は：レガシーエンドホストを接続するために使用されます。アップグレードしない限り、エンドホストまたはエンドシステムは、A + Pの制限を認識していないため、完全なIPアドレスを前提としています。 NAT機能が必要な時はいつでもアプリケーションレベルゲートウェイ（のALG）を含む任意のアドレスやポート変換を実行します。この機能を実装するために保つ必要がある状態では、外部アドレスとポートがちょうど今日NATを埋め込むのCPEのように、その内部アドレスとポートにマッピングされているためにマッピングです。 、微妙な、しかし非常に重要な違いは、ここで注意する必要があります。お客様は、NAT変換プロセスを制御しているか、「バイパス」NATに選択することがあります。これが行われた場合、我々は大規模NAT（LSN）NATを呼び出します。 NATは、顧客が翻訳プロセスをコントロールすることはできませんしかし、もし、我々はCGNそれを呼び出します。
Signaling function: is used to allow A+P-aware devices to get to know which ports are assigned to be passed through untranslated and what will happen to packets outside the assigned port range (e.g., could be NATed or discarded). Signaling may also be used to learn the encapsulation method and any endpoint information needed. In addition, the signaling function may be used to dynamically assign the requested port range.
シグナル伝達関数は：A + P-認識装置はポートが非翻訳を通過するように割り当てられ、割り当てられたポート範囲外のパケットに何が起こるか（例えば、NAT処理または廃棄することができる）を知ることができるように使用されます。シグナリングはまた、カプセル化方式と必要な任意のエンドポイント情報を学ぶために使用することができます。また、シグナリング機能は、動的に要求されたポート範囲を割り当てるために使用されてもよいです。
As mentioned above, the core architectural elements of the A+P solution are three separated and independent functions: the NAT function, the encaps/decaps function, and the signaling function. The NAT function is similar to a NAT as we know it today: it performs a translation between two different address realms. When the external realm is public IPv4 address space, we assume that the translation is many-to-one, in order to multiplex many customers on a single public IPv4 address. The only difference with a traditional NAT (Figure 1) is that the translator might only be able to use a restricted range of ports when mapping multiple internal addresses onto an external one, e.g., the external address realm might be port-restricted.
NAT機能、ENCAPS /機能をdecaps、シグナリング機能：上述したように、A + P溶液のコアアーキテクチャ要素は、三の分離し、独立した機能です。今日私たちが知っているようにNAT機能は、NATのようになります。これは、2つの異なるアドレスレルム間の変換を行います。外部レルムは、パブリックIPv4アドレス空間であるとき、私たちは翻訳が単一のパブリックIPv4アドレスに多くの顧客を多重化するためには、多対一であることを前提としています。伝統的なNAT（図1）との唯一の違いは、翻訳者が唯一の外部一方に複数の内部アドレスをマッピングする際に、ポートの制限された範囲を使用することができるかもしれないということである、例えば、外部のアドレス領域は、ポート制限されるかもしれません。
"internal-side" "external-side"
+-----+
internal | N | external
address <---| A |---> address
realm | T | realm
+-----+
Figure 1: Traditional NAT
図1：従来のNAT
The encaps/decaps function, on the other hand, is the ability to establish a tunnel with another endpoint providing the same function. This implies some form of signaling to establish a tunnel. Such signaling can be viewed as integrated with DHCP or as a separate service. Section 3.3.1 discusses the constraints of this signaling function. The tunnel can be an IPv6 or IPv4 encapsulation, a layer-2 tunnel, or some other form of softwire. Note that the presence of a tunnel allows unmodified, naive, or even legacy devices between the two endpoints.
ENCAPS / decaps機能、一方、同じ機能を提供する別のエンドポイントとのトンネルを確立する能力です。これは、トンネルを確立するためのシグナリングのいくつかのフォームを意味しています。 DHCPまたは別のサービスとして統合このようなシグナリングは見ることができます。 3.3.1は、このシグナル伝達機能の制約について説明します。トンネルは、IPv6またはIPv4カプセル化、レイヤ2トンネル、又はsoftwireのいくつかの他の形態とすることができます。トンネルの存在は、2つのエンドポイント間、非修飾ナイーブ、あるいはレガシーデバイスを可能にすることに留意されたいです。
Two or more devices that provide the encaps/decaps function are linked by tunnels to form an A+P subsystem. The function of each gateway is to encapsulate and decapsulate, respectively. Figure 2
ENCAPS / decaps機能を提供する2つの以上のデバイスが、A + P・サブシステムを形成するためのトンネルによって連結されています。各ゲートウェイの機能は、それぞれ、カプセル化及びデカプセル化することです。図2
depicts the simplest possible A+P subsystem, that is, two devices providing the encaps/decaps function.
つまり、ENCAPSを提供する二つのデバイス/機能をdecaps、最も簡単な可能A + P・サブシステムを示します。
+------------------------------------+
Private | +----------+ tunnel +----------+ | Public
address --|-| gateway |==========| gateway |-|-- address
realm | +----------+ +----------+ | realm
+------------------------------------+
A+P subsystem
Figure 2: A Simple A+P Subsystem
図2：簡単なA + Pサブシステム
Within an A+P subsystem, the public address realm is extended by using bits from the port number when forwarding packets. Each device is assigned one address from the external realm and a range of port numbers. Hence, devices that are part of an A+P subsystem can communicate with the public realm without the need for address translation (i.e., preserving end-to-end packet integrity): an A+P packet originated from within the A+P subsystem can be simply forwarded over tunnels up to the endpoint, where it gets decapsulated and routed in the external realm.
A + P・サブシステム内で、パブリックアドレス領域は、パケットを転送する際、ポート番号からのビットを使用することによって拡張されます。各装置は、外部レルムとポート番号の範囲から一つのアドレスが割り当てられています。したがって、アドレス変換の必要性（つまりは、エンドツーエンドのパケットの整合性を維持する）ことなく、公共分野と通信できるA + P・サブシステムの一部であるデバイス：A + PパケットがA + Pサブシステム内から発信単にそれがカプセル化解除し、外部領域にルーティングされたエンドポイント、最大のトンネルを介して転送することができます。
The following information needs to be available on all the gateways in the A+P subsystem. It is expected that there will be a signaling protocols such as [PR-ADDR-ASSIGN], [SHARED-ADDR-OPT], [PORT-RANGE-OPT], or [PCP-BASE].
以下の情報は、A + P・サブシステム内のすべてのゲートウェイ上で利用できるようにする必要があります。このような[PR-ADDR-ASSIGN]、[共有ADDR-OPT]、[PORT-RANGE-OPT]、または[PCP-BASE]などのシグナリングプロトコルが存在するであろうことが予想されます。
The information that needs to be shared is the following:
共有する必要のある情報は以下の通りであります：
o a set of public IPv4 addresses,
OパブリックIPv4アドレスのセット、
o for each IPv4 address, a starting point for the allocated port range,
O各IPv4アドレスのために、割り当てられたポート範囲の開始点、
o the number of delegated ports,
委任されたポートの数、O、
o the optional key that enables partial or full preservation of entropy in port randomization -- see [PR-ADDR-ASSIGN],
[PR-ADDR-ASSIGN]を参照して、 - ポートランダムにエントロピーの部分的または完全な保存を可能にする任意のキーO
o the lifetime for each IPv4 address and set of allocated ports,
O各IPv4アドレスの有効期間と割り当てポートのセット、
o the tunneling technology to be used (e.g., "IPv6-encapsulation"), o addresses of the tunnel endpoints (e.g., IPv6 address of tunnel endpoints),
Oトンネリング技術が使用される（例えば、「IPv6のカプセル化」）、トンネルエンドポイントのアドレスO（例えば、トンネルエンドポイントのIPv6アドレス）、
o whether or not NAT function is provided by the gateway,
NAT機能は、ゲートウェイによって提供されるか否か、O、
o a device identification number and some authentication mechanisms, and
Oデバイスの識別番号と、いくつかの認証メカニズム、及び
o a version number and some reserved bits for future use.
Oバージョン番号と、将来の使用のためのいくつかの予約ビット。
Note that the functions of encapsulation and decapsulation have been separated from the NAT function. However, to accommodate legacy hosts, NATing is likely to be provided at some point in the path; therefore, the availability or absence of NATing MUST be communicated in signaling, as A+P is agnostic about NAT placement.
カプセル化とカプセル化解除の機能は、NAT機能から分離されていることに注意してください。しかしながら、従来のホストを収容するために、NAT変換は、経路内のどこかの時点で提供される可能性があります。 A + PがNAT配置約とらわれないように、したがって、NAT変換の利用可能性または不在は、シグナル伝達に伝達されなければなりません。
The port ranges can be allocated in two different ways:
ポート範囲は、2つの異なる方法で割り当てることができます。
o If applications or end-hosts behind the CPE are not UPnPv2/ NAT-PMP-aware, then the CPE SHOULD request ports via mechanisms, e.g., as described in [PR-ADDR-ASSIGN] and [PORT-RANGE-OPT]. Note that different port ranges can have different lifetimes, and the CPE is not entitled to use them after they expire -- unless it refreshes those ranges. It is up to the ISP to put mechanisms in place (to prevent denial-of-service attacks) that determine what percentage of already allocated port ranges should be exhausted before a CPE may request additional ranges, how often the CPE can request additional ranges, and so on.
CPEの背後にあるアプリケーションまたはエンドホストはUPnPv2 / NAT-PMP-認識していない場合は[PR-ADDR-ASSIGN]と[PORT-RANGE-OPT]に記載されているようにO、次いで、CPEは、例えば機構を介してポートを要求すべきです。それはそれらの範囲を更新しない限り、 - 異なるポート範囲が異なる寿命を持つことができ、CPEは、有効期限が切れる後にそれらを使用する権利がないことに注意してください。それは、場所にメカニズムを置くためにISPまでです（サービス拒否攻撃を防ぐために）CPEは、追加の範囲を要求することができる前に、どのくらいの頻度CPEは、追加の範囲を要求することができ尽くされるべきですでに割り当てられているポート範囲の何パーセントかを決定こと等々。
o If applications behind the CPE are UPnPv2/NAT-PMP-aware, additional ports MAY be requested through that mechanism. In this case, the CPE should forward those requests to the LSN, and the LSN should reply reporting if the requested ports are available or not (and if they are not available, some alternatives should be offered). Here again, to prevent potential denial-of-service attacks, mechanisms should be in place to prevent UPnPv2/NAT-PMP packet storms and fast port allocation. A detailed description of this mechanism, called PCP, is in [PCP-BASE].
CPEの背後にあるアプリケーションがUPnPv2 / NAT-PMP-認識している場合は、O、追加のポートは、そのメカニズムを介して要求されることがあります。この場合、CPEは、LSNにそれらの要求を転送する必要があり、かつ要求されたポートが使用可能かそうでない（と彼らが利用できない場合、いくつかの選択肢が提供されるべきである）場合LSNは、報告を返信すべきです。ここで再び、潜在的なサービス拒否攻撃を防ぐために、メカニズムはUPnPv2 / NAT-PMPパケットストームと高速ポート割り当てを防止するための場所である必要があります。 PCPと呼ばれるこのメカニズムの詳細な説明は、[PCP-BASE]です。
Whatever signaling mechanism is used inside the tunnels -- DHCP, IP Control Protocol (IPCP), or PCP based, synchronization between the signaling server and PRR must be established in both directions. For example, if we use DHCP as the signaling mechanism, the PRR must communicate to the DHCP server at least its IP range. The DHCP server then starts to allocate IP addresses and port ranges to CPEs and communicates back to the PRR which IP and port range have been allocated to which CPE, so the PRR knows to which tunnel to redirect incoming traffic. In addition, DHCP MUST also communicate lifetimes of port ranges assigned to CPE via the PRR. DHCP server may be co-located with the PRR function to ease address management and also to avoid the need to introduce a communication protocol between the PRR and DHCP.
ベースDHCP、IP制御プロトコル（IPCP）、又はPCP、シグナリング・サーバとPRRの間の同期は双方向に確立されなければならない - どのようなシグナリングメカニズムは、トンネル内で使用されています。私たちは、シグナリングメカニズムとしてDHCPを使用した場合、PRRは、少なくともそのIP範囲DHCPサーバに通信する必要があります。 DHCPサーバは、IPアドレスとポートを割り当てるために開始したCPEの範囲であり、バックPRRは、着信トラフィックをリダイレクトするためにどのトンネルに知っているように、IPおよびポート範囲は、どのCPEに割り当てられているPRRに通信します。また、DHCPは、PRRを介してCPEに割り当てられたポート範囲の寿命をも通信しなければなりません。 DHCPサーバは、アドレス管理を容易にするためにもPRRとDHCP間の通信プロトコルを導入する必要性を回避するために、PRR機能と同じ場所に配置することができます。
If UPnPv2/NAT-PMP is used as the dynamic port allocation mechanism, the PRR must also communicate to the DHCP (or IPCP) server to avoid those ports. The PRR must somehow (e.g., using DHCP or IPCP options) communicate back to CPE that the allocation of ports was successful, so CPE adds those ports to existing port ranges.
UPnPv2 / NAT-PMPは、動的ポート割り当てメカニズムとして使用される場合、PRRはまた、これらのポートを回避するために、DHCP（またはIPCP）サーバと通信しなければなりません。 PRRは、何らかの形で（例えば、DHCPまたはIPCPオプションを使用して）CPEは、既存のポート範囲にこれらのポートを追加して、ポートの割り当てが成功したことをバックCPEに通信しなければなりません。
Note that operation can be even simplified if a fixed length of port ranges is assigned to all customers and no differentiation is implemented based on port-range length. In such case, the binding table maintained by the PRR can be dynamically built upon the receipt of a first packet from a port-restricted device.
ポートの固定長がすべての顧客に割り当てられ、全く区別がポートレンジ長さに基づいて実装されていない範囲であれば、その操作も簡略化することができます。このような場合には、PRRによって維持バインディングテーブルは、動的ポート制限装置からの最初のパケットの受信に基づいて構築することができます。
Each gateway within the A+P subsystem manages a certain portion of A+P address space; that is, a portion of IPv4 space that is extended by borrowing bits from the port number. This address space may be a single, port-restricted IPv4 address. The gateway MAY use its managed A+P address space for several purposes:
A + P・サブシステム内の各ゲートウェイは、+ Pのアドレス空間の特定の部分を管理します。すなわち、ポート番号からビットを借りることによって拡張されたIPv4空間の一部です。このアドレス空間は、単一の、ポート制限のIPv4アドレスであってもよいです。ゲートウェイは、いくつかの目的のためにその管理A + Pのアドレス空間を使用することがあります：
o Allocation of a sub-portion of the A+P address space to other authenticated A+P gateways in the A+P subsystem (referred to as delegation). We call the allocated sub-portion delegated address space.
A + P・サブシステム内の他の認証A + PゲートウェイにA + Pアドレス空間のサブ部分のO割り当ては、（委任と呼ばれます）。私たちは、割り当てられたサブ部分委任アドレス空間を呼び出します。
o Exchange of (untranslated) packets with the external address realm. For this to work, such packets MUST use a source address and port belonging to the non-delegated address space.
O外部アドレスレルムを持つ（未翻訳）パケットの交換。これが機能するためには、そのようなパケットは、非委任アドレス空間に属する送信元アドレスとポートを使用する必要があります。
If the gateway is also capable of performing the NAT function, it MAY translate packets arriving on an internal interface that are outside of its managed A+P address space into non-delegated address space.
ゲートウェイはまた、NAT機能を実行することが可能である場合、それは非委任アドレス空間にその管理A + Pアドレス空間の外にある内部インターフェイスに到着したパケットを変換することができます。
Hence, a provider may have 'islands' of A+P as they slowly deploy over time. The provider does not have to replace CPE until they want to provide the A+P function to an island of users or even to one particular user in a sea of non-A+P users.
彼らはゆっくりと時間をかけて展開としてしたがって、プロバイダはA + Pの「島」を持っていることがあります。プロバイダは、彼らは、ユーザーの島に、あるいは非A + Pユーザーの海の内の1人の特定のユーザにA + P機能を提供したいまでCPEを交換する必要はありません。
An A+P gateway ("A"), accepts incoming connections from other A+P gateways ("B"). Upon connection establishment (provided appropriate authentication), B would "ask" A for delegation of an A+P address. In turn, A will inform B about its public IPv4 address and will delegate a portion of its port range to B. In addition, A will also negotiate the encaps/decaps function with B (e.g., let B know the address of the decaps device at the endpoint of the tunnel).
A + Pゲートウェイ（ "A"）は、他のA + Pゲートウェイ（ "B"）からの着信接続を受け付けます。 （適切な認証を提供した）コネクション確立時に、BはA + Pアドレスの委任に対してAを「尋ねる」ことになります。ターンでは、Aは、そのパブリックIPv4アドレスについてBに通知し、またBにそのポート範囲の一部を委譲します、AもENCAPSをネゴシエートします/ Bとの機能をdecaps（例えば、Bはdecapsデバイスのアドレスを知っていますトンネルのエンドポイントで）。
This could be implemented, for example, via a NAT-PMP- or DHCP-like solution. In general, the following rule applies: a sub-portion of the managed A+P address space is delegated as long as devices below ask for it; otherwise, private IPv4 is provided to support legacy hosts.
これは、NAT-PMP-やDHCPのような液を介して、例えば、実施することができます。一般的には、以下のルールが適用されます：管理A + Pアドレス空間のサブ部分は限りデバイスは、以下のことを求めるよう委任されます。それ以外の場合は、プライベートIPv4は、レガシーホストをサポートするために提供されます。
The following examples use an IPv4 address from the blocks reserved for documentation as defined in [RFC5737].
[RFC5737]で定義されるように以下の実施例は、ドキュメントのために予約ブロックからIPv4アドレスを使用します。
private +-----+ +-----+ public
address ---| B |==========| A |--- Internet
realm +-----+ +-----+
Address space realm of A:
public IPv4 address = 192.0.2.1
port range = 0-65535
Address space realm of B: public IPv4 address = 192.0.2.1 port range = 2560-3071
Bのアドレス空間レルム：パブリックIPv4アドレス= 192.0.2.1ポート範囲= 2560から3071
Figure 3: Configuration Example
図3：設定例
Figure 3 illustrates a sample configuration. Note that A might actually consist of three different devices: one that handles signaling requests from B; one that performs encapsulation and decapsulation; and, if provided, one device that performs the NATing function (e.g., an LSN). Packet forwarding is assumed to be as follows: in the "outbound" case, a packet arrives from the private address realm to B. As stated above, B has two options: it can either apply or not apply the NAT function. The decision depends upon the specific configuration and/or the capabilities of A and B. Note that NAT functionality is required to support legacy hosts; however, this can be done at either of the two devices A or B. The term "NAT" refers to translating the packet into the managed A+P address (B has address 192.0.2.1 and ports 2560-3071 in the example above). We then have two options:
図3は、サンプル構成を示す図です。 Aは実際には3つの異なるデバイスから成るかもしれないことに注意してください：Bからのリクエストシグナリング処理1。カプセル化及びデカプセル化を行うもの。そして、提供される場合、（例えば、LSN）NAT変換機能を実行する一つのデバイス。パケット転送は、以下のようであると仮定される。上述したように、「発信」の場合に、パケットがBにプライベートアドレス領域から到着、Bの2つのオプションを有している：それはNAT機能を適用適用するかどうしますか。決定は、NAT機能は、従来のホストをサポートするために必要であることを特定の構成および/またはAとBノートの能力に依存します。しかし、この2つのデバイスのAまたはB「NAT」は管理A + Pアドレスにパケットを変換という用語（Bは、上記の例では、アドレス192.0.2.1とポート2560から3071を有している）のいずれかで行うことができます。私たちは、その後、2つのオプションがあります。
1) B NATs the packet. The translated packet is then tunneled to A. A recognizes that the packet has already been translated because the source address and port match the delegated space. A decapsulates the packet and releases it in the public Internet.
1）BのNATパケット。翻訳されたパケットはA. Aにトンネリングされた送信元アドレスとポートが委任スペースに一致するので、パケットが既に翻訳されていることを認識しています。公共のインターネットでのパケットを解放それをデカプセル化します。
2) B does not NAT the packet. The untranslated packet is then tunneled to A. A recognizes that the packet has not been translated, so A forwards the packet to a co-located NATing device, which translates the packet and routes it in the public Internet. This device, e.g., an LSN, has to store the mapping between the source port used to NAT and the tunnel where the packet came from, in order to correctly route the reply. Note that A cannot use a port number from the range that has been delegated to B. As a consequence, A has to assign a part of its non-delegated address space to the NATing function.
2）BはパケットをNAT変換しません。未翻訳パケットは、その後、A. Aにトンネリングされ、Aはパケット及び公衆インターネット内のルートを変換する同一位置のNAT変換デバイスにパケットを転送するように、パケットは、翻訳されていないことを認識する。この装置は、例えば、LSNは、NAT、パケットが正しくルーティング応答するために、から来たトンネルに使用されるソースポートとの間のマッピングを格納しなければなりません。 Aは、結果としてBに委任された範囲からポート番号を使用することはできません、Aは、NAT変換関数にその非委任アドレス空間の一部を割り当てる必要があります。
"Inbound" packets are handled in the following way: a packet from the public realm arrives at A. A analyzes the destination port number to understand whether or not the packet needs to be NATed.
「インバウンド」のパケットは、次のように処理されます：公共分野からのパケットはA. Aに到着したパケットがNAT処理する必要があるかどうかを理解するために宛先ポート番号を分析します。
1) If the destination port number belongs to the range that A delegated to B, then A tunnels the packet to B. B NATs the packet using its stored mapping and forwards the translated packet to the private domain.
宛先ポート番号をBに委任範囲に属する場合は1）、その後、Aは、B BのNATのパケットにその格納されたマッピングを使用してパケットをトンネルとプライベートドメインに変換パケットを転送します。
2) If the destination port number is from the address space of the LSN, then A passes the packet on to the co-located LSN, which uses its stored mapping to NAT the packet into the private address realm of B. The appropriate tunnel is stored as well in the mapping of the initial NAT. The LSN then encapsulates the packet to B, which decapsulates it and normally routes it within its private realm.
宛先ポート番号は、LSNのアドレス空間からのものである場合2）、次いでAは適切なトンネルであるBのプライベートアドレス領域にNATにパケットをその格納されたマッピングを使用して同じ場所に配置LSN、上にパケットを渡します最初のNATのマッピングにも同様に保存されました。 LSNは、それをデカプセル化し、通常、そのプライベート領域内のルートをBにパケットをカプセル化します。
3) Finally, if the destination port number falls in neither a delegated range nor the address range of the LSN, A discards the packet. If the packet is passed to the LSN, but no mapping can be found, the LSN discards the packet.
宛先ポート番号が委任範囲もLSNのアドレス範囲のいずれもになった場合3）最後に、Aは、パケットを破棄する。パケットは、LSNに渡されますが、マッピングが見つからない場合、LSNは、パケットを破棄します。
Observe that A must be able to receive all IPv4 packets destined to the public IPv4 address (192.0.2.1 in the example), so that it can make routing decisions according to the port number. On the other hand, B receives IPv4 packets destined to the public IPv4 address only via the established tunnel with A. In other words, B uses the public IPv4 address just for translation purposes, but it is not used to make routing decisions. This allows us to keep the routing logic at B as simple as described above, while enabling seamless communication between A+P devices sharing the same public IPv4 address.
Aは、それがポート番号に応じてルーティング決定を行うことができるように、パブリックIPv4アドレス（例では192.0.2.1）宛のすべてのIPv4パケットを受信できなければならないことを確認します。一方、Bのみ換言すればAと確立されたトンネルを介してパブリックIPv4アドレス宛てのIPv4パケットを受信し、Bは単なる翻訳のためにパブリックIPv4アドレスを使用し、ルーティング決定を行うために使用されません。これは、同じパブリックIPv4アドレスを共有A + P・デバイス間のシームレスな通信を可能にしながら、上述したような単純なBにルーティングロジックを保つために私たちを可能にします。
private +-----+ +-----+ public
address ---| B |==========| A |--- Internet
realm 1 +-----+ +-----+
|
private +-----+ |
address ---| C |============/
realm 2 +-----+
Address space realm of A:
public IPv4 address = 192.0.2.1
port range = 0-65535
Address space realm of B: public IPv4 address = 192.0.2.1 port range = 2560-3071
Bのアドレス空間レルム：パブリックIPv4アドレス= 192.0.2.1ポート範囲= 2560から3071
Address space realm of C: public IPv4 address = 192.0.2.1 port range = 0-2559
Cのアドレス空間レルム：パブリックIPv4アドレス= 192.0.2.1ポート範囲= 0から2559
Figure 4: Hierarchical A+P
図4：階層A + P
Consider the example shown in Figure 4. Here, both B and C use the encaps/decaps function to establish a tunnel with A, and they are assigned the same public IPv4 address with different, non-overlapping port ranges. Assume that a host in B's private realm sends a packet destined to address 192.0.2.1 and port 2000, and that B has been instructed to NAT all packets destined to 192.0.2.1. Under these assumptions, B receives the packet and NATs it using its own public IPv4 address (192.0.2.1) and a port selected from its configured port range (e.g., 3000). B then tunnels the translated packet to A. When A receives the packet via the tunnel, it looks at the destination address and port, recognizes C's delegated range, and then tunnels the packet to C. Observe that, apart from stripping the tunnel header, A handles the packet as if it came from the public Internet. When C receives the packet, it NATs the destination address into one address chosen from its private address realm, while keeping the source address (192.0.2.1) and port (3000) untranslated. Return traffic is handled the same way. Such a mechanism allows hosts behind A+P devices to communicate seamlessly even when they share the same public IPv4 address.
BとCの両方がENCAPS / decapsはAとトンネルを確立するように機能し、それらは異なる、非重複ポート範囲と同じパブリックIPv4アドレスを割り当てられて使用し、ここで、図4に示されている例を考えます。 Bのプライベート領域内のホストは192.0.2.1、ポート2000をアドレス宛てのパケットを送信し、そのBがNAT 192.0.2.1宛のすべてのパケットに指示されたと仮定します。これらの仮定の下で、Bは、それ自身のパブリックIPv4アドレス（192.0.2.1）と、その設定されたポートの範囲（例えば、3000）から選択されたポートを使用してパケットとのNATを受信します。 Bは、その後、Aがトンネルを介してパケットを受信すると、それは離れてトンネルヘッダを剥ぎ取りから、宛先アドレスおよびポートを見Cの委任範囲を認識し、次にそれを守っCにパケットをトンネリングA.に翻訳パケットをトンネリングそれは公共のインターネットから来たかのようにAは、パケットを処理します。 Cがパケットを受信すると、NATのプライベートアドレス領域から選択された一つのアドレスに宛先アドレス、送信元アドレス（192.0.2.1）とポート（3000）非翻訳を維持しつつ。リターントラフィックは、同じように処理されます。そのような機構は、+ Pのデバイスの背後にあるホストは、それらが同一のパブリックIPv4アドレスを共有する場合でもシームレスに通信することを可能にします。
Please refer to Section 4 for a discussion of an alternative A+P mechanism that does not incur path-stretch penalties for intra-domain communication.
ドメイン内の通信のためのパス・ストレッチのペナルティを被るない代替のA + Pメカニズムの議論については、セクション4を参照してください。
Since each device in an A+P subsystem provides the encaps/decaps function, new devices can establish tunnels and become in turn part of an A+P subsystem. As noted above, being part of an A+P subsystem implies the capability of talking to the external address realm without any translation. In particular, as described in the previous section, a device X in an A+P subsystem can be reached from the external domain by simply using the public IPv4 address and a port that has been delegated to X. Figure 5 shows an example where three devices are connected in a chain. In other words, A+P signaling can be used to extend end-to-end connectivity to the devices that are in an A+P subsystem. This allows A+P-aware applications (or OSes) running on end-hosts to enter an A+P subsystem and exploit untranslated connectivity.
A + P・サブシステム内の各デバイスがENCAPSを提供するので、/機能をdecaps、新しいデバイスがトンネルを確立し、A + Pサブシステムのターン部になることができます。 A + Pサブシステムの一部である、上述したように、変換されずに外部アドレス領域に話の能力を意味しています。前のセクションで説明したように、特に、A + P・サブシステム内のデバイスXは、単に、パブリックIPv4アドレス及びX.図5に委任されたポートを使用して、外部ドメインから到達することができ、3つの例を示していますデバイスをチェーンで接続されています。換言すれば、A + Pシグナリングは、A + P・サブシステム内にあるデバイスに、エンドツーエンドの接続性を拡張するために使用することができます。これは、エンドホスト上で実行されている+ P対応のアプリケーション（またはのOS）はA + Pサブシステムを入力し、翻訳されない接続を利用することを可能にします。
There are two modes for end-hosts to gain fine-grained control of end-to-end connectivity. The first is where actual end-hosts perform the NAT function and the encaps/decaps function that is required to join the A+P subsystem. This option works in a similar way to the NAT-in-the-host trick employed by virtualization software such as VMware, where the guest operating system is connected via a NAT to the host operating system. The second mode is when applications autonomously ask for an A+P address and use it to join the A+P subsystem. This capability is necessary for some applications that require end-to-end connectivity (e.g., applications that need to be contacted from outside).
エンドツーエンド接続のきめ細かい制御を獲得するためのエンドホストのための2つのモードがあります。実際のエンドホストは、A + P・サブシステムに参加するために必要とされるNAT機能及びENCAPS / decaps機能を実行する場合に最初のです。このオプションは、ゲストオペレーティングシステムは、ホスト・オペレーティング・システムへのNATを介して接続されているVMware社、などの仮想化ソフトウェアで採用NAT・イン・ザ・ホストトリックと同様に動作します。アプリケーションが自律的にA + Pアドレスを尋ねると、A + P・サブシステムに参加するためにそれを使用するときに、第2のモードがあります。この機能は、エンドツーエンド接続（外部から接触する必要例えば、アプリケーション）を必要とするいくつかの用途のために必要です。
+---------+ +---------+ +---------+
internal | gateway | | gateway | | gateway | external
realm --| 1 |======| 2 |======| 3 |-- realm
+---------+ +---------+ +---------+
Figure 5: An A+P Subsystem with Multiple Devices
図5：複数のデバイスを有するA + Pサブシステム
Whatever the reasons might be, the Internet was built on a paradigm that end-to-end connectivity is important. A+P makes this still possible in a time where address shortage forces ISPs to use NATs at various levels. In that sense, A+P can be regarded as a way to bypass NATs.
どのような理由は、インターネットは、エンドツーエンドの接続が重要なパラダイムに基づいて構築された可能性があります。 + Pは、アドレス不足がさまざまなレベルでのNATを使用するようにするISPを強制的に時間で、これはまだ可能にします。その意味で、A + PでのNATをバイパスする方法とみなすことができます。
+---+ (customer2)
|A+P|-. +---+
+---+ \ NAT|A+P|-.
\ +---+ |
\ | forward if in range
+---+ \+---+ +---+ /
|A+P|------|A+P|----|A+P|----
+---+ /+---+ +---+ \
/ NAT if necessary
/ (cust1) (prov. (e.g., provider NAT)
+---+ / router)
|A+P|-'
+---+
Figure 6: A Complex A+P Subsystem
図6：複合体A + Pサブシステム
Figure 6 depicts a complex scenario, where the A+P subsystem is composed of multiple devices organized in a hierarchy. Each A+P gateway decapsulates the packet and then re-encapsulates it again to the next tunnel.
図6は、A + Pサブシステムが階層に編成複数のデバイスで構成されている複雑なシナリオを示しています。各A + Pゲートウェイは、パケットをデカプセル化し、その後、次のトンネルに再びそれを再カプセル化します。
A packet can be NATed either when it enters the A+P subsystem, at intermediate devices, or when it exits the A+P subsystem. This could be, for example, a gateway installed within the provider's network, together with an LSN. Then, each customer operates its own CPE. However, behind the CPE, applications might also be A+P-aware and run their own A+P-gateways; this enables them to have end-to-end connectivity.
それはA + P・サブシステムに入ったときに、パケットは、中間デバイスで、いずれかのNAT処理することができ、またはそれはA + P・サブシステムを終了したとき。これは、例えば、ゲートウェイは一緒にLSNと、プロバイダのネットワーク内に設置することができます。次に、各顧客は独自のCPEを運営しています。しかし、CPEの後ろに、アプリケーションはまた、A + P-注意して、自分のA + P-ゲートウェイを実行するかもしれません。これは、エンドツーエンドの接続性を持つためにそれらを可能にします。
One limitation applies when "delayed translation" is used (e.g., translation at the LSN instead of the CPE). If devices using "delayed translation" want to talk to each other, they SHOULD use A+P addresses or out-of-band addressing.
「遅延翻訳」（代わりCPEのLSNで、例えば、翻訳）を使用した場合1つの制限は適用されます。 「遅延翻訳」を使用しているデバイスは、お互いに話をしたい場合は、A + Pアドレスを使用すべきか、アウトオブバンドのアドレッシング。
A+P architecture
+ Pアーキテクチャ
IPv4 Full-A+P AFTR CGN
| | | |
<-- Full IPv4 ---- Port range ---- Port range ---- Provider --->
allocated & dynamic & LSN NAT ONLY
allocation (NAT on CPE (No mechanism)
(no NAT) (NAT on CPE) and on LSN) for customer to
bypass CGN)
Figure 7: A+P Overall Architecture
図7：A + P全体的なアーキテクチャ
The A+P architecture defines various deployment options within an ISP. Figure 7 shows the spectrum of deployment options. On the far left is the common deployment method for broadband subscribers today, an IPv4 address unrestricted with full port range. Full-A+P refers to a port-range allocation from the ISP. The customer must operate an A+P-aware CPE device, and no NATing functionality is provided by the ISP. The Address Family Transition Router (AFTR), such as DS-Lite [RFC6333], is a hybrid. There is NAT present in the core (in this document, referred to as LSN), but the user has the option to "bypass" that NAT in one form or an other, for example, via A+P, NAT-PMP, etc. Finally, a service provider that only deploys CGN will place a NAT in the provider's core and does not allow the customer to "bypass" the translation process or modify ALGs on the NAT. The customer is provider-locked. Notice that all options (besides full IPv4) require some form of tunneling mechanism (e.g., 4in6) and a signaling mechanism (see Section 3.3.1).
A + P・アーキテクチャは、ISP内の様々な展開オプションを定義します。図7は、展開オプションのスペクトルを示します。左端のブロードバンド加入者のための一般的な展開方法今日、フルポート範囲で無制限のIPv4アドレスです。フルA + Pは、ISPからポート範囲の割り当てを指します。顧客は、A + P対応CPEデバイスを操作しなければならない、とNO NAT変換機能は、ISPによって提供されていません。このようなDS-Liteは[RFC6333]のアドレスファミリーの遷移ルータ（AFTR）は、ハイブリッドです。そこNAT本発明は、（本書では、LSNと称する）コアであるが、ユーザは、例えば、一つの形態または他のでNAT「バイパス」するオプションを有している、などA + P、NAT-PMPを介して。最後に、唯一のCGNを展開し、サービスプロバイダは、プロバイダのコアでNATを配置し、「バイパス」に顧客に翻訳プロセスを許可またはNAT上のALGを変更しません。顧客は、プロバイダロックされています。 （フルIPv4の他に）すべてのオプションがトンネリングメカニズム（例えば、4in6）及びシグナリングメカニズムのいくつかのフォームを必要とすることに注意してください（セクション3.3.1を参照）。
There are implementations of A+P as well as documented experiments. France Telecom did experiments that are described in [A+P-EXPERIMENTS]. As seen in that experiment, most tested applications are unaffected. There are problems with torrent protocol and applications, as the listening port is out of A+P port range and some UPnP may be required to make it work with A+P.
A + Pの実装だけでなく、文書化実験があります。フランステレコムは、[A + P-実験]で説明された実験を行いました。その実験で見られるように、ほとんどのテストアプリケーションは影響を受けません。リスニングポートはA + Pポートの範囲外であり、いくつかのUPnPは、それはA + Pで動作させるために必要とされるよう急流プロトコルやアプリケーションに問題があります。
Problems with BitTorrent have already been experienced in the wild by users trapped behind a non-UPnP-capable CPE. The current workaround for the end-user is to statically map ports, which can be done in the A+P scenario as well.
BitTorrentのの問題は、すでに非UPnP対応のCPEの後ろにトラップされたユーザーによって野生で経験してきました。エンドユーザの現在の回避策は、静的にもA + Pシナリオで行うことができるポートをマッピングすることです。
BitTorrent tests and experiments in shared IP and port-range environments are well described in [BITTORRENT-ADDR-SHARING]. Conclusions in that document tell us that two limitations were experienced. The first occurred when two clients sharing the same IP address tried to simultaneously retrieve the SAME file located in a SINGLE remote peer. The second limitation occurred when a client tried to download a file located on several seeders, when those seeders shared the same IP address. Mutual file sharing between hosts having the same IP address has been checked. Indeed, machines having the same IP address can share files with no alteration compared to current IP architectures.
共用IPおよびポート範囲環境でBitTorrentの試験と実験が良く[ビットトレント-ADDR共有]に記載されています。その文書の結論は、2つの制限が経験したことを教えて。同じIPアドレスを共有する2つのクライアントが同時にSINGLEリモートピアにある同じファイルを取得しようとしたときに最初が発生しました。クライアントは、これらのシーダーが同じIPアドレスを共有する場合、いくつかのシーダー上にあるファイルをダウンロードしようとしたときに、第2の制限が発生しました。同じIPアドレスを持つホスト間での相互のファイル共有がチェックされています。確かに、同じIPアドレスを持つマシンは、現在のIPアーキテクチャに比べて無変更とファイルを共有することができます。
Working implementations of A+P can be found in:
A + Pの作業実装はで見つけることができます：
o Internet Systems Consortium AFTR (http://www.isc.org/software/aftr),
（http://www.isc.org/software/aftr）AFTR Oインターネットシステムコンソーシアム、
o FT Orange opensource A+P (http://opensourceaplusp.weebly.com/) developed by Xiaoyu Zhao, Xiaohong Deng, Tao Zheng, and
暁趙、Xiaohongトウ、タオ鄭によって開発されたFTオレンジオープンソースA + P（http://opensourceaplusp.weebly.com/）O、及び
o 4rd (IPv4 Residual Deployment) from ipinfusion.com, which is stateless A+P.
ステートレスA + Pであるipinfusion.comからO 4RD（IPv4の残留展開）。
SMAP stands for Stateless A+P Mapping. This function is responsible for, in a stateless scheme, encapsulating IPv4 packets in IPv6 ones as well as decapsulating IPv4 packets from IPv6 ones. An SMAP function may be hosted in a PRR, end-user device, etc.
SMAPはステートレスA + Pマッピングを表します。この関数は、ステートレス方式では、IPv6ののものでIPv4パケットをカプセル化するだけでなく、IPv6ののものからIPv4パケットをカプセル開放する責任があります。 SMAP関数はPRR、エンドユーザ装置、等でホストされてもよいです
As mentioned in Section 4.1 of [RFC6052], the suffix part may enclose the port.
[RFC6052]のセクション4.1で述べたように、接尾部は、ポートを囲むことができます。
The Stateless A+P Mapping (SMAP) gateway consists in two basic functions as described in Figure 8.
ステートレスA + Pマッピング（SMAP）ゲートウェイ、図8で説明したように、2つの基本的な機能からなります。
1. SMAP encapsulates an IPv4 packet, destined to a shared IPv4 address, in an IPv6 one. The IPv6 source address is constructed using an IPv4-embedded IPv6 address [RFC6052] from the IPv4 source address and port number plus the IPv6 prefix that has been provisioned to the node performing the SMAP function. The destination IPv6 address is constructed using the shared IPv4 destination address and port number plus the IPv6 prefix that has been provisioned to the SMAP function and that is dedicated to IPv4 destination addresses.
1. SMAPは、IPv6のいずれかで、共有IPv4アドレス宛てのIPv4パケットをカプセル化します。 IPv6ソースアドレスは、IPv4ソースアドレスとポート番号とSMAPの機能を実行するノードにプロビジョニングされたIPv6プレフィックスからのIPv4埋め込みIPv6アドレス[RFC6052]を使用して構築されています。宛先IPv6アドレスは、共有IPv4の宛先アドレスとポート番号とSMAP関数にプロビジョニングされたIPv6プレフィックスを用いて構成されており、それは、IPv4宛先アドレス専用です。
2. SMAP extracts IPv4 incoming packets from IPv6 incoming ones that have IPv6 source addresses belonging to the prefix of the node performing the SMAP function. Extracted IPv4 packets are then forwarded to the point identified by the IPv4 destination address and port number.
2. SMAPは、SMAPの機能を実行するノードのプレフィックスに属するIPv6ソースアドレスを持つIPv6の着信ものからIPv4の着信パケットを抽出します。抽出されたIPv4パケットは、その後、IPv4宛先アドレスとポート番号によって識別されるポイントに転送されます。
+-------------------+
| |----IPv6---\
----IPv4---\| |----IPv4---\\
-----------/| |-----------//
| |-----------/
| SMAP |
| | /--IPv6-----
/---IPv4----| |//---IPv4----
\-----------| |\\-----------
| | \-----------
+-------------------+
Figure 8: Stateless A+P Mapping Gateway Function
図8：ステートレスA + Pマッピングゲートウェイ機能
An SMAP-enabled node will perform the stateless 6/4 mapping function for all public shared IPv4 addresses for which it was designated as a stateless 6/4 mapping gateway.
SMAP対応ノードは、それがステートレス6/4マッピングゲートウェイとして指定しているすべてのパブリック共有IPv4アドレスのステートレス6/4マッピング機能を実行します。
To perform the stateless 6/4 mapping function, an SMAP gateway must:
ステートレス6/4マッピング機能を実行するために、SMAPのゲートウェイが次の条件を満たす必要があります。
o be provided with an IPv6 prefix (i.e., Pref6). The SMAP gateway uses this prefix to construct IPv6 source addresses for all IPv4 shared addresses for which it was designated as an SMAP gateway. The IPv6 prefix may be provisioned statically or dynamically (e.g., DHCP).
O IPv6プレフィックス（すなわち、Pref6）を設けること。 SMAPゲートウェイは、SMAPのゲートウェイとして指定しているすべてのIPv4共用アドレスのIPv6ソースアドレスを構成するために、このプレフィックスを使用します。 IPv6プレフィックス（例えば、DHCP）静的または動的にプロビジョニングすることができます。
o be able to know the IPv6 prefix of the node serving as another SMAP gateway for IPv4 destination addresses. This prefix may be known in various ways:
O IPv4宛先アドレスの別のSMAPゲートウェイとしてのノードのIPv6プレフィックスを知ることができます。このプレフィックスは、さまざまな方法で知られているかもしれません。
* Default or Well-Known Prefix (i.e., 64:ff9b::/96) that was provisioned statically or dynamically;
*デフォルトまたは既知のプレフィックス（すなわち、64：ff9b :: / 96）、静的または動的にプロビジョニングされました。
* Retained at the reception of incoming IPv4-in-IPv6 encapsulated packets;
*着信のIPv4型のIPv6カプセル化パケットの受信に保持。
* Discovered at the start of communication, thanks to mechanisms such as DNS resolution, for example.
*例えば、DNS解決のようなメカニズムのおかげで、通信の開始時に発見。
When the SMAP-enabled node receives IPv4 packets with IPv4 source addresses for which it was not designated as an smap gateway, it will not perform stateless 6/4 mapping function for those packets. Those packets will be handled in a classical way (i.e., forwarded, dropped, or locally processed).
SMAP対応ノードは、それがSMAPゲートウェイとして指定されなかったIPv4ソースアドレスとIPv4パケットを受信すると、それらのパケットのためにステートレス6/4マッピング機能を実行しないであろう。それらのパケット（すなわち、転送され、ドロップされた、またはローカルで処理された）古典的な方法で処理されます。
When the SMAP-enabled node receives IPv6 packets with IPv6 addresses that do not match with its IPv6 prefix, it will not perform the stateless 6/4 mapping function for those packets. Those packets will be handled in a classical way (i.e., forwarded, dropped, or locally processed).
SMAP対応のノードがそのIPv6プレフィックスと一致していないIPv6アドレスとIPv6パケットを受信すると、これらのパケットのステートレス6/4マッピング機能を実行しません。それらのパケット（すなわち、転送され、ドロップされた、またはローカルで処理された）古典的な方法で処理されます。
In this configuration, the node A performs the stateless mapping function on the received IPv4 traffic (encapsulated in IPv6 packets) before forwarding to the node B. The node B performs the stateless mapping function on the received IPv6 traffic (extracting IPv4 packets) before forwarding the IPv4 traffic to the destination identified by the IPv4 destination address and port number. In the opposite direction, and as previously, the node B performs the stateless mapping function on the received IPv4 traffic (encapsulating in IPv6 packets) before forwarding to the node A. The node A performs the stateless mapping function on the received IPv6 traffic (extracting IPv4 packets) before forwarding the IPv4 traffic to the point identified by the IPv4 destination address and port number. In this case, only IPv6 traffic is managed in the network segment between the nodes A and B.
この構成では、ノードAは、ノードBは、転送する前に受信されたIPv6トラフィック（抽出IPv4パケット）にステートレスマッピング関数を実行するノードBに転送する前に、（IPv6パケットにカプセル化された）受信したIPv4トラフィックにステートレスマッピング関数を実行しますIPv4宛先アドレスとポート番号によって識別される宛先へのIPv4トラフィック。反対方向に、そして先に、ノードBは、ノードAは、受信したIPv6トラフィック上のステートレスマッピング関数を実行するノードAに転送する前に、（抽出する（IPv6パケットにカプセル化する）、受信したIPv4トラフィックにステートレスマッピング関数を実行しますIPv4宛先アドレスとポート番号によって識別される点にIPv4トラフィックを転送する前にIPv4パケット）。この場合には、IPv6のみのトラフィックは、ノードAとBとの間のネットワークセグメントで管理されています
+------+ +------+
| |----IPv6---\ | |
----IPv4---\| |----IPv4---\\| |----IPv4---\
-----------/| |-----------//| |-----------/
| |-----------/ | |
| SMAP | | SMAP |
| | /----IPv6---| |
/---IPv4----| |//---IPv4----| |/---IPv4----
\-----------| |\\-----------| |\-----------
| | \-----------| |
+------+ +------+
node A node B
Figure 9
図9
Several deployment scenarios of the SMAP function may be envisaged in the context of port-range-based solutions:
SMAPの機能のいくつかの展開シナリオは、ポート範囲ベースのソリューションとの関連で考えられます。
o An SMAP function is embedded in a port-restricted device. Other SMAP-enabled nodes are deployed in the boundaries between IPv6- enabled realms and IPv4 ones. This scenario may be deployed particularly for intra-domain communications so as to interconnect heterogeneous realms (i.e., IPv6/IPv4) within the same Autonomous System (AS).
O SMAP機能は、ポート制限型のデバイスに組み込まれています。その他SMAP対応のノードはIPv6-有効レルムとのIPv4のものの間の境界に配備されています。同じ自律システム（AS）内に異種レルム（すなわち、のIPv6 / IPv4）を相互接続するように、このシナリオは、特にドメイン内の通信のために配備されてもよいです。
o An SMAP function is embedded in a port-restricted device. Other SMAP-enabled nodes are deployed in the interconnection segment (with adjacent IPv4-only ones) of a given AS. This deployment scenario is more suitable for service providers targeting the deployment of IPv6 since it eases the migration to full IPv6. Core nodes are not required to continue to activate both IPv4 and IPv6 transfer capabilities.
O SMAP機能は、ポート制限型のデバイスに組み込まれています。他のSMAP対応ノードは、次のように与えられたの（隣接IPv4のみのものと）相互接続セグメントに配備されています。この展開シナリオでは、それが完全なIPv6への移行が容易になりますので、IPv6導入をターゲットにサービスプロバイダーに適しています。コアノードは、IPv4とIPv6の両方の転送機能をアクティブにするために継続する必要はありません。
Other considerations regarding the interconnection of SMAP-enabled domains should be elaborated. The following provides a non-exhaustive list of interconnection schemes.
SMAP対応ドメインの相互接続に関するその他の考慮事項を詳述する必要があります。以下は、相互接続スキームの非網羅的なリストを提供します。
o The interconnection of two domains implementing the SMAP function may be deployed via IPv4 Internet (Figure 10): this means that IPv4 packets encapsulated in IPv6 packets are transferred using IPv6 until reaching the first SMAP-enabled node. Then, these packets are decapsulated and are forwarded using IPv4 transfer capabilities. A remote SMAP-enabled node will receive those packets and proceed to an IPv4-in-IPv6 encapsulation. These packets are then routed normally until reaching the port-restricted devices that decapsulate the packets.
oをSMAPの機能を実現する二つのドメインの相互接続は、IPv4インターネット（図10）を介して展開することができる。これは、IPv6パケットにカプセル化されたIPv4パケットを最初SMAP対応ノードに到達するまでIPv6を使用して転送されることを意味します。次に、これらのパケットはカプセル化が解除され、IPv4の転送機能を使用して転送されます。リモートSMAP対応ノードは、それらのパケットを受信し、IPv4インのIPv6カプセル化に進むことになります。これらのパケットは、その後、パケットをデカプセル化ポート制限型のデバイスに到達するまで正常にルーティングされます。
+------+ +------+ +--------+ +------+ +------+
| |--IPv6--\ | | | | | |---IPv6--\ | |
| |--IPv4--\\| |---|-IPv4---|--\| |---IPv4--\\| |
| |--------//| |---|--------|--/| |---------//| |
| |--------/ | | |Internet| | |---------/ | |
| SMAP | | SMAP | | IPv4 | | SMAP | | SMAP |
| | /--IPv6--| | | | | | /---IPv6--| |
| |//--IPv4--| |/--|-IPv4---|---| |//--IPv4---| |
| |\\--------| |\--|--------|---| |\\---------| |
| | \--------| | | | | | \---------| |
+------+ +------+ +--------+ +------+ +------+
Source node A node B Destination
Figure 10: Interconnection Scenario 1
図10：相互接続シナリオ1
o A second scheme is to use IPv6 to interconnect two realms that implement the SMAP function (Figure 11). An IPv6 prefix (i.e., Pref6) assigned by IANA is used for this service. If appropriate routing configurations have been enforced, then the IPv6- encapsulated packets will be routed until the final destination. In order to implement this model, IPv4-inferred IPv6 prefixes are required to be injected in the IPv6 inter-domain routing tables.
O第2の方式は、SMAPの機能を実現する2つのレルム（図11）を相互接続するためにIPv6を使用することです。 IANAによって割り当てられたIPv6プレフィックス（すなわち、Pref6）は、このサービスのために使用されます。適切なルーティング構成が適用されている場合には、IPv6-カプセル化されたパケットは、最終的な宛先までルーティングされます。このモデルを実現するために、IPv4に推論IPv6プレフィックスは、IPv6ドメイン間ルーティングテーブルに注入する必要があります。
+------+ +------------+ +------+
| | | | | |
| |----IPv6-----|----IPv6----|----IPv6----\ | |
| |----IPv4-----|------------|----IPv4----\\| |
| |-------------|------------|------------//| |
| |-------------|------------|------------/ | |
| SMAP | | Internet v6| | SMAP |
| | /-----IPv6--|------------|-----IPv6-----| |
| |//---IPv4----|------------|-------IPv4---| |
| |\\-----------|------------|--------------| |
| | \-----------|------------|--------------| |
| | | | | |
+------+ +------------+ +------+
Source Destination
Figure 11: Interconnection Scenario 2
図11：相互接続シナリオ2
The deployment of the SMAP function allows for smooth migration of networks to an IPv6-only scheme while maintaining the delivery of IPv4 connectivity services to customers. The delivery of IPv4 connectivity services over an IPv6-only network does not require any stateful function to be deployed on the core network. Owing to this A+P mode, both the IPv4 service continuity and the migration to an IPv6-only deployment model are facilitated.
顧客へのIPv4接続サービスの提供を維持しながら、SMAP機能の展開は、IPv6のみの制度へのネットワークのスムーズな移行が可能になります。 IPv6のみのネットワーク上でIPv4接続サービスの提供は、コアネットワーク上で展開されるように任意のステートフルな機能を必要としません。 IPv6のみの展開モデルにこのA + Pモード、IPv4サービスの継続性および移動の両方のために促進されます。
The SMAP section (Section 4) discusses two modes: the binding and the stateless modes. Dynamic port allocation is not a feature of the stateless mode, but it is supported in the binding mode. In the binding mode, distinct external IPv4 addresses may be used, but this is not recommended.
結合およびステートレスモード：SMAPセクション（セクション4）は2つのモードについて説明します。動的ポート割り当ては、ステートレスモードの機能ではありませんが、それは結合モードでサポートされています。結合モードでは、別個の外部IPv4アドレスを使用することができるが、これは推奨されません。
o Stateless Mode
お Ｓたてぇっｓ もで
Complete stateless mapping implies that the IPv4 address and the significant bits coding the port range are reflected inside the IPv6 prefix assigned to the port-restricted device. This can be achieved either by embedding the full IPv4 address and the significant bits in the IPv6 prefix or by applying an algorithmic approach. Two alternatives are offered when such a stateless mapping is to be enabled:
完全なステートレスマッピングは、IPv4アドレスとポート範囲をコーディングする上位ビットがポート制限装置に割り当てられたIPv6プレフィックスの内部に反射されることを意味します。これは、完全なIPv4アドレスとIPv6プレフィックスまたはアルゴリズム的アプローチを適用することにより、上位ビットを埋め込むことによってのいずれかで達成することができます。ステートレスマッピングを有効に設定する場合は、二つの選択肢が提供されています：
- use the IPv6 prefix already used for native IPv6 traffic, or
- すでにネイティブIPv6トラフィックのために使用されたIPv6プレフィックスを使用しますか、
- provide two prefixes to the port-restricted device: one for the native IPv6 traffic and one for the IPv4 traffic.
IPv4トラフィック用のネイティブIPv6トラフィック用と1： - ポート制限型デバイスへの2つのプレフィックスを提供しています。
Note that:
ご了承ください：
- Providing two IPv6 prefixes has the advantages of allowing a /64 prefix for the port-restricted device along with another prefix (e.g., a /56 or /64) for native IPv6 traffic. This alternative allows the service provider to relate the native IPv6 traffic addressing plan to the IPv4 addressing plan. The drawback is having to allocate two prefixes to each port-restricted device and to route them. In addition, an address selection issue may be encountered.
- 2つのIPv6プレフィックスを提供することは、ネイティブIPv6トラフィックのための別の接頭辞（例えば、/ 56または/ 64）とともに、ポート制限装置のための/ 64プレフィックスを可能にする利点を有します。この代替は、IPv4アドレス計画にネイティブIPv6トラフィックのアドレッシング計画を関連付けるために、サービスプロバイダができます。欠点は、それらの各ポート制限装置へとルーティングする2つのプレフィックスを割り当てる有しています。また、アドレス選択問題が発生する可能性があります。
- Providing one prefix for both needs (e.g., a /56 or a /64) allows the service provider to handle two types of IPv6 prefix for the port-restricted device and in routing tables. But the drawback is that it strongly links the IPv4 addressing plan to the allocated IPv6 prefixes.
- 両方のニーズ（例えば、/ 56または/ 64）ごとに1つの接頭辞を提供することは、サービスプロバイダは、ポート制限デバイスおよびルーティングテーブルにIPv6プレフィックスの二つのタイプを処理することを可能にします。しかし、欠点は、それが強く、割り当てられたIPv6プレフィックスへのIPv4アドレス計画を結ぶことです。
As mentioned in Section 4.1 of [RFC6052], the suffix part may enclose the port.
[RFC6052]のセクション4.1で述べたように、接尾部は、ポートを囲むことができます。
o Binding Table Mode
O結合表モード
Another alternative is to assign a "normal" IPv6 prefix to the port-restricted device and to use a binding table, which can be hosted by a service node to correlate the (shared IPv4 address, port range) with an IPv6 address part of the assigned IPv6 prefix. For scalability reasons, this table should be instantiated within PRR-enabled nodes that are close to the port-restricted devices. The number of required entries if hosted at the interconnection segment would be equal to the amount of subscribed users (one per port-restricted device).
別の代替では、ポート制限装置に「正常な」IPv6プレフィックスを割り当てるためのIPv6アドレスの一部と（共有IPv4アドレス、ポート範囲）を相関させるためにサービス・ノードによってホストされることができるバインディングテーブルを使用することです割り当てられたIPv6プレフィックス。スケーラビリティの理由から、このテーブルは、ポート制限付きデバイスに近いPRR対応のノード内でインスタンス化されなければなりません。配線セグメントでホストされている場合に必要なエントリの数は、加入ユーザ（ポート制限装置に1つ）の量に等しくなります。
If a Stateless A+P Mapping (SMAP) type of implementation is deployed over intermediate IPv6-only-capable devices, it is recommended that default routes are configured, and the IPv4 routing table is not "leaked" into the IPv6 routing table in terms of having reachability for the packets going towards the Internet.
実装のステートレスA + Pマッピング（SMAP）タイプ中間IPv6のみ対応のデバイス上に配置されている場合、デフォルトルートが設定されていることが推奨され、IPv4ルーティングテーブルは点でIPv6ルーティングテーブルに「漏洩」されていませんインターネットに向かうパケットの到達可能性を持ちます。
One of the stateless A+P variants is 4rd [4rd].
ステートレスA + P変異体の一つは、4RD [4RD]です。
Some large broadband providers will not have enough public IPv4 address space to provide every customer with a single IP address. The natural solution is sharing a single IP address among many customers. Multiplexing customers is usually accomplished by allocating different port numbers to different customers somewhere within the network of the provider.
いくつかの大規模なブロードバンドプロバイダーは、単一のIPアドレスを持つすべての顧客を提供するのに十分なパブリックIPv4アドレス空間を持っていません。自然な解決策は、多くの顧客の間で単一のIPアドレスを共有しています。多重のお客様は、通常はどこかのプロバイダのネットワーク内の異なる顧客に異なるポート番号を割り当てることによって達成されます。
It is expected that, when the provider wishes to enable A+P for a customer or a range of customers, the CPE can be upgraded or replaced to support A+P encaps/decaps functionality. Ideally, the CPE also provides NATing functionality. Further, it is expected that at least another component in the ISP network provides the corresponding A+P functionality, and hence is able to establish an A+P subsystem with the CPE. This device is referred to as an A+P router or Port-Range Router (PRR), and could be located close to PE routers. The core of the network MUST support the tunneling protocol (which SHOULD be IPv6, as per Constraint 7) but MAY be another tunneling technology when necessary. In addition, we do not wish to restrict any initiative of customers who might want to run an A+P-capable network on or behind their CPE. To satisfy both Constraints 1 and 2, unmodified legacy hosts should keep working seamlessly, while upgraded/new end-systems should be given the opportunity to exploit enhanced features.
プロバイダが顧客や顧客の範囲のためにA + Pを有効にしたい場合、CPEは、アップグレードまたは+ PのENCAPSをサポートするために置き換えることができます/機能をdecaps、ことが期待されます。理想的には、CPEはまた、NAT変換機能を提供します。さらに、ISPネットワーク内の少なくとも他の構成要素は、対応する+ P機能を提供し、ひいてはCPEとA + P・サブシステムを確立することが可能であることが予想されます。この装置は、A + Pルータまたはポートレンジルータ（PRR）と呼ばれ、ルータをPEに近接して配置することができます。ネットワークのコアは、（制約7通り、IPv6の必要があります）が、必要な場合、別のトンネリング技術であるかもしれトンネリングプロトコルをサポートしなければなりません。また、我々は彼らのCPE上や後ろにA + P対応のネットワークを実行したい場合があり、お客様の任意の主導権を制限したくありません。制約1と2の両方を満たすために、変更されていないレガシーホストは、アップグレード/新しいエンドシステムが強化された機能を利用する機会を与えられるべきである一方で、シームレスに作業を続ける必要があります。
In the case of mobile service providers, the situation is slightly different. The A+P border is assumed to be the gateway (e.g., Gateway GPRS Support Node (GGSN) / Packet Data Network (PDN) gateway (GW) of 3GPP, or Access Service Network (ASN) GW of Worldwide Interoperability for Microwave Access (WiMAX)). The need to extend the address is not within the provider network, but on the edge between the mobile phone devices and the gateway. While desirable, IPv6 connectivity may or may not be provided.
モバイルサービスプロバイダの場合は、状況は少し異なります。 A + Pの境界は、3GPP、またはアクセスサービスネットワークのゲートウェイ（例えば、ゲートウェイGPRSサポートノード（GGSN）/パケットデータネットワーク（PDN）ゲートウェイ（GW）、マイクロ波アクセスのための世界的相互運用性の（ASN）GW（であると仮定されますWiMAXの））。アドレスを拡張する必要性は、プロバイダネットワーク内ではなく、携帯電話のデバイスとゲートウェイとの間のエッジに。望ましいが、IPv6接続は、または提供してもしなくてもよいです。
For mobile providers, we use the following terms and assumptions:
モバイルプロバイダのために、私たちは以下の用語および仮定を使用します。
4. devices behind the phone, e.g., laptop computer connecting via phone to Internet
電話の後ろ4.デバイスは、例えば、ラップトップコンピュータがインターネットに電話を経由して接続します
We expect that the gateway has a pool of IPv4 addresses and is always in the data-path of the packets. Transport between the gateway and phone devices is assumed to be an end-to-end layer-2 tunnel. We assume that the phone as well as gateway can be upgraded to support A+P. However, some applications running on the phone or devices behind the phone (such as laptop computers connecting via the phone) are not expected to be upgraded. Again, while we do not expect that devices behind the phone will be A+P-aware or upgraded, we also do not want to hinder their evolution. In this sense, the mobile phone would be comparable to the CPE in the broadband provider case; it would be the gateway to the PRR/LSN box in the network of the broadband provider.
私たちは、ゲートウェイは、IPv4アドレスのプールを持っており、パケットのデータ・パス内に常にあることを期待しています。ゲートウェイと電話装置との間の輸送は、エンドツーエンドのレイヤ2トンネルであると仮定されます。私たちは、携帯電話だけでなく、ゲートウェイが+ Pをサポートするようにアップグレードすることができることを前提としています。しかし、（例えば携帯電話を経由して接続するラップトップコンピュータなど）、電話の背後にある電話やデバイス上で実行されているいくつかのアプリケーションがアップグレードされることが予想されていません。我々は携帯電話の背後にあるデバイスは、+ P-対応またはアップグレードされることを期待していないながら、ここでも、我々はまた、彼らの進化を妨げたくありません。この意味では、携帯電話、ブロードバンドプロバイダ場合にCPEに匹敵するであろう。それは、ブロードバンドプロバイダのネットワーク内のPRR / LSNボックスへのゲートウェイであろう。
ISPs suffering from IPv4 address space exhaustion are interested in achieving a high address space compression ratio. In this respect, an A+P subsystem allows much more flexibility than traditional NATs: the NAT can be placed at the customer and/or in the provider network. In addition, hosts or applications can request ports and thus have untranslated end-to-end connectivity.
IPv4アドレス空間の枯渇に苦しんISPが高いアドレス空間の圧縮率を達成することに興味を持っています。この点で、A + P・サブシステムは、従来のNATよりもはるかに柔軟性を可能にする：NATは、顧客に及び/又はプロバイダネットワーク内に配置することができます。加えて、ホストまたはアプリケーションは、ポートを要求し、したがって、非翻訳エンドツーエンド接続を有することができます。
+---------------------------+
private | +------+ A+P-in +-----+ | dual-stacked
(RFC 1918) --|-| CPE |==-IPv6-==| PRR |-|-- network
space | +------+ tunnel +-----+ | (public addresses)
| ^ +-----+ |
| | IPv6-only | LSN | |
| | network +-----+ |
+----+----------------- ^ --+
| |
on customer within provider
premises and control network
Figure 12: A Simple A+P Subsystem Example
図12：簡単なA + Pサブシステムの例
Consider the deployment scenario in Figure 12, where an A+P subsystem is formed by the CPE and a PRR within the ISP core network and preferably is close to the customer edge. Inside the subsystem, packets are forwarded based on address and port. The provider MAY deploy an LSN co-located with the PRR to handle packets that have not been translated by the CPE. In such a configuration, the ISP allows the customer to freely decide whether the translation is done at the
A + Pサブシステムは、CPEとISPコアネットワーク内のPRRによって形成され、好ましくは、カスタマエッジに近接して、図12に配備シナリオを考えます。サブシステムの内部では、パケットがアドレスとポートに基づいて転送されます。プロバイダーは、CPEによって翻訳されていないパケットを処理するためのPRRと同じ場所に配置LSNを展開するかもしれません。このような構成では、ISPは、顧客が自由に翻訳がで行われているかどうかを決定することができます
CPE or at the LSN. In order to establish the A+P subsystem, the CPE will be configured automatically (e.g., via a signaling protocol that conforms to the requirements stated above).
CPEまたはLSNで。 A + Pサブシステムを確立するために、CPEが自動的に設定される（例えば、上述した要件に準拠したシグナリングプロトコルを介して）。
Note that the CPE in the example above is provisioned with only an IPv6 address on the external interface.
上記の例ではCPEは、外部インターフェイス上でのみIPv6アドレスがプロビジョニングされていることに留意されたいです。
+------------ IPv6-only transport ------------+
| +---------------+ | | |
| |A+P-application| | +--------+ | +-----+ | dual-stacked
| | on end-host |=|==| CPE w/ |==|==| PRR |-|-- network
| +---------------+ | +--------+ | +-----+ | (public addresses)
+---------------+ | +--------+ | +-----+ |
private IPv4 <-*--+->| NAT | | | LSN | |
address space \ | +--------+ | +-----+ |
for legacy +|--------------|----------+
hosts | |
| |
end-host with | CPE device | provider
upgraded | on customer | network
application | premises |
Figure 13: An Extended A+P Subsystem with End-Host Running A+P-Aware Applications
図13：+ P対応アプリケーションを実行するエンドホストと拡張A + Pサブシステム
Figure 13 shows an example of how an upgraded application running on a legacy end-host can connect to another host in the public realm. The legacy host is provisioned with a private IPv4 address allocated by the CPE. Any packet sent from the legacy host will be NATed either at the CPE (if configured to do so) or at the LSN (if available).
図13は、従来のエンドホスト上で実行されているアップグレードされたアプリケーションは、パブリック領域内の別のホストに接続する方法の例を示しています。レガシーホストはCPEによって割り当てられたプライベートIPv4アドレスがプロビジョニングされています。レガシーホストから送信されたパケットは、CPE（そうするように構成されている場合）で、またはLSN（利用可能な場合）のいずれかでNAT変換されます。
An A+P-aware application running on the end-host MAY use the signaling described in Section 3.3.1 to connect to the A+P subsystem. In this case, the application will be delegated some space in the A+P address realm, and will be able to contact the public realm (i.e., the public Internet) without the need for translation.
エンドホスト上で実行されているA + P対応のアプリケーションは、A + P・サブシステムに接続するには、セクション3.3.1で説明したシグナリングを使用するかもしれません。この場合、アプリケーションは、A + Pアドレス分野でいくつかの領域を委任され、翻訳を必要とせずにパブリック領域（すなわち、公衆インターネット）に接触することができるであろう。
Note that part of A+P signaling is that the NATs are optional. However, if neither the CPE nor the PRR provides NATing functionality, then it will not be possible to connect legacy end-hosts.
+ Pシグナリングの一部がNATのがオプションであることに注意してください。 CPEもPRRどちらもNAT変換機能を提供している場合しかし、従来のエンドホストを接続することはできません。
To enable packet forwarding with A+P, the ISP MUST install at its A+P border a PRR that encaps/decaps packets. However, to achieve a higher address space compression ratio and/or to support CPEs without NATing functionality, the ISP MAY decide to provide an LSN as well. If no LSN is installed in some part of the ISP's topology, all CPEs in that part of the topology MUST support NAT functionality. For reasons of scalability, it is assumed that the PRR is located within the access portion of the network. The CPE would be configured automatically (e.g., via an extended DHCP or NAT-PMP, which has the signaling requirements stated above) with the address of the PRR and of the LSN (if one is being provided). Figure 12 illustrates a possible deployment scenario.
A + Pとのパケット転送を可能にするために、ISPは、A + P境界でパケットをdecaps / ENCAPS PRRをインストールする必要があります。しかし、上位アドレス空間圧縮率を達成するために、および/またはNAT変換機能なしのCPEをサポートするために、ISPにもLSNを提供するように決定することができます。何のLSNがISPのトポロジの一部に設置されていない場合は、トポロジのその部分におけるすべてのCPEはNAT機能をサポートしなければなりません。スケーラビリティの理由から、PRRは、ネットワークのアクセス部分内に配置されているものとします。 （一方が提供されている場合）CPEは、PRRのアドレスを（例えば、拡張DHCPまたは上述のシグナリング要件がNAT-PMPを介して）及びLSNを自動的に設定されることになります。図12は、可能な配置シナリオを示します。
Allocating a fixed number of ports to all CPEs may lead to exhaustion of ports for high-usage customers. This is a perfect recipe for upsetting more demanding customers. On the other hand, allocating to all customers ports sufficiently to match the needs of peak users will not be very efficient. A mechanism for dynamic allocation of port ranges allows the ISP to achieve two goals: a more efficient compression ratio of the number of customers on one IPv4 address and, on the other hand, no limit of the more demanding customers' communication.
すべてのCPEへのポートの固定番号を割り当てると、使用頻度の高い顧客のためのポートの枯渇につながる可能性があります。これは、より厳しい顧客を動揺させるための完璧なレシピです。一方、十分にピークユーザーのニーズに合わせて、すべての顧客ポートに割り当てることが、非常に効率的ではありません。 1つのIPv4アドレスと、他方では、より厳しい顧客の通信の制限なしに顧客数のより効率的な圧縮比：ポート範囲の動的割り当てのための機構は、ISPは、2つの目標を達成することを可能にします。
Additional allocation of ports or port ranges may be made after an initial static allocation of ports.
ポートまたはポート範囲の追加の割り当ては、ポートの最初の静的割り当て後に行ってもよいです。
The mechanism would prefer allocations of port ranges from the same IP address as the initial allocation. If it is not possible to allocate an additional port range from the same IP, then the mechanism can allocate a port range from another IP within the same subnet. With every additional port range allocation, the PRR updates its routing table. The mechanism for allocating additional port ranges may be part of normal signaling that is used to authenticate the CPE to the ISP.
機構は、初期割り当てと同じIPアドレスからポート範囲の割り当てを好むだろう。それは、同じIPからの追加のポート範囲を割り当てることができない場合、機構は、同じサブネット内の他のIPからのポート範囲を割り当てることができます。すべての追加のポート範囲の割り当てでは、PRRは、そのルーティングテーブルを更新します。付加的なポート範囲を割り当てるためのメカニズムは、ISPにCPEを認証するために使用され、通常のシグナリングの一部であってもよいです。
The ISP controls the dynamic allocation of port ranges by the PRR by setting the initial allocation size and maximum number of allocations per CPE, or the maximum allocations per subscription, depending on subscription level. There is a general observation that the more demanding customer uses around 1024 ports when heavily communicating. So, for example, a first suggestion might be 128 ports initially and then dynamic allocations of ranges of 128 ports up to 511 more allocations maximum. A configured maximum number of allocations could be used to prevent one customer acting in a destructive manner should they become infected. The maximum number of allocations might also be more finely grained, with parameters of how many allocations a user may request per some time frame. If this is used, evasive applications may need to be limited in their bad behavior; for example, one additional allocation per minute would considerably slow a port request storm.
ISPは、サブスクリプションレベルに応じて、初期割り当てサイズとCPEごとの割り当ての最大数、またはサブスクリプションあたりの最大割り当てを設定することにより、PRRによってポート範囲の動的割り当てを制御します。頻繁に通信するときに、より厳しい顧客が1024ポートの周りに使用する一般的な観察があります。したがって、例えば、最初の提案は、128の最初にポート511より配分最大に最大128ポートの範囲の、動的割り当てかもしれません。彼らは、感染になるべき割り当ての設定された最大数は破壊的に作用する一人の顧客を防ぐために使用することができます。割り当ての最大数は、より細かく粒状、ユーザがある時間フレームごと要求することができるどのように多くの割り当てのパラメータを持つかもしれません。これを使用する場合は、回避アプリケーションは、彼らの悪い行動に制限する必要があるかもしれません。例えば、1分間に1つの追加の割り当てはかなりポート要求の嵐を遅らせるだろう。
There is likely no minimum request size. This is because A+P-aware applications running on end-hosts MAY request a single port (or a few ports) for the CPE to be contacted on (e.g., Voice over IP (VoIP) clients register a public IP and a single delegated port from the CPE, and accept incoming calls on that port). The implementation on the CPE or PRR will dictate how to handle such requests for smaller blocks: for example, half of available blocks might be used for "block-allocations", 1/6 for single port requests, and the rest for NATing.
最低要求サイズはおそらくありません。エンドホスト上で実行されているA + P対応のアプリケーションは、単一のポート（またはいくつかのポート）を要求することができるので、CPE（例えば、ボイスオーバーIP（VoIP）のクライアントに接触させるためにこれがあるパブリックIPを登録し、単一委譲CPEからのポート、およびそのポート上の着信コールを受け入れます）。 CPEまたはPRRの実装は、より小さなブロックのために、このような要求を処理する方法を指示します：例えば、使用可能なブロックの半分は「ブロックの割り当て」、シングルポートの要求のための1/6、およびNAT変換のための休息のために使用される可能性があります。
Another possible mechanism to allocate additional ports is UPnP/ NAT-PMP (as defined in Section 3.3.1), if applications behind CPE support it. In the case of the LSN implementation (DS-Lite), as described in Section 3.3.4 about the A+P overall architecture, signaling packets are simply forwarded by the CPE to the LSN and back to the host running the application that requested the ports, and the PRR allocates the requested port to the appropriate CPE. The same behavior may be chosen with AFTR, if requested ports are outside of the static initial port allocation. If a full A+P implementation is selected, then UPnPv2/NAT-PMP packets are accepted by the CPE, processed, and the requested port number is communicated through the normal signaling mechanism between CPE and PRR tunnel endpoints (PCP).
追加のポートを割り当てるための別の可能なメカニズムは、UPnPの/ NAT-PMP（セクション3.3.1で定義されている）である場合CPEサポートその背後にあるアプリケーション。 A + P全体的なアーキテクチャに関するセクション3.3.4に記載したようにLSN実装（DS-ライト）の場合には、シグナリングパケットは、単に要求されたアプリケーションを実行するホストに戻すLSNにCPEによって転送されますポート、およびPRRは、適切なCPEに要求されたポートを割り当てます。要求されたポートが静的初期ポート割り当ての外にある場合、同じ現象が、AFTRで選択することができます。フルA + Pの実装が選択された場合、UPnPv2 / NAT-PMPパケットは、CPEによって受け入れ処理し、要求されたポート番号は、CPEとPRRトンネルエンドポイント（PCP）との間の正常なシグナル伝達機構を介して通信されます。
This section provides a detailed example of A+P setup, configuration, and packet flow from an end-host connected to an A+P service provider to any host in the IPv4 Internet, and how the return packets flow back. The following example discusses an A+P-unaware end-host, where the NATing is done at the CPE. Figure 14 illustrates how the CPE receives an IPv4 packet from the end-user device. We first describe the case where the CPE has been configured to provide the NAT functionality (e.g., by the customer through interaction with a website or by automatic signaling). In the following, we call a packet that is translated at the CPE an "A+P-forwarded packet", an analogy with the port-forwarding function employed in today's CPEs. Upon receiving a packet from the internal interface, the CPE translates, encapsulates, and forwards it to the PRR. The NAT on the CPE is assumed to have a default route to the public realm through its tunnel interface.
このセクションでは、IPv4インターネットの任意のホストにA + P・サービス・プロバイダに接続されたエンドホストからA + Pのセットアップ、構成、およびパケットフローの詳細な例を提供し、どのようにリターンパケットが逆流します。次の例では、NAT変換をCPEで行われるA + P-気づかないエンドホストを論じています。図14は、CPEは、エンドユーザデバイスからIPv4パケットを受信する方法を示します。まずCPEはNAT機能を提供するように構成されている場合について説明（例えば、ウェブサイトとの相互作用を介して、顧客による自動シグナリングによって）。以下では、CPE、「A + P-転送されたパケット」、今日のCPEに採用ポートフォワーディング機能とのアナロジーで換算されたパケットを呼び出します。内部インタフェースからパケットを受信すると、CPEは、翻訳カプセル化、及びPRRに転送します。 CPE上のNATは、そのトンネルインターフェースを介して公共分野へのデフォルトルートを持っていると仮定されます。
When the PRR receives the A+P-forwarded packet, it decapsulates the inner IPv4 packet and checks the source address. If the source address does match the range assigned to A+P-enabled CPEs, then the PRR simply forwards the decapsulated packet onward. This is always the case for A+P-forwarded packets. Otherwise, the PRR assumes that the packet is not A+P-forwarded and passes it to the LSN function, which in turn translates and forwards the packet based on the destination address. Figure 14 shows the packet flow for an outgoing A+P-forwarded packet.
PRRは、A + P-転送されたパケットを受信すると、内側のIPv4パケットをデカプセル化し、ソースアドレスをチェックします。送信元アドレスが+ P対応のCPEに割り当てられた範囲に一致しない場合、PRRは単に以降デカプセル化パケットを転送します。これは、常にA + P-転送されるパケットの場合です。そうでない場合、PRRは、パケットが+ P-転送ではなく、順番に変換し、宛先アドレスに基づいてパケットを転送LSN関数に渡すことを想定しています。図14は、発信A + P-転送されたパケットのパケットフローを示しています。
+-----------+
| Host |
+-----+-----+
| | 198.51.100.2
IPv4 datagram 1 | |
| |
v | 198.51.100.1
+---------|---------+
|CPE | |
+--------|||--------+
| ||| 2001:db8::2
| ||| 192.0.2.3 (100-200)
IPv6 datagram 2| |||
| |||<-IPv4-in-IPv6
| |||
-----|-|||-------
/ | ||| \
| ISP access network |
\ | ||| /
-----|-|||-------
| |||
v ||| 2001:db8::1
+--------|||--------+
|PRR ||| |
+---------|---------+
| | 192.0.2.1
IPv4 datagram 3 | |
-----|--|--------
/ | | \
| ISP network / |
\ Internet /
-----|--|--------
| |
v | 203.0.113.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 14: Forwarding of Outgoing A+P-Forwarded Packets
図14：発信A + P-転送されたパケットの転送
+-----------------+--------------+-----------------------------+
| Datagram | Header field | Contents |
+-----------------+--------------+-----------------------------+
| IPv4 datagram 1 | IPv4 Dst | 203.0.113.1 |
| | IPv4 Src | 198.51.100.2 |
| | TCP Dst | 80 |
| | TCP Src | 8000 |
| --------------- | ------------ | --------------------------- |
| IPv6 datagram 2 | IPv6 Dst | 2001:db8::1 |
| | IPv6 Src | 2001:db8::2 |
| | IPv4 Dst | 203.0.113.1 |
| | IPv4 Src | 192.0.2.3 |
| | TCP Dst | 80 |
| | TCP Src | 100 |
| --------------- | ------------ | --------------------------- |
| IPv4 datagram 3 | IPv4 Dst | 203.0.113.1 |
| | IPv4 Src | 192.0.2.3 |
| | TCP Dst | 80 |
| | TCP Src | 100 |
+-----------------+--------------+-----------------------------+
Datagram Header Contents
データグラムヘッダーの内容
An incoming packet undergoes the reverse process. When the PRR receives an IPv4 packet on an external interface, it first checks whether or not the destination address falls within the A+P CPE delegated range. If the address space was delegated, then the PRR encapsulates the incoming packet and forwards it through the appropriate tunnel for that IP/port range. If the address space was not delegated, the packet would be handed to the LSN to check if a mapping is available.
着信パケットは、逆のプロセスを経ます。 PRRは、外部インターフェイス上でIPv4パケットを受信すると、宛先アドレスがA + PのCPE委任範囲内で最初か否かを確認します。アドレス空間が委任された場合、PRRは、着信パケットをカプセル化し、そのIP /ポート範囲の適切なトンネルを介して転送します。アドレス空間が委任されていなかった場合、パケットは、マッピングが利用可能であるかどうかを確認するLSNに渡されることになります。
Figure 15 shows how an incoming packet is forwarded, under the assumption that the port number matches the port range that was delegated to the CPE.
図15は、着信パケットが、ポート番号がCPEに委任されたポート範囲と一致するという仮定の下で、転送される様子を示しています。
+-----------+
| Host |
+-----+-----+
^ | 198.51.100.2
IPv4 datagram 3 | |
| |
| | 198.51.100.1
+---------|---------+
|CPE | |
+--------|||--------+
^ ||| 2001:db8::2
| ||| 192.0.2.3 (100-200)
IPv6 datagram 2| |||
| |||<-IPv4-in-IPv6
| |||
-----|-|||-------
/ | ||| \
| ISP access network |
\ | ||| /
-----|-|||-------
| |||
| ||| 2001:db8::1
+--------|||--------+
|PRR ||| |
+---------|---------+
^ | 192.0.2.1
IPv4 datagram 1 | |
-----|--|--------
/ | | \
| ISP network / |
\ Internet /
-----|--|--------
| |
| | 203.0.113.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 15: Forwarding of Incoming A+P-Forwarded Packets
図15：着信A + P-転送されたパケットの転送
+-----------------+--------------+-----------------------------+
| Datagram | Header field | Contents |
+-----------------+--------------+-----------------------------+
| IPv4 datagram 1 | IPv4 Dst | 198.51.100.3 |
| | IPv4 Src | 203.0.113.1 |
| | TCP Dst | 100 |
| | TCP Src | 80 |
| --------------- | ------------ | --------------------------- |
| IPv6 datagram 2 | IPv6 Dst | 2001:db8::2 |
| | IPv6 Src | 2001:db8::1 |
| | IPv4 Dst | 198.51.100.3 |
| | IP Src | 203.0.113.1 |
| | TCP Dst | 100 |
| | TCP Src | 80 |
| --------------- | ------------ | --------------------------- |
| IPv4 datagram 3 | IPv4 Dst | 198.51.100.2 |
| | IPv4 Src | 203.0.113.1 |
| | TCP Dst | 8000 |
| | TCP Src | 80 |
+-----------------+--------------+-----------------------------+
Datagram Header Contents
データグラムヘッダーの内容
Note that datagram 1 travels untranslated up to the CPE; thus, the customer has the same control over the translation as he has today -- a home gateway with customizable port-forwarding.
CPEまでの1つの走行非翻訳そのデータグラムを注意してください。カスタマイズ可能なポートフォワーディングとホームゲートウェイ - このように、顧客は、彼が今日持っていると翻訳の上に同じコントロールを持っています。
Packets for which the CPE does not have a corresponding port-forwarding rule are tunneled to the PRR that provides the LSN function. We underline that the LSN MUST NOT use the delegated space for NATing. See [RFC6333] for network diagrams that illustrate the packet flow in this case.
CPEは、対応するポート転送ルールを持たないためにパケットはLSN機能を提供PRRにトンネリングされています。私たちは、LSNは、NAT変換のための委任のスペースを使用してはならないことを強調しています。この場合のパケットの流れを示すネットワーク図のために[RFC6333]を参照。
ICMP is problematic for all NATs because it lacks port numbers. A+P routing exacerbates the problem.
それはポート番号がないため、ICMPはすべてのNATのための問題があります。 + Pルーティング問題を悪化させます。
Most ICMP messages fall into one of two categories: error reports or ECHO/ECHO replies (commonly known as "pings"). For error reports, the offending packet header is embedded within the ICMP packet; NAT devices can then rewrite that portion and route the packet to the actual destination host. This functionality will remain the same with A+P; however, the PRR will need to examine the embedded header to extract the port number, while the A+P gateway will do the necessary rewriting.
エラーレポートや（一般に「ピング」として知られている）ECHO / ECHO回答：ほとんどのICMPメッセージは、2つのカテゴリに分類されます。エラーレポートのために、問題のパケットヘッダは、ICMPパケット内に埋め込まれています。 NATデバイスは、実際の宛先ホストにその部分とルートパケットを書き換えることができます。この機能は、A + Pと同じままになります。 A + Pゲートウェイが必要な書き換えを行いますながらしかし、PRRは、ポート番号を抽出するために埋め込まれたヘッダを検査する必要があります。
ECHO and ECHO replies are more problematic. For ECHO, the A+P gateway device must rewrite the "Identifier" and perhaps "Sequence Number" fields in the ICMP request, treating them as if they were port numbers. This way, the PRR can build the correct A+P address for the returning ECHO replies, so they can be correctly routed back to the appropriate host in the same way as TCP/UDP packets. Pings originated from the public realm (Internet) towards an A+P device are not supported.
ECHO ECHOと回答は、より多くの問題があります。 ECHOため、A + Pゲートウェイ装置は、それらがポート番号であるかのようにそれらを処理する、ICMP要求におそらく「識別子」と「シーケンス番号」フィールドを書き換えなければなりません。このように、PRRは戻ってエコー応答のための正しいA + Pアドレスを構築することができますので、彼らは正しくTCP / UDPパケットと同じように戻って適切なホストにルーティングすることができます。 pingがサポートされていないA + P装置に向かって公共領域（インターネット）に由来します。
In order to deliver a fragmented IP packet to its final destination (among those having the same IP address), the PRR should activate a dedicated procedure similar to the one used by [RFC6146], Section 3.5, in the sense that it should reassemble the fragments in order to look at the destination port number.
（同じIPアドレスを有するものの中で）、その最終的な宛先に断片化されたIPパケットを配信するために、PRRは、それが再構築すべきであるという意味で、[RFC6146]で使用されるものと同様の専用の手順は、セクション3.5を活性化すべきです宛先ポート番号を調べるために、断片。
Note that it is recommended to use a Path MTU Discovery (PMTUD) mechanism (e.g., [RFC1191]).
パスMTUディスカバリ（PMTUD）メカニズムを使用することが推奨されることに留意されたい（例えば、[RFC1191]）。
Security issues related to fragmentation are out of scope of this document. For more details, refer to [RFC1858].
断片化に関連したセキュリティ問題はこの文書の範囲外です。詳細については、[RFC1858]を参照してください。
One limitation that A+P shares with any other IP-address-sharing mechanism is the availability of well-known ports. In fact, services run by customers that share the same IP address will be distinguished by the port number. As a consequence, it will be impossible for two customers who share the same IP address to run services on the same port (e.g., port 80). Unfortunately, working around this limitation usually implies application-specific hacks (e.g., HTTP and HTTPS redirection), discussion of which is out of the scope of this document. Of course, a provider might charge more for giving a customer the well-known port range, 0..1024, thus allowing the customer to provide externally available services. Many applications require the availability of well-known ports. However, those applications are not expected to work in an A+P environment unless they can adapt to work with different ports. Such applications do not work behind today's NATs either.
他のIPアドレスを共有する機構を有するA + P株式1つの制限は、既知のポートの利用可能性です。実際には、同じIPアドレスを共有する顧客が実行されるサービスは、ポート番号で区別されます。その結果、それは同じポート（例えば、ポート80）上でサービスを実行するために、同じIPアドレスを共有する2人の顧客のために不可能になります。残念ながら、この制限を回避作業は、通常はこの文書の範囲外で議論そのアプリケーション固有のハック（例えば、HTTPおよびHTTPSリダイレクト）を、意味しています。もちろん、プロバイダは、このように、顧客によく知られたポート範囲、0..1024を与え、顧客が外部から利用可能なサービスを提供することを可能にするためのより多く課金することがあります。多くのアプリケーションは、well-knownポートの可用性を必要とします。しかし、これらのアプリケーションは、それらが異なるポートで動作するように適応することができない限り、A + P環境で動作することが期待されていません。このようなアプリケーションは、いずれかの今日のNATの背後に動作しません。
Another problem that is common to all NATs is coexistence with IPsec. In fact, a NAT that also translates port numbers prevents the Authentication Header (AH) and Encapsulating Security Payload (ESP) from functioning properly, both in tunnel and in transport mode. In this respect, we stress that, since an A+P subsystem exhibits the same external behavior as a NAT, well-known workarounds (such as [RFC3715]) can be employed.
すべてのNATに共通するもう一つの問題は、IPsecとの共存です。実際には、また、ポート番号を変換するNATは、トンネルおよびトランスポートモードの両方で、適切に機能から認証ヘッダ（AH）とカプセル化セキュリティペイロード（ESP）を防止します。この点で、我々は、A + Pサブシステムは、NATと同じ外部挙動を示すので、ことを強調（例えば、[RFC3715]など）は、周知の回避策を使用することができます。
A+P, as all other port-sharing solutions, suffers from the issues documented in [RFC6269], but that's something we'll have to live with.
+ Pは、他のすべてのポートを共有するソリューションとして、[RFC6269]で文書化の問題に苦しんでいるが、それは私たちが一緒に暮らす必要があります何か。
For the host-based A+P, issues related to application conflicts when trying to bind to an out-of-range port are to be further assessed. Note that extensions to the host-based model have been proposed in the past (e.g., the Port-Enhanced Address Resolution Protocol (ARP) extension documented in http://software.merit.edu/pe-arp/).
ホストベースのA + Pについては、範囲外のポートにバインドしようとしたときに、アプリケーションの競合に関連する問題は、さらに評価されるべきです。ホストベースのモデルへの拡張機能が過去に提案されていることに注意してください（例えば、ポートの拡張アドレス解決プロトコルhttp://software.merit.edu/pe-arp/に文書（ARP）拡張子）。
Issues raised by [PR-IP-ISSUES] have been analyzed in [STATELESS-4v6]. As seen in that document, most of the issues apply to host-based port-sharing solutions. A+P is not intended to be a host-based port-sharing solution.
[PR-IP-ISSUES]が提起した問題は、[STATELESS-4v6]で分析されています。その文書に見られるように、問題のほとんどは、ために、ホストベースのポート共有ソリューションを適用します。 + Pは、ホストベースのポート共有ソリューションであることが意図されていません。
The conclusion of [STATELESS-4v6] is that the set of issues specifically attributed to A+P either do not apply to CPE-based flavors or can be mitigated. The A+P solution represents a reasonable trade-off compared to alternatives in areas such as binding logging (for data storage purposes) and ease of deployment and operations, all of which are actually facilitated by such a solution.
[STATELESS-4v6]の結論は、具体的にはA + Pに起因する問題のセットのいずれかCPEベースの風味には適用されない、または軽減することができることです。 A + P溶液は、実際にはそのような溶液によって促進されるすべてが（データ記憶のために）そのような結合ロギングなどの分野での代替と展開と操作の容易さ、に比べ合理的なトレードオフを表します。
With CGNs/LSNs, tracing hackers, spammers, and other criminals will be difficult, requiring logging, recording, and storing of all connection-based mapping information. The need for storage implies a trade-off. On one hand, the LSNs can manage addresses and ports as dynamically as possible in order to maximize aggregation. On the other hand, the more quickly the mapping between private and public space changes, the more information needs to be recorded. This would cause concern not only for law enforcement services, but also for privacy advocates.
CGNを/のLSNと、トレースハッカー、スパマー、および他の犯罪者は、すべての接続ベースのマッピング情報のログ記録、および記憶を必要とすることは困難であろう。ストレージの必要性はトレードオフを意味します。一方では、のLSNは、凝集を最大にするためになど、動的に可能な限りのアドレスとポートを管理することができます。一方、プライベートとパブリックスペースの変化との間に、より迅速にマッピングは、より多くの情報を記録する必要があります。これは、法執行機関のサービスのため、だけでなく、プライバシー擁護派のためだけでなく、懸念を引き起こします。
A+P offers a better set of trade-offs. All that needs to be logged is the allocation of a range of port numbers to a customer. By design, this will be done rarely, improving scalability. If the NAT functionality is moved further up the tree, the logging requirement will be as well, increasing the load on one node, but giving it more resources to allocate to a busy customer, perhaps decreasing the frequency of allocation requests.
+ Pはトレードオフの優れたセットを提供しています。ログに記録する必要があるすべては、顧客へのポート番号の範囲を割り当てています。設計では、これは、スケーラビリティの向上、めったに行われません。 NAT機能がさらにツリー上に移動されている場合は、ログの要件は、おそらく割り当て要求の頻度を減らす、1つのノードの負荷を増大させるが、多忙な顧客に割り当てるためにそれをより多くのリソースを与え、同様になります。
The other extreme is A+P NAT on the customer premises. Such a node would be no different than today's NAT boxes, which do no such logging. We thus conclude that A+P is no worse than today's situation, while being considerably better than CGNs.
他の極端では、顧客の敷地内に+ P NATです。このようなノードには、そのようなロギングを行いません今日のNAT箱、の違いはなくなります。そこで我々は、CGNをよりかなり良好でありながら、A + Pは、今日の状況よりも悪化していないと結論付けています。
The authors wish to especially thank Remi Despres and Pierre Levis for their help on the development of the A+P approach. We also thank David Ward for review, constructive criticism, and interminable questions, and Dave Thaler for useful criticism on "stackable" A+P gateways. We would also like to thank the following persons for their feedback on earlier versions of this work: Rob Austein, Gert Doering, Dino Farinacci, Russ Housley, Ruediger Volk, Tina Tsou, and Pasi Sarolahti.
著者は、特にA + Pアプローチの開発に彼らの助けのためのレミ・デプレとピエール・リーバイスに感謝したいです。我々はまた、「スタッカブル」A + Pゲートウェイ上の便利な批判のために見直し、建設的な批判、そして果てしない質問のためのデビッド・ウォード、とDaveターラーに感謝します。ロブAusteinと、ゲルトDoering、ディノファリナッチ、ラスHousley、Ruedigerボルク、ティナツオウ、およびパシSarolahti：我々はまた、この作品の以前のバージョンでの彼らのフィードバックのために、次の人に感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[4rd] Despres, R., Matsushima, S., Murakami, T., and O. Troan, "IPv4 Residual Deployment across IPv6-Service networks (4rd) ISP-NAT's made optional", Work in Progress, March 2011.
[4RD]デプレ、R.、松島、S.、村上、T.、およびO. Troan、進歩、2011年3月に、仕事の "IPv6-サービスネットワーク（4RD）ISP-NATの作られたオプションの間でIPv4の残留展開"。
[A+P-EXPERIMENTS] Deng, X., Boucadair, M., and F. Telecom, "Implementing A+P in the provider's IPv6-only network", Work in Progress, March 2011.
[A + P-実験]鄧小平、X.、Boucadair、M.、およびF.テレコム、 "プロバイダのIPv6のみのネットワークで実装A + P"、進歩、2011年3月に作業。
[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[BCP38]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス妨害Attacksを破り"、BCP 38、RFC 2827、2000年5月。
[BITTORRENT-ADDR-SHARING] Boucadair, M., Grimault, J., Levis, P., and A. Villefranque, "Behavior of BitTorrent service in an IP Shared Address Environment", Work in Progress, March 2011.
[BitTorrentの-ADDR共有] Boucadair、M.、グリモー、J.、リーバイス、P.、およびA. Villefranque、 "IP共有アドレス環境でのBitTorrentのサービスの動作"、進歩、2011年3月に作業。
[PCP-BASE] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", Work in Progress, July 2011.
[PCP-BASE]ウイング、D.、チェシャー、S.、Boucadair、M.、Penno、R.、およびP.セルカーク、 "ポート制御プロトコル（PCP）"、進歩、2011年7月での作業。
[PORT-RANGE-OPT] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and T. ZOU), "Huawei Port Range Configuration Options for PPP IPCP", Work in Progress, June 2011.
[PORT-RANGE-OPT] Boucadair、M.、リーバイス、P.、Bajko、G.、Savolainenの、T.、およびT. ZOU）、 "PPP IPCPのために華為ポート範囲の設定オプション"、進歩、2011年6月での作業。
[PR-ADDR-ASSIGN] Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, "Port Restricted IP Address Assignment", Work in Progress, September 2010.
[PR-ADDR-ASSIGN] Bajko、G.、Savolainenの、T.、Boucadair、M.、およびP.リーバイス、 "ポート制限付きIPアドレスの割り当て"、進歩、2010年9月での作業。
[PR-IP-ISSUES] Thaler, D., "Issues With Port-Restricted IP Addresses", Work in Progress, February 2010.
[PR-IP-ISSUES]ターラー、D.、 "ポート制限付きIPアドレスを持つ問題"、進歩、2010年2月での作業。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995.
[RFC1858] Ziemba、G.、リード、D.、およびP. Trainaの、 "IPフラグメントフィルタリングのためのセキュリティの考慮事項"、RFC 1858、1995年10月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715] Aboba、B.とW.ディクソン、 "IPsecでネットワークアドレス変換（NAT）の互換性の要件"、RFC 3715、2004年3月。
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, January 2010.
[RFC5737] Arkko、J.、綿、M.、およびL. Vegoda、 "ドキュメントのために予約されたIPv4アドレスブロック"、RFC 5737、2010年1月。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.
[RFC6052]バオ、C.、のHuitema、C.、Bagnulo、M.、Boucadair、M.、およびX.李、RFC 6052、2010年10月の "IPv6は、IPv4 / IPv6の翻訳者のアドレス指定"。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146] Bagnulo、M.、マシューズ、P.、およびI.バンBeijnum、 "ステートフルNAT64：IPv4のサーバーへのIPv6クライアントからのネットワークアドレスとプロトコル変換"、RFC 6146、2011年4月。
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
[RFC6269]フォード、M.、Boucadair、M.、デュラン、A.、リーバイス、P.、およびP.ロバーツ、RFC 6269、2011年6月、 "IPアドレスの共有に関する問題"。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.
[RFC6333]デュラン、A.、Droms、R.、Woodyatt、J.、およびY.リー、 "IPv4の枯渇後デュアルスタックLiteのブロードバンドの展開"、RFC 6333、2011年8月。
[SHARED-ADDR-OPT] Boucadair, M., Levis, P., Grimault, J., Savolainen, T., and G. Bajko, "Dynamic Host Configuration Protocol (DHCPv6) Options for Shared IP Addresses Solutions", Work in Progress, December 2009.
[共有ADDR-OPT] Boucadair、M.、リーバイス、P.、グリモー、J.、Savolainenの、T.、およびG. Bajkoは、作業中の "共有IPのための動的ホスト構成プロトコル（DHCPv6）オプションソリューションアドレス"進歩、2009年12月。
[STATELESS-4v6] Dec, W., Asati, R., Bao, C., and H. Deng, "Stateless 4Via6 Address Sharing", Work in Progress, July 2011.
[STATELESS-4v6] 12月、W.、Asati、R.、バオ、C.、およびH.鄧小、 "ステートレス4Via6アドレスの共有"、進歩、2011年7月での作業。
This document has nine primary authors.
この文書では、9本の主な著者を持っています。
Gabor Bajko Nokia EMail: gabor.bajko@nokia.com
ガボールBajkoノキアEメール：gabor.bajko@nokia.com
Mohamed Boucadair France Telecom 3, Av Francois Chateaux Rennes 35000 France EMail: mohamed.boucadair@orange-ftgroup.co
モハメド・Boucadairフランステレコム3のAvフランソワ・シャトー35000レンヌフランスEメール：mohamed.boucadair@orange-ftgroup.co
Steven M. Bellovin Columbia University 1214 Amsterdam Avenue MC 0401 New York, NY 10027 US Phone: +1 212 939 7149 EMail: bellovin@acm.org
スティーブンM. Bellovin氏コロンビア大学1214アムステルダムアベニューMC 0401ニューヨーク、NY 10027米国電話：+1 212 939 7149 Eメール：bellovin@acm.org
Randy Bush Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, Washington 98110 US Phone: +1 206 780 0431 x1 EMail: randy@psg.com
ランディブッシュインターネットイニシアティブ5147クリスタルスプリングスベインブリッジ島、ワシントン98110米国電話：+1 206 780 0431×1 Eメール：randy@psg.com
Luca Cittadini Universita' Roma Tre via della Vasca Navale, 79 Rome, 00146 Italy Phone: +39 06 5733 3215 EMail: luca.cittadini@gmail.com
ルカCittadini Universita「ローマトレ経由デッラ・バスカNavale、79ローマ、00146イタリア電話：+39 06 5733 3215 Eメール：luca.cittadini@gmail.com
Olaf Maennel Loughborough University Department of Computer Science - N.2.03 Loughborough United Kingdom Phone: +44 115 714 0042 EMail: o@maennel.net
コンピュータサイエンスのオラフMaennelラフバラ大学学部 - N.2.03ラフバライギリス電話：+44 115 714 0042 Eメール：o@maennel.net
Reinaldo Penno Juniper Networks 1194 North Mathilda Avenue Sunnyvale, California 94089 US EMail: rpenno@juniper.net
レイナルドPennoジュニパーネットワークスの1194北マチルダアベニューサニーベール、カリフォルニア州94089米国メールアドレス：rpenno@juniper.net
Teemu Savolainen Nokia Hermiankatu 12 D TAMPERE, FI-33720 Finland EMail: teemu.savolainen@nokia.com
テームSavolainenのノキアHermiankatu 12 D TAMPERE、フィンランドFI-33720 Eメール：teemu.savolainen@nokia.com
Jan Zorz Go6 Institute Slovenia Frankovo naselje 165 Skofja Loka, 4220 Slovenia EMail: jan@go6.si
ヤンZorz Go6研究所スロベニアフランク・リゾート165シュコーフィア・ロカ、スロベニア4220 Eメール：jan@go6.si
Editor's Address
編集者の住所
Randy Bush (editor) Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, Washington 98110 US
ランディブッシュ（エディタ）インターネットイニシアティブ5147クリスタルスプリングスベインブリッジ島、ワシントン98110米国
Phone: +1 206 780 0431 x1 EMail: randy@psg.com
電話：+1 206 780 0431 x1メール：randy@psg.com