[要約] RFC 6346は、IPv4アドレス不足に対するアドレスプラスポート（A+P）アプローチについての要約です。このRFCの目的は、IPv4アドレスの効率的な利用と、アドレス不足の問題を解決するための新しいアドレス割り当て手法を提案することです。
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
IPv4アドレス不足へのアドレスプラスポート（A P）アプローチ
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アドレス共有スキームを提案し、ポート番号ビットの一部を拡張IPv4アドレス（アドレスプラスポート、またはA）の一部として扱います。単一のIPv4アドレスを単一の顧客デバイスに割り当てる代わりに、TCP/UDPヘッダーのポート番号範囲のビットを追加エンドポイント識別子として使用して、アドレスフィールドを拡張することを提案します。これは、同じIPv4アドレスを複数のクライアント（例：Customer Premises Equipment（CPE）、携帯電話）に割り当てることを意味し、それぞれにポート範囲が割り当てられています。IPv4アドレスの疲労に直面して、アドレスの必要性は、単一のホストで何千ものアプリケーションに対処できる必要性よりも強くなります。アドレス変換が必要な場合、エンドユーザーは翻訳プロセスを制御する必要があります - コア内のいくつかのスマートボックスではありません。
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.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6346.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 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未満のビットに制限できると仮定すると、最大16の追加ビットを残すことでIPv4アドレスの有効サイズを増やすことができます。このシナリオでは、1〜65536の顧客をマルチプレックスすることができます。同じIPv4アドレスが、1〜65536ポートの固定またはダイナミックレンジを可能にします。たとえば、顧客は、オペレーターによって定義された初期の固定ポート範囲を受け取り、契約に応じて追加のブロックを動的にリクエストすることができます。これを「拡張アドレス指定」または「A P」（アドレスプラスポート）アドレス指定と呼びます。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.
IPv4インターネットのさまざまなレベルと場所でさまざまな形式のNATがインストールされ、アドレス圧縮を実現します。このドキュメントでは、これが可能な限りネットワークの端に近づいているメカニズムについて主張し、それによりエンドツーエンドの原則への損傷を最小限に抑え、エンドカスタマーがアドレスとポートの翻訳を制御できるようにします。したがって、該当する場合は、コアに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を調整するだけで、または特定のアルグをサポートする新しいバージョンにアップグレードすることにより、同意のエンドポイント間に新しいアプリケーションを簡単に展開できます。
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ベース]を使用した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のもう1つの問題は、セッション状態とネットワーク配置の間のトレードオフです。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.
A 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.
A 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アドレスを翻訳する必要があるIPv4アドレスをプライベートアドレスと見なします。
Port-Range Router (PRR): A device that forwards A+P packets.
Port-Range Router（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.
プロバイダーBorder Router（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.
5) 「double-nat」は避ける必要があります。複数のゲートウェイデバイスがパスに存在する可能性があり、1つが翻訳を行ったら、それらのパケットを再刻むべきではありません。
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はそれほど問題をもたらさないのに対し、プロバイダーのNatsは追加のログを維持する必要があると仮定します。
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.
A Pアーキテクチャは、Encaps/Decaps、NAT、Signalingの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関数：中間レガシーデバイス上のPパケットをポート制限するポート制限に使用します。カプセル化関数はIPv4パケットを取り、IPとTCP/UDPヘッダーを検索し、適切なトンネルにパケットを入れます。このアクションを実行するために必要な状態は、転送テーブルに匹敵します。脱カプセル化デバイスは、トンネルから出てくるパケットのソースアドレスとポートが正当であるかどうかを確認する必要があります（例：[BCP38]を参照）。このようなチェックの結果に基づいて、パケットは翻訳されずに転送されたり、破棄されたり、ネートされたりする場合があります。このドキュメントでは、このカップ/Decaps機能をポートレンジルーター（PRR）として提供するデバイスを参照します。
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,
ネットワークアドレス変換（NAT）関数：レガシーエンドホストを接続するために使用されます。アップグレードされていない限り、エンドホストまたはエンドシステムはPの制限を認識していないため、完全なIPアドレスを想定しています。NAT関数は、必要に応じてアプリケーションレベルゲートウェイ（ALG）を含むアドレスまたはポート翻訳を実行します。この関数を実装するために保持する必要がある状態は、現在のCPESがNATを埋め込んでいるように、内部アドレスとポートに外部アドレスとポートがマッピングされたマッピングです。微妙な、
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を「バイパス」することを選択する場合があります。これが行われた場合、NATを大規模なNAT（LSN）と呼びます。ただし、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.
シグナリング関数：P-Awareデバイスが、どのポートが翻訳されずに渡されるか、割り当てられたポート範囲外のパケットに何が起こるかを知ることができるようにするために使用されます（例えば、ネートまたは破棄することができます）。シグナリングは、カプセル化方法と必要なエンドポイント情報を学習するためにも使用できます。さらに、信号関数を使用して、要求されたポート範囲を動的に割り当てることができます。
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.
上記のように、A Pソリューションのコアアーキテクチャ要素は、NAT関数、cancaps/decaps関数、およびシグナル伝達関数の3つの分離関数と独立した関数です。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トンネル、または他の形式のソフトワイヤーである可能性があります。トンネルの存在により、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.
可能な限り最も単純なPサブシステム、つまり、capaps/decaps関数を提供する2つのデバイスを描写します。
+------------------------------------+
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サブシステム内では、パケットを転送するときにポート番号のビットを使用して、パブリックアドレスの領域が拡張されます。各デバイスには、外部領域から1つのアドレスとポート番号の範囲が割り当てられます。したがって、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]、[Shared-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],
o ポートランダム化におけるエントロピーの部分的または完全な保存を可能にするオプションのキー - [PR-ADDR-ASSIGN]を参照してください。
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 使用するトンネリング技術（例：「IPv6-capsulation」）、
o addresses of the tunnel endpoints (e.g., IPv6 address of tunnel endpoints),
o トンネルエンドポイントのアドレス（例：トンネルエンドポイントのIPv6アドレス）、
o whether or not NAT function is provided by the gateway,
o NAT機能がゲートウェイによって提供されるかどうか、
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関数から分離されていることに注意してください。ただし、レガシーホストに対応するために、ネイティングはパスのある時点で提供される可能性があります。したがって、Pは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.
o CPEの背後にあるアプリケーションまたはエンドホストがUPNPV2/ NAT-PMP-AWAREでない場合、CPEは[PR-ADDR-Assign]および[Port-Range-OPT]に記載されているように、メカニズムを介してポートを要求する必要があります。異なるポート範囲には異なる寿命があり、CPEは有効期限が切れた後に使用する権利がないことに注意してください。CPEが追加の範囲を要求する前に、すでに割り当てられたポート範囲の割合を使い果たすべきか、CPEが追加の範囲を要求する頻度を決定するのは、ISP次第です（サービス拒否攻撃を防ぐため）。等々。
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].
o CPEの背後にあるアプリケーションがUPNPV2/NAT-PMP-AWAREである場合、そのメカニズムを通じて追加のポートが要求される場合があります。この場合、CPEはそれらの要求をLSNに転送する必要があり、LSNは要求されたポートが利用可能であるかどうかを報告する必要があります（そして、それらが利用できない場合は、いくつかの選択肢を提供する必要があります）。ここでも、潜在的なサービス拒否攻撃を防ぐために、UPNPV2/NAT-PMPパケットストームと迅速なポート割り当てを防ぐためのメカニズムを整える必要があります。PCPと呼ばれるこのメカニズムの詳細な説明は、[PCPベース]にあります。
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
トンネル内で使用されるシグナリングメカニズム（DHCP、IPコントロールプロトコル（IPCP）、またはPCPベースのPCPベース）は、シグナリングサーバーとPRR間の同期を両方向に確立する必要があります。たとえば、DHCPをシグナリングメカニズムとして使用する場合、PRRは少なくともそのIP範囲でDHCPサーバーと通信する必要があります。その後、DHCPサーバーはIPアドレスとポート範囲のCPEに割り当てられ、PRRに通信し、どのIPおよびポート範囲がCPEに割り当てられているかをPRRに戻し、PRRはどのトンネルが着信トラフィックをリダイレクトするかを知っています。さらに、DHCPも寿命を伝える必要があります
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.
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アドレスである場合があります。ゲートウェイは、いくつかの目的のために、その管理された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.
o A Pアドレス空間のサブパーティションのAPサブシステム内の他の認証されたA Pゲートウェイ（委任と呼ばれる）への割り当て。割り当てられたサブパーティオン委任アドレススペースを呼び出します。
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関数を実行できる場合、管理されている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.
したがって、プロバイダーは、時間の経過とともにゆっくりと展開するため、Pの「島」を持っている可能性があります。プロバイダーは、ユーザーの島または非A Pユーザーの海の特定のユーザーにさえ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
A Pゲートウェイ（ "A"）は、他のA Pゲートウェイ（ "B"）からの着信接続を受け入れます。接続確立（適切な認証を提供）により、BはA Pアドレスの委任についてAを「質問」します。順番に、AはそのパブリックIPv4アドレスについてBに通知し、
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).
さらに、ポート範囲の一部をBに委任します。さらに、Aはbとcaps/decaps関数を交渉します（たとえば、トンネルのエンドポイントにあるDecapsデバイスのアドレスをBに知らせます）。
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様のソリューションを介して実装できます。一般に、次のルールが適用されます。管理された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
アドレス空間領域：パブリックIPv4アドレス= 192.0.2.1ポート範囲= 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つの異なるデバイスで構成される可能性があることに注意してください。1つはBからのシグナリング要求を処理するものです。カプセル化と脱カプセル化を実行するもの。そして、提供されている場合、ネート関数を実行する1つのデバイス（例：LSN）。パケット転送は次のとおりであると想定されています。「アウトバウンド」の場合、パケットはプライベートアドレスの領域からBに到着します。上記のように、Bには2つのオプションがあります。NAT機能を適用または適用しないことができます。決定は、特定の構成および/またはAおよびBの機能に依存します。ただし、これは2つのデバイスAまたはBのいずれかで実行できます。「NAT」という用語は、パケットをマネージドAアドレスに変換することを指します（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パケット。翻訳されたパケットは、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はパケットを削減しません。その後、翻訳されていないパケットがAにトンネルされます。Aはパケットが翻訳されていないことを認識しているため、パケットを共同配置ネイティングデバイスに転送し、パケットを翻訳してパブリックインターネットにルーティングします。このデバイスは、例えば、LSNでは、返信を正しくルーティングするために、NATとパケットが来たトンネルに使用されるソースポートの間にマッピングを保存する必要があります。Aは、Bに委任された範囲のポート番号を使用できないことに注意してください。結果として、Aは非決定されたアドレス空間の一部をネート関数に割り当てる必要があります。
"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は、宛先ポート番号を分析して、パケットをネートする必要があるかどうかを理解します。
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.
1) 宛先ポート番号がbに委任された範囲に属している場合、A a a a a a a a a a a a a a a b. b natsは、保存されたマッピングを使用してパケットを使用して、翻訳されたパケットをプライベートドメインに転送します。
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.
2) 宛先ポート番号がLSNのアドレススペースからのものである場合、Aはパケットを共同配置された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.
3) 最後に、宛先ポート番号が委任された範囲もLSNの住所範囲もない場合、パケットを破棄します。パケットが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.
ポート番号に従ってルーティング決定を行うことができるように、パブリックIPv4アドレス（例では192.0.2.1）に導かれたすべてのIPv4パケットを受信できる必要があることに注意してください。一方、Bは、Aが確立されたトンネルを介してのみパブリックIPv4アドレスに向けられたIPv4パケットを受信します。つまり、Bは翻訳目的でパブリックIPv4アドレスを使用しますが、ルーティングの決定を行うためには使用されません。これにより、同じパブリックIPv4アドレスを共有するPデバイス間のシームレスな通信を有効にしながら、ルーティングロジックを上記のように単純に維持することができます。
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
アドレス空間領域：パブリックIPv4アドレス= 192.0.2.1ポート範囲= 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.
図4に示す例を考えてみましょう。ここでは、BとCの両方がEncaps/Decaps関数を使用してAを持つトンネルを確立し、異なる非重複ポート範囲の同じパブリックIPv4アドレスを割り当てられます。 Bのプライベートレルムのホストは、192.0.2.1とポート2000に対処するためのパケットを送信し、BがNATに192.0.2.1に向けられたすべてのパケットに指示されていると仮定します。これらの仮定の下で、Bはパケットを受け取り、NATは独自のPublic IPv4アドレス（192.0.2.1）と、構成されたポート範囲（例：3000）から選択されたポートを使用します。 b次に、翻訳されたパケットをAにトンネルAにトンネルがトンネルを介してパケットを受信すると、宛先アドレスとポートを見て、Cの委任範囲を認識し、パケットをCにトンネルにします。パケットは、公共のインターネットから来たかのようにパケットを処理します。 Cがパケットを受信すると、宛先アドレスをプライベートアドレスの領域から選択した1つのアドレスに削除し、ソースアドレス（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サブシステム内の各デバイスはcapps/decaps関数を提供するため、新しいデバイスはトンネルを確立し、A Pサブシステムの一部になります。上記のように、A Pサブシステムの一部であることは、翻訳なしで外部アドレスの領域と話す能力を意味します。特に、前のセクションで説明したように、A PサブシステムのデバイスXには、パブリックIPv4アドレスとXに委任されたポートを使用するだけで外部ドメインから到達できます。図5は、3つのデバイスがある例を示しています。チェーンで接続されています。言い換えれば、Pシグナル伝達を使用して、A Pサブシステムにあるデバイスへのエンドツーエンドの接続性を拡張できます。これにより、エンドホストで実行されているP-Awareアプリケーション（または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つのモードがあります。1つ目は、実際のエンドホストがNAT関数と、A Pサブシステムに参加するために必要なEncaps/Decaps関数を実行する場所です。このオプションは、ゲストオペレーティングシステムがNATを介してホストオペレーティングシステムに接続されているVMwareなどの仮想化ソフトウェアで採用されているホストのNATトリックと同様に機能します。2番目のモードは、アプリケーションが自律的にA Pアドレスを要求し、それを使用してA Pサブシステムに参加するときです。この機能は、エンドツーエンドの接続性（外部から連絡する必要があるアプリケーションなど）を必要とする一部のアプリケーションに必要です。
+---------+ +---------+ +---------+
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.
理由が何であれ、インターネットはエンドツーエンドの接続性が重要であるパラダイムの上に構築されました。A Pは、住所不足によりISPがさまざまなレベルでNATを使用することを強制する時代に、これをまだ可能にします。その意味で、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サブシステムに入るとき、またはA Pサブシステムを終了するときのいずれかです。これは、たとえば、プロバイダーのネットワーク内にLSNとともにインストールされたゲートウェイである可能性があります。次に、各顧客が独自のCPEを運用します。ただし、CPEの背後には、アプリケーションもP-Awareであり、独自の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.
「遅延翻訳」が使用されるときに1つの制限が適用されます（たとえば、CPEの代わりにLSNでの翻訳）。「遅延翻訳」を使用しているデバイスが互いに話し合いたい場合、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は、完全なポート範囲で無制限のアドレスです。 Full-A Pは、ISPからのポートレンジ割り当てを指します。顧客はA P-Aware CPEデバイスを操作する必要があり、ISPによってネート機能は提供されません。 DS-Lite [RFC6333]などのアドレスファミリ遷移ルーター（AFTR）はハイブリッドです。コアに存在するNATがあります（このドキュメントではLSNと呼ばれます）が、ユーザーは、たとえば、P、NAT-PMPなどを介して、ある形式でそのNATを「バイパス」するオプションがあります。 、CGNのみを展開するサービスプロバイダーは、プロバイダーのコアにNATを配置し、顧客が翻訳プロセスを「バイパス」したり、NATでアルグを変更したりすることはできません。顧客はプロバイダーロックされています。すべてのオプション（完全な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.
文書化された実験と同様に、Pの実装があります。フランステレコムは、[P-Experments]で説明されている実験を行いました。その実験で見られるように、ほとんどのテスト済みアプリケーションは影響を受けません。リスニングポートはPポートの範囲から外れており、PがPポート範囲から外れているため、Torrentプロトコルとアプリケーションには問題があります。
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テストと実験は、[Bittorrent-Addr-Sharing]でよく説明されています。その文書の結論は、2つの制限が経験されたことを示しています。最初は、同じIPアドレスを共有している2人のクライアントが、単一のリモートピアにある同じファイルを同時に取得しようとしたときに発生しました。2番目の制限は、クライアントがいくつかのシーダーにあるファイルをダウンロードしようとしたときに発生しました。これらのシーダーが同じIPアドレスを共有したとき。同じIPアドレスを持つホスト間の相互ファイル共有がチェックされています。実際、同じIPアドレスを持つマシンは、現在のIPアーキテクチャと比較して変更なしでファイルを共有できます。
Working implementations of A+P can be found in:
Pの動作実装は、次のものを見つけることができます。
o Internet Systems Consortium AFTR (http://www.isc.org/software/aftr),
o インターネットシステムコンソーシアムAFTR（http://www.isc.org/software/aftr）、
o FT Orange opensource A+P (http://opensourceaplusp.weebly.com/) developed by Xiaoyu Zhao, Xiaohong Deng, Tao Zheng, and
o ft orange opensource a p（http://opensourceaplusp.weebly.com/）Xiaoyu Zhao、Xiaohong Deng、Tao Zheng、および開発
o 4rd (IPv4 Residual Deployment) from ipinfusion.com, which is stateless A+P.
o IPInfusion.comからの第4（IPv4残差展開）、これはステートレスA Pです。
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ソースアドレスとポート番号からのIPv4-埋め込みIPv6アドレス[RFC6052]に加えて、SMAP関数を実行するノードにプロビジョニングされたIPv6プレフィックスを使用して構築されます。宛先IPv6アドレスは、共有IPv4宛先アドレスとポート番号と、SMAP関数にプロビジョニングされ、IPv4宛先アドレス専用のIPv6プレフィックスを使用して構築されます。
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対応ノードは、Stateless 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-in-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パケットを受信すると、それらのパケットのStateless 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に転送する前に、ノードAが受信したIPv4トラフィック（IPv6パケットにカプセル化された）でステートレスマッピング関数を実行します。ノードBは、転送する前に受信したIPv6トラフィック（IPv4パケットを抽出）でステートレスマッピング機能を実行します。IPv4宛先アドレスとポート番号によって識別される宛先へのIPv4トラフィック。反対方向に、そして以前と同様に、ノードBは、ノードAに転送する前に、受信したIPv4トラフィック（IPv6パケットにカプセル化）でステートレスマッピング関数を実行します。ノードAは受信したIPv6トラフィックでステートレスマッピング関数を実行します（IPv4パケット）IPv4のトラフィックをIPv4宛先アドレスとポート番号で識別するポイントに転送する前。この場合、ノードAとBの間のネットワークセグメントでIPv6トラフィックのみが管理されます。
+------+ +------+
| |----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のノードと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対応ノードは、与えられたASの相互接続セグメント（隣接する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関数を実装する2つのドメインの相互接続は、IPv4インターネットを介して展開される場合があります（図10）。これは、IPv6パケットにカプセル化されたIPv4パケットが最初のSMAP対応ノードに到達するまでIPv6を使用して転送されることを意味します。次に、これらのパケットは脱カプセル化され、IPv4転送機能を使用して転送されます。リモートSMAP対応ノードはこれらのパケットを受信し、IPv4-in-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番目のスキームは、IPv6を使用して、SMAP関数を実装する2つのレルムを相互接続することです（図11）。IANAによって割り当てられたIPv6プレフィックス（つまり、Pref6）がこのサービスに使用されます。適切なルーティング構成が実施されている場合、IPv6カプセル化されたパケットは最終目的地までルーティングされます。このモデルを実装するには、IPv4インタードメインルーティングテーブルにIPv4インセル化された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.
SMAP関数の展開により、IPv4接続サービスの顧客への配信を維持しながら、IPv6のみのスキームへのネットワークのスムーズな移行が可能になります。IPv6のみのネットワークを介したIPv4接続サービスの配信では、コアネットワークにステートフル機能を展開する必要はありません。これにより、Pモードのため、IPv4サービスの連続性とIPv6のみの展開モデルへの移行の両方が促進されます。
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
o ステートレスモード
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プレフィックスの重要なビットを埋め込むか、アルゴリズムアプローチを適用することによって達成できます。このようなステートレスマッピングを有効にする場合、2つの選択肢が提供されます。
- 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.
- ポート制限デバイスに2つのプレフィックスを提供します。1つはネイティブIPv6トラフィック用、もう1つはIPv4トラフィック用です。
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プレフィックスを提供するには、ポート制限デバイスのA /64プレフィックスと、ネイティブIPv6トラフィックの別のプレフィックス（A /56または /64など）を許可することの利点があります。この代替案により、サービスプロバイダーは、ネイティブIPv6トラフィックアドレス指定計画をIPv4アドレス指定計画に関連付けることができます。欠点は、各ポート制限デバイスに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.
- 両方のニーズ（A /56またはA /64など）に1つのプレフィックスを提供すると、サービスプロバイダーがポート制限デバイスとルーティングテーブルの2種類のIPv6プレフィックスを処理できます。しかし、欠点は、IPv4アドレス指定計画を割り当てられたIPv6プレフィックスに強くリンクしていることです。
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).
もう1つの選択肢は、「通常の」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バリアントの1つは4番目です[4番目]です。
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.
プロバイダーが顧客またはさまざまな顧客にPを有効にしたい場合、CPEをアップグレードまたは交換して、P Encaps/Decaps機能をサポートできることが期待されています。理想的には、CPEはネイティング機能も提供します。さらに、ISPネットワーク内の少なくとも別のコンポーネントが対応するA P機能を提供するため、CPEでA Pサブシステムを確立できることが予想されます。このデバイスは、A Pルーターまたはポートレンジルーター（PRR）と呼ばれ、PEルーターの近くに配置できます。ネットワークのコアは、トンネルプロトコル（制約7に従ってIPv6である必要があります）をサポートする必要がありますが、必要に応じて別のトンネルテクノロジーである場合があります。さらに、CPEまたは後ろに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ボーダーは、ゲートウェイ（例：ゲートウェイGPRSサポートノード（GGSN） /パケットデータネットワーク（PDN）ゲートウェイ（GW）の3GPPのゲートウェイ（GW）、またはマイクロ波アクセス（WIMAX）の世界的な相互運用性のAccessサービスネットワーク（ASN）GWであると想定されています。）。アドレスを拡張する必要性は、プロバイダーネットワーク内ではなく、携帯電話デバイスとゲートウェイの間の端にあります。望ましいものの、IPv6接続が提供される場合と提供されていない場合があります。
For mobile providers, we use the following terms and assumptions:
モバイルプロバイダーには、次の用語と仮定を使用します。
1. provider network (PN)
1. プロバイダーネットワーク（PN）
2. gateway (GW)
2. ゲートウェイ（GW）
3. mobile phone device (phone)
3. 携帯電話デバイス（電話）
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-Awareまたはアップグレードされることは期待していませんが、それらの進化を妨げたくありません。この意味で、携帯電話はブロードバンドプロバイダーのケースの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
図12の展開シナリオを考えてみましょう。ここで、A PサブシステムはCPEによって形成され、ISPコアネットワーク内のPRRが形成され、できれば顧客エッジに近いものです。サブシステム内では、パケットはアドレスとポートに基づいて転送されます。プロバイダーは、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-Awareアプリケーションを実行している拡張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（利用可能な場合）でネートされます。
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.
End-Hostで実行されているP-Awareアプリケーションは、セクション3.3.1で説明されているシグナリングを使用して、A Pサブシステムに接続する場合があります。この場合、アプリケーションは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もネイティング機能を提供しない場合、レガシーのエンドホストを接続することはできません。
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
Pを使用してパケット転送を有効にするには、ISPはA P BorderにパケットをカプセルするPRRをインストールする必要があります。ただし、より高いアドレス空間圧縮比を達成し、および/またはネート機能なしでCPEをサポートするために、ISPはLSNも提供することを決定する場合があります。ISPのトポロジの一部にLSNがインストールされていない場合、すべてのCPE
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.
トポロジのその部分では、NAT機能をサポートする必要があります。スケーラビリティの理由により、PRRはネットワークのアクセス部分内にあると想定されています。CPEは、PRRおよびLSNのアドレスを使用して自動的に構成されます（上記のシグナリング要件を備えた拡張DHCPまたはNAT-PMPを介して）（1つが提供されている場合）。図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に割り当てると、高層顧客にポートが疲れる可能性があります。これは、より要求の厳しい顧客を動揺させるための完璧なレシピです。一方、ピークユーザーのニーズに合わせて十分にすべての顧客ポートに割り当てることは、それほど効率的ではありません。ポート範囲の動的割り当てのメカニズムにより、ISPは2つの目標を達成できます。1つのIPv4アドレスの顧客数のより効率的な圧縮比と、一方で、より要求の厳しい顧客のコミュニケーションの制限はありません。
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はルーティングテーブルを更新します。追加のポート範囲を割り当てるメカニズムは、CPEをISPに認証するために使用される通常のシグナル伝達の一部である可能性があります。
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分間に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.
最小要求サイズはおそらくありません。これは、エンドホストで実行されているP-Awareアプリケーションが、CPEに連絡する単一のポート（またはいくつかのポート）を要求する可能性があるためです（例：Voice over IP（VoIP）クライアントがパブリックIPと単一の委任されたポートを登録しますCPEから、そのポートでの着信呼び出しを受け入れます）。CPEまたはPRRの実装では、小さなブロックのこのようなリクエストを処理する方法を決定します。たとえば、利用可能なブロックの半分は「ブロックアロケーション」に、1/6に1/6、残りはネートに使用できます。
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).
追加のポートを割り当てる別の可能なメカニズムは、CPEの背後にあるアプリケーションがサポートする場合、UPNP/ NAT-PMP（セクション3.3.1で定義されています）です。LSN実装（DS-Lite）の場合、A P全体のアーキテクチャに関するセクション3.3.4で説明されているように、シグナリングパケットはCPEによってLSNに転送され、ポートを要求したアプリケーションを実行するホストに戻るだけです。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.
このセクションでは、A Pサービスプロバイダーに接続されたエンドホストからIPv4インターネットの任意のホストに接続されたエンドホスト、および返品パケットのフローバックの詳細な例を示します。次の例では、NatingがCPEで行われるA P-Unawareエンドホストについて説明します。図14は、CPEがエンドユーザーデバイスからIPv4パケットを受信する方法を示しています。最初に、CPEがNAT機能を提供するように構成されている場合を説明します（たとえば、Webサイトとのやり取りまたは自動信号によって顧客によって）。以下では、CPEで翻訳されたパケットを「P orwarded Packet」と呼びます。これは、今日の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,
PRRがA Pに覆われたパケットを受信すると、内側のIPv4パケットを脱カプセル化し、ソースアドレスをチェックします。ソースアドレスがP対応のCPEに割り当てられた範囲に一致する場合、PRRは単純に分解パケットを前方に転送します。これは、P orwardedパケットの場合でも常に当てはまります。それ以外の場合、PRRは、パケットがpに囲まれていないと想定しており、LSN関数に渡すと渡します。
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.
これは、宛先アドレスに基づいてパケットを変換および転送します。図14は、P-orwardedパケットを発信するためのパケットフローを示しています。
+-----------+
| 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：P-orwardedパケットの発信の転送
+-----------------+--------------+-----------------------------+
| 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：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.
Datagram 1は、CPEまで翻訳されていない移動を行うことに注意してください。したがって、顧客は、今日の翻訳と同じコントロールを持っています。これは、カスタマイズ可能なポートフォードを備えたホームゲートウェイです。
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は、ネートに委任されたスペースを使用してはならないことを強調します。この場合のパケットフローを示すネットワーク図については、[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.
ほとんどのICMPメッセージは、エラーレポートまたはエコー/エコー応答（一般に「pings」と呼ばれる）の2つのカテゴリのいずれかに分類されます。エラーレポートの場合、問題のパケットヘッダーはICMPパケットに埋め込まれています。その後、NATデバイスはその部分を書き換えて、パケットを実際の宛先ホストにルーティングできます。この機能は、Pでは同じままです。ただし、PRRは埋め込まれたヘッダーを調べてポート番号を抽出する必要がありますが、A Pゲートウェイは必要な書き換えを行います。
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.
エコーとエコーの応答はより問題があります。エコーの場合、A Pゲートウェイデバイスは、ICMPリクエストの「識別子」および「シーケンス番号」フィールドを書き換えて、ポート番号のように扱う必要があります。このようにして、PRRは、戻るエコー応答の正しいA Pアドレスを構築できます。そのため、TCP/UDPパケットと同じ方法で適切なホストに正しく戻ることができます。Pingは、Public Realm（Internet）から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]で使用されているものと同様の専用手順をアクティブにする必要があります。宛先ポート番号を見るためのフラグメント。
Note that it is recommended to use a Path MTU Discovery (PMTUD) mechanism (e.g., [RFC1191]).
PATH MTU Discovery（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.
Pが他のIPアドレス共有メカニズムと共有する制限の1つは、よく知られているポートの可用性です。実際、同じIPアドレスを共有する顧客が実行するサービスは、ポート番号によって区別されます。結果として、同じIPアドレスを共有する2人の顧客が同じポートでサービスを実行することは不可能です（ポート80など）。残念ながら、この制限を回避することは、通常、アプリケーション固有のハック（例：HTTPやHTTPのリダイレクトなど）を意味し、その議論はこのドキュメントの範囲外です。もちろん、プロバイダーは、顧客によく知られているポート範囲0..1024を提供するためにより多く請求される可能性があり、顧客が外部で利用可能なサービスを提供できるようにします。多くのアプリケーションでは、よく知られているポートの可用性が必要です。ただし、これらのアプリケーションは、さまざまなポートでの作業に適応できない限り、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.
A 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]で分析されています。その文書に見られるように、ほとんどの問題はホストベースのポート共有ソリューションに適用されます。A 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]の結論は、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/LSNSを使用すると、ハッカー、スパマー、その他の犯罪者を追跡することは困難であり、すべての接続ベースのマッピング情報の伐採、記録、保存が必要です。ストレージの必要性は、トレードオフを意味します。一方では、LSNSは集約を最大化するために、できるだけ動的にアドレスとポートを管理できます。一方、プライベートスペースとパブリックスペースの変化のマッピングが速いほど、より多くの情報を記録する必要があります。これは、法執行サービスだけでなく、プライバシー擁護者にとっても懸念を引き起こすでしょう。
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.
もう1つの極端は、顧客の施設のP natです。このようなノードは、今日のNATボックスと違いはありません。したがって、PはCGNよりもかなり優れている一方で、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アプローチの開発に関する彼らの助けをしてくれたレミ・デスプレスとピエール・レビスに特に感謝したいと考えています。また、David Wardにレビュー、建設的な批判、干渉性のある質問をしてくれたことに感謝します。DaveThalerは、Pゲートウェイの「スタック可能な」という有用な批判をしてくれました。また、この作品の以前のバージョンについてのフィードバックについて、次の人に感謝したいと思います：ロブ・オースタイン、ゲルト・ドーリング、ディノ・ファリナッチ、ラス・ヒューズリー、ルーディガー・ヴォルク、ティナ・ツァウ、パシ・サロラティ。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Despres、R.、Matsushima、S.、Murakami、T。、およびO. Troan、「IPv4-Service Networks（第4）ISP-NATがオプションに作られたIPv4残存展開」、2011年3月の作業。
[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.
[P-Experiments] Deng、X.、Boucadair、M。、およびF. Telecom、「プロバイダーのIPv6のみのネットワークに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] Ferguson、P。およびD. Senie、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、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-Sharing] Boucadair、M.、Grimault、J.、Levis、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] Wing、D.、Cheshire、S.、Boucadair、M.、Penno、R.、およびP. Selkirk、「ポートコントロールプロトコル（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.、Levis、P.、Bajko、G.、Savolainen、T。、およびT. Zou）、「PPP IPCPのHuaweiポート範囲構成オプション」、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. Levis、「港制限IPアドレスの割り当て」、2010年9月に進行中の作業。
[PR-IP-ISSUES] Thaler, D., "Issues With Port-Restricted IP Addresses", Work in Progress, February 2010.
[PR-IP-Issues] Thaler、D。、「港湾制限IPアドレスの問題」、2010年2月に進行中の作業。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995.
[RFC1858] Ziemba、G.、Reed、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.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、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. Dixon、「Ipsec-Networkアドレス翻訳（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.、Cotton、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] Bao、C.、Huitema、C.、Bagnulo、M.、Boucadair、M.、およびX. Li、「IPv4/IPv6翻訳者のアドレス指定」、RFC 6052、2010年10月。
[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.、Matthews、P。、およびI. Van Beijnum、「Stateful Nat64：IPv6クライアントからIPv4サーバーへのネットワークアドレスとプロトコル翻訳」、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] Ford、M.、Boucadair、M.、Durand、A.、Levis、P。、およびP. Roberts、「IPアドレス共有の問題」、RFC 6269、2011年6月。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.
[RFC6333] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4 Exhotion後のデュアルスタックライトブロードバンド展開」、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.
[Shared-Addr-Opt] Boucadair、M.、Levis、P.、Grimault、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] Dec、W。、Asati、R.、Bao、C。、およびH. Deng、「Stateless 4Via6アドレス共有」、2011年7月の作業進行中。
This document has nine primary authors.
このドキュメントには9人の主要な著者がいます。
Gabor Bajko Nokia EMail: gabor.bajko@nokia.com
gabor bajko nokiaメール：gabor.bajko@nokia.com
Mohamed Boucadair France Telecom 3, Av Francois Chateaux Rennes 35000 France EMail: mohamed.boucadair@orange-ftgroup.co
Mohamed Boucadair France Telecom 3、Av Francois Chateaux Rennes 35000 Franceメール：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.ベロビンコロンビア大学1214アムステルダムアベニューMC 0401ニューヨーク、ニューヨーク10027米国電話：1 212 939 7149メール：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 X1メール：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
Luca Cittadini Universita 'Della Vasca Navale、79 Rome、00146 Italy電話：39 06 5733 3215メール：laca.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
Olaf Maennell Loughborough University of Computer Science -N.2.03 Loughborough Unitaddom Chone：44 115 714 0042メール：o@maennel.net
Reinaldo Penno Juniper Networks 1194 North Mathilda Avenue Sunnyvale, California 94089 US EMail: rpenno@juniper.net
Reinaldo Penno Juniper Networks 1194 North Mathilda Avenue Sunnyvale、California 94089 US Email：rpenno@juniper.net
Teemu Savolainen Nokia Hermiankatu 12 D TAMPERE, FI-33720 Finland EMail: teemu.savolainen@nokia.com
Teemu Savolainen Nokia Hermiankatu 12 D Tampere、fi-33720フィンランドメール：teemu.savolainen@nokia.com
Jan Zorz Go6 Institute Slovenia Frankovo naselje 165 Skofja Loka, 4220 Slovenia EMail: jan@go6.si
Jan Zorz Go6 Institute Slovenia Frankovo Naselje 165 Skofja Loka、4220 Sloveniaメール：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