Internet Engineering Task Force (IETF) M. Ford, Ed.
Request for Comments: 6269 Internet Society
Category: Informational M. Boucadair
ISSN: 2070-1721 France Telecom
A. Durand
Juniper Networks
P. Levis
France Telecom
P. Roberts
Internet Society
June 2011
Issues with IP Address Sharing
Abstract
抽象
The completion of IPv4 address allocations from IANA and the Regional Internet Registries (RIRs) is causing service providers around the world to question how they will continue providing IPv4 connectivity service to their subscribers when there are no longer sufficient IPv4 addresses to allocate them one per subscriber. Several possible solutions to this problem are now emerging based around the idea of shared IPv4 addressing. These solutions give rise to a number of issues, and this memo identifies those common to all such address sharing approaches. Such issues include application failures, additional service monitoring complexity, new security vulnerabilities, and so on. Solution-specific discussions are out of scope.
IANAと地域インターネットレジストリ（RIRが）からIPv4アドレスの割り当ての完了は、もはや十分ではIPv4は彼らに、加入者ごとに1つずつ割り当てるアドレスが存在しないとき、彼らは彼らの加入者にIPv4接続サービスを提供し続ける方法を疑問視する世界中のサービスプロバイダーを引き起こしています。この問題に対するいくつかの可能な解決策は今のアドレッシング共有のIPv4の考え方をベースに浮上しています。これらのソリューションは、多くの問題を生じさせ、そしてこのメモはそのようなすべてのアドレス共有アプローチに共通するものを識別されます。このような問題は、その上のアプリケーションの障害、追加のサービス監視の複雑さ、新しいセキュリティの脆弱性などがあります。ソリューション固有の議論は適用範囲外です。
Deploying IPv6 is the only perennial way to ease pressure on the public IPv4 address pool without the need for address sharing mechanisms that give rise to the issues identified herein.
IPv6導入は、ここで特定された問題を生じさせるアドレス共有メカニズムを必要とせずにパブリックIPv4アドレスプールへの圧力を緩和するための唯一の多年生の方法です。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6269.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6269で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Shared Addressing Solutions . . . . . . . . . . . . . . . . . 4
3. Analysis of Issues as They Relate to First and Third
Parties . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Content Provider Example . . . . . . . . . . . . . . . . . . . 8
5. Port Allocation . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Outgoing Ports . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Incoming Ports . . . . . . . . . . . . . . . . . . . . . . 10
5.2.1. Port Negotiation . . . . . . . . . . . . . . . . . . . 11
5.2.2. Connection to a Well-Known Port Number . . . . . . . . 12
5.2.3. Port Discovery Mechanisms . . . . . . . . . . . . . . 12
6. Impact on Applications . . . . . . . . . . . . . . . . . . . . 12
7. Geo-location and Geo-proximity . . . . . . . . . . . . . . . . 14
8. Tracking Service Usage . . . . . . . . . . . . . . . . . . . . 15
9. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 16
12. Traceability . . . . . . . . . . . . . . . . . . . . . . . . . 17
13. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.1. Abuse Logging and Penalty Boxes . . . . . . . . . . . . . 18
13.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 19
13.3. Spam . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
13.4. Port Randomization . . . . . . . . . . . . . . . . . . . . 19
13.5. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.6. Policing Forwarding Behavior . . . . . . . . . . . . . . . 20
14. Transport Issues . . . . . . . . . . . . . . . . . . . . . . . 20
14.1. Parallel Connections . . . . . . . . . . . . . . . . . . . 20
14.2. Serial Connections . . . . . . . . . . . . . . . . . . . . 20
14.3. TCP Control Block Sharing . . . . . . . . . . . . . . . . 21
15. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 21
16. Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . 21
17. IPv6 Transition Issues . . . . . . . . . . . . . . . . . . . . 21
18. Introduction of Single Points of Failure . . . . . . . . . . . 22
19. State Maintenance Reduces Battery Life . . . . . . . . . . . . 22
20. Support of Multicast . . . . . . . . . . . . . . . . . . . . . 22
21. Support of Mobile-IP . . . . . . . . . . . . . . . . . . . . . 22
22. Security Considerations . . . . . . . . . . . . . . . . . . . 23
23. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
24. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
25. Informative References . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Classes of Address Sharing Solution . . . . . . . . . 27
Appendix B. Address Space Multiplicative Factor . . . . . . . . . 27
Allocations of IPv4 addresses from the Internet Assigned Numbers Authority (IANA) were completed on February 3, 2011 [IPv4_Pool]. Allocations from Regional Internet Registries (RIRs) are anticipated to be complete around a year later, although the exact date will vary from registry to registry. This is causing service providers around the world to start to question how they will continue providing IPv4 connectivity service to their subscribers when there are no longer sufficient IPv4 addresses to allocate them one per subscriber. Several possible solutions to this problem are now emerging based around the idea of shared IPv4 addressing. These solutions give rise to a number of issues, and this memo identifies those common to all such address sharing approaches and collects them in a single document.
インターネット割り当て番号機関（IANA）からIPv4アドレスの割り当ては2011 [IPv4_Pool]、2月3日に完了しました。正確な日付は、レジストリに、レジストリごとに異なりますが、地域インターネットレジストリ（RIRが）からの割り当ては、一年後の周りに完了することが予想されます。これは、彼らがIPv4のは彼らに、加入者ごとに1つずつ割り当てるアドレスを十分にはもはや存在しているとき、その加入者にIPv4接続サービスを提供していない続けるか疑問を開始するために、世界中のサービスプロバイダーを引き起こしています。この問題に対するいくつかの可能な解決策は今のアドレッシング共有のIPv4の考え方をベースに浮上しています。これらのソリューションは、多くの問題を生じ、そしてこのメモはそのようなすべてのアドレス共有アプローチに共通するものと識別し、単一のドキュメントでそれらを収集します。
Deploying IPv6 is the only perennial way to ease pressure on the public IPv4 address pool without the need for address sharing mechanisms that give rise to the issues identified herein. In the short term, maintaining growth of IPv4 services in the presence of IPv4 address depletion will require address sharing. Address sharing will cause issues for end-users, service providers, and third parties such as law enforcement agencies and content providers. This memo is intended to highlight and briefly discuss these issues.
IPv6導入は、ここで特定された問題を生じさせるアドレス共有メカニズムを必要とせずにパブリックIPv4アドレスプールへの圧力を緩和するための唯一の多年生の方法です。短期的には、IPv4アドレスの枯渇の存在下でのIPv4サービスの成長を維持することは、アドレスの共有が必要になります。アドレス共有は、このような法執行機関やコンテンツプロバイダとして、エンドユーザー、サービスプロバイダー、および第三者のために問題が発生します。このメモを強調表示し、簡単にこれらの問題を議論することを意図しています。
Increased IPv6 deployment should reduce the burden being placed on an address sharing solution, and should reduce the costs of operating that solution. Increasing IPv6 deployment should cause a reduction in the number of concurrent IPv4 sessions per subscriber. If the percentage of end-to-end IPv6 traffic significantly increases, so that the volume of IPv4 traffic begins decreasing, then the number of IPv4 sessions will decrease. The smaller the number of concurrent IPv4 sessions per subscriber, the higher the number of subscribers able to share the same IPv4 public address, and consequently, the lower the number of IPv4 public addresses required. However, this effect will only occur for subscribers who have both an IPv6 access and a shared IPv4 access. This motivates a strategy to systematically bind a shared IPv4 access to an IPv6 access. It is difficult to foresee to what extent growing IPv6 traffic will reduce the number of concurrent IPv4 sessions, but in any event, IPv6 deployment and use should reduce the pressure on the available public IPv4 address pool.
増加したIPv6の展開は、アドレス共有ソリューションの上に置かれている負担を軽減すべきである、と操作そのソリューションのコストを削減しなければなりません。 IPv6の展開を大きくすると、加入者ごとの同時のIPv4セッションの数の減少を引き起こす必要があります。エンドツーエンドのIPv6トラフィックの割合が大幅に増加した場合、IPv4トラフィックの量が減少し始めるように、その後のIPv4セッションの数が減少します。必要なIPv4のパブリックアドレスの数より低い、より高い、加入者ごとの同時のIPv4セッションの数より小さい同じIPv4のパブリックアドレスを共有することができる加入者の数、ひいては。しかし、この効果は、IPv6のみのアクセスと共有IPv4アクセスの両方を持っている加入者に発生します。これは、体系的にIPv6アクセスへの共有IPv4アクセスをバインドするための戦略に動機を与えます。成長しているIPv6トラフィックは、同時のIPv4セッションの数を削減するためにどの程度予見することは困難であるが、いずれにしても、IPv6の展開と使用が可能なパブリックIPv4アドレスプールへの圧力を減らす必要があります。
In many networks today, a subscriber is provided with a single public IPv4 address at their home or small business. For instance, in fixed broadband access, an IPv4 public address is assigned to each CPE (Customer Premises Equipment). CPEs embed a NAT function that is responsible for translating private IPv4 addresses ([RFC1918] addresses) assigned to hosts within the local network, to the public IPv4 address assigned by the service provider (and vice versa). Therefore, devices located with the LAN share the single public IPv4 address and they are all associated with a single subscriber account and a single network operator.
多くのネットワークは、今日では、加入者は、自分の家庭や小規模ビジネスでの単一のパブリックIPv4アドレスを備えています。例えば、固定ブロードバンドアクセスでは、IPv4のパブリックアドレスは、各CPE（顧客宅内機器）に割り当てられています。 CPEは、サービスプロバイダ（およびその逆）によって割り当てられたパブリックIPv4アドレスに、ローカルネットワーク内のホストに割り当てられたプライベートIPv4アドレス（[RFC1918]アドレス）を変換する責任があるNAT機能を組み込みます。そのため、LANであるデバイスは、単一のパブリックIPv4アドレスを共有し、それらはすべて、単一のユーザアカウントと単一のネットワーク・オペレータに関連付けられています。
A number of proposals currently under consideration in the IETF rely upon the mechanism of multiplexing multiple subscribers' connections over a smaller number of shared IPv4 addresses. This is a significant change. These proposals include Carrier Grade NAT (CGN a.k.a. LSN for Large Scale NAT) [LSN-REQS], Dual-Stack Lite [DS-Lite], NAT64 [RFC6145] [RFC6146], Address+Port (A+P) proposals [A+P] [PORT-RANGE], and Stateless Address Mapping [SAM]. Appendix A and Appendix B provide a classification of these different types of solutions and discuss some of the design considerations to be borne in mind when deploying large-scale address sharing. Whether we're talking about DS-Lite, A+P, NAT64, or CGN isn't especially important -- it's the view from the outside that matters, and given that, most of the issues identified below apply regardless of the specific address sharing scenario in question.
IETFで現在検討中の提案の数は、共有IPv4アドレスの数が少ない以上の多重化、複数の加入者の接続のメカニズムに依存しています。これは大きな変化です。これらの提案は、キャリアグレードNAT（CGN別名LSN大規模NAT用）[LSN-REQS]、デュアルスタックライト[DS-Liteの]、NAT64 [RFC6145] [RFC6146]、アドレス+ポート（A + P）の提案[A + P] [PORT-RANGE]、及びステートレスアドレスマッピング[SAM]。付録Aおよび付録Bには、ソリューションのこれらの異なるタイプの分類を提供し、大規模なアドレス共有を展開する際に念頭に置くことが設計上の考慮事項のいくつかを議論します。我々はDS-Liteは、A + P、NAT64、またはCGNの話をしているかどうかは、特に重要ではありません - それは重要外から眺めだし、与えられた以下の特定された問題のほとんどは、特定のアドレスに関係なく適用されます、ということ問題のシナリオを共有します。
In these new proposals, a single public IPv4 address would be shared by multiple homes or small businesses (i.e., multiple subscribers), so the operational paradigm described above would no longer apply. In this document, we refer to this new paradigm as large-scale address sharing. All these proposals extend the address space by adding port information; they differ in the way they manage the port value.
これらの新たな提案では、単一のパブリックIPv4アドレスは、複数の家庭や中小企業（すなわち、複数の加入者）によって共有されることになるので、上記の運用パラダイムはもはや適用されないだろう。この文書では、我々は大規模なアドレス共有として、この新しいパラダイムを参照してください。すべてのこれらの提案は、ポート情報を追加することによって、アドレス空間を拡張します。彼らはポート値を管理する方法が異なります。
Security issues associated with NAT have long been documented (see [RFC2663] and [RFC2993]). However, sharing IPv4 addresses across multiple subscribers by any means, either moving the NAT functionality from the home gateway to the core of the service provider network or restricting the port choice in the subscriber's NAT, creates additional issues for subscribers, content providers, and network operators. Many of these issues are created today by public Wi-Fi hotspot deployments. As such large-scale address sharing solutions become more widespread in the face of IPv4 address depletion, these issues will become both more severe and more commonly felt. NAT issues in the past typically only applied to a single legal entity; as large-scale address sharing becomes more prevalent, these issues will increasingly span across multiple legal entities simultaneously.
NATに関連するセキュリティ上の問題は長い（[RFC2663]と[RFC2993]を参照）に文書化されています。しかし、任意の手段によって、複数の加入者間でのIPv4アドレスを共有し、いずれかのサービスプロバイダーのネットワークのコアにホームゲートウェイからのNAT機能を移動したり、加入者のNATでポートの選択を制限し、加入者、コンテンツプロバイダ、およびネットワークのための追加的な問題を作成し、演算子。これらの問題の多くは、公共のWi-Fiホットスポットの導入により、今日作成されます。このような大規模なアドレス共有ソリューションは、IPv4アドレスの枯渇に直面して、より普及したように、これらの問題はより深刻と、より一般的に感じたの両方になります。過去にNATの問題は、通常、単一の法人に適用されます。大規模なアドレスの共有がより一般的になるにつれて、これらの問題はますます同時に複数の法人にまたがるます。
All large-scale address sharing proposals share technical and operational issues, and these are addressed in the sections that follow. These issues are common to any service-provider NAT, enterprise NAT, and also non-NAT solutions that share individual IPv4 addresses across multiple subscribers. This document is intended to bring all of these issues together in one place.
すべての大規模なアドレス共有の提案は、技術的および運用上の問題を共有し、そしてこれらは、以下のセクションで対処されています。これらの問題は、いずれかのサービスプロバイダーNAT、企業NATに共通しており、複数の加入者間で個別のIPv4アドレスを共有し、また、非NATソリューション。この文書は、一箇所にまとめて、これらの問題のすべてを持参することを意図しています。
In this section, we present an analysis of whether the issues identified in the remainder of this document are applicable to the organization deploying the shared addressing mechanism (and by extension their subscribers) and/or whether these issues impact third parties (e.g., content providers, law enforcement agencies, etc.). In this analysis, issues that affect end-users are deemed to affect first parties, as end-users can be expected to complain to their service provider when problems arise. Where issues can expect to be foreseen and addressed by the party deploying the shared addressing solution, they are not attributed.
このセクションでは、我々は、この文書の残りの部分で識別された問題は、共有アドレッシング機構（ひいては加入者）を展開組織に適用され、および/または、これらの問題は、第三者（例えば、コンテンツプロバイダに影響を与えるかどうかどうかの分析を提示し、法執行機関、など）。エンドユーザーは、問題が発生したときに彼らのサービスプロバイダに文句を期待することができるように、この分析では、エンドユーザーに影響を与える問題は、最初の当事者に影響を与えるものとみなされます。問題が予見し、共有アドレス指定のソリューションを導入する当事者によって対処されることを期待できる場合には、それらが帰属されていません。
In Figure 1, we have also tried to indicate (with 'xx') where issues are newly created in addition to what could be expected from the introduction of a traditional NAT device. Issues marked with a single 'x' are already present today in the case of typical CPE NAT; however, they can be expected to be more severe and widespread in the case of large-scale address sharing.
図1では、我々はまた、問題が新たに伝統的なNATデバイスの導入から期待できるものに加えて、作成された（「XX」で）示すことを試みました。単一の「x」でマークされた問題は、典型的なCPEのNATの場合には、すでに今日存在しています。しかし、彼らは大規模なアドレス共有の場合に、より深刻かつ広範であることを期待することができます。
+------------------------------------------------+--------+---------+
| Issue | 1st | 3rd |
| | party | parties |
+------------------------------------------------+--------+---------+
| Restricted allocations of outgoing | x | |
| ports will impact performance for end-users | | |
| | | |
| Incoming port negotiation mechanisms may fail | xx | |
| | | |
| Incoming connections to Assigned Ports will | x | |
| not work | | |
| | | |
| Port discovery mechanisms will not work | x | |
| | | |
| Some applications will fail to operate | x | x |
| | | |
| Assumptions about parallel/serial connections | x | x |
| may fail | | |
| | | |
+------------------------------------------------+--------+---------+
+------------------------------------------------+--------+---------+
| Issue | 1st | 3rd |
| | party | parties |
+------------------------------------------------+--------+---------+
| TCP control block sharing will be affected | x | x |
| | | |
| Reverse DNS will be affected | x | x |
| | | |
| Inbound ICMP will fail in many cases | x | x |
| | | |
| Amplification of security issues will occur | xx | xx |
| | | |
| Fragmentation will require special handling | x | |
| | | |
| Single points of failure and increased | x | |
| network instability may occur | | |
| | | |
| Port randomization will be affected | x | |
| | | |
| Service usage monitoring and abuse logging | xx | xx |
| will be impacted for all elements in the chain | | |
| between service provider and content provider | | |
| | | |
| Penalty boxes will no longer work | xx | xx |
| | | |
| Spam blacklisting will be affected | xx | xx |
| | | |
| Geo-location services will be impacted | xx | xx |
| | | |
| Geo-proximity mechanisms will be impacted | xx | xx |
| | | |
| Load balancing algorithms may be impacted | | xx |
| | | |
| Authentication mechanisms may be impacted | | x |
| | | |
| Traceability of network usage and abusage will | | xx |
| be affected | | |
| | | |
| IPv6 transition mechanisms will be affected | xx | |
| | | |
| Frequent keep-alives will reduce battery life | x | |
| | | |
+------------------------------------------------+--------+---------+
Figure 1: Shared addressing issues for first and third parties
図1：共有は、第1および第三者のために問題に対処
As can be seen from Figure 1, deployment of large-scale address sharing will create almost as many problems for third parties as it does for the service provider deploying the address sharing mechanism. Several of these issues are specific to the introduction of large-scale address sharing as well. All of these issues are discussed in further detail below.
図1から分かるように、それはアドレスを共有する機構を展開サービスプロバイダの場合と同様に、大規模なアドレス共有の展開は、第三者のためにほぼ同じ多くの問題を作成します。これらの問題のいくつかは、同様に大規模なアドレス共有の導入に固有のものです。これらの問題のすべては、以下に詳細に説明されています。
Taking a content provider as an example of a third party, and focusing on the issues that are created specifically by the presence of large-scale address sharing, we identify the following issues as being of particular concern:
第三者の例として、コンテンツプロバイダを取って、そして大規模なアドレス共有の存在によって特別に作成されている問題に焦点を当て、我々は特に問題であるとして、次の問題を識別します。
o Degraded geo-location for targeted advertising and licensed content restrictions (see Section 7).
Oターゲットを絞った広告とライセンスのコンテンツ制限のための劣化ジオロケーション（セクション7を参照します）。
o Additional latency due to indirect routing and degraded geo-proximity (see Section 7).
間接的なルーティングおよび劣化地理的近接に起因O追加のレイテンシ（セクション7参照します）。
o Exposure to new amplification attacks (see Section 13).
新しい増幅攻撃への暴露O（セクション13を参照）。
o Service usage monitoring is made more complicated (see Section 8).
Oサービスの使用状況の監視がより複雑になること（セクション8を参照）。
o Incoming port negotiation mechanisms may fail (see Section 5.2.1).
O着信ポートネゴシエーションメカニズム（セクション5.2.1を参照）が失敗することがあります。
o IP blocking for abuse/spam will cause collateral damage (see Section 13).
Oの濫用/スパムのためのIPブロック（セクション13を参照）担保損傷を与える可能性があります。
o Load balancing algorithms may be impacted (see Section 16).
O負荷分散アルゴリズム（セクション16を参照）影響を受ける可能性があります。
o Traceability of network usage and abuse will be impacted (see Section 12).
Oネットワークの使用状況や虐待のトレーサビリティは、影響を受ける（セクション12を参照）。
When we talk about port numbers, we need to make a distinction between outgoing connections and incoming connections. For outgoing connections, the actual source port number used is usually irrelevant. (While this is true today, in a port-range solution, it is necessary for the source port to be within the allocated range.) But for incoming connections, the specific port numbers allocated to subscribers matter because they are part of external referrals (used by third parties to contact services run by the subscribers).
我々は、ポート番号について話すとき、私たちは、発信接続と着信接続の区別をする必要があります。発信接続のために、使用される実際の送信元ポート番号は、通常、無関係です。 （これは今日のは事実ですが、送信元ポートが割り当てられた範囲内であるためには、ポート範囲の溶液中で、それが必要です。）しかし、彼らは外部の紹介の一部（であるため、着信接続のために、加入者に割り当てられた固有のポート番号は重要で加入者によって実行されるサービスに連絡することを第三者が使用します）。
The total number of subscribers able to share a single IPv4 address will depend upon assumptions about the average number of ports required per active subscriber, and the average number of simultaneously active subscribers. It is important to realize that the TCP design makes it undesirable for clients to re-use ports while they remain in the TIME-WAIT state (typically 4 minutes after the connection has concluded). TIME-WAIT state removes the hazard of old duplicates for "fast" or "long" connections, in which clock-driven Initial Sequence Number selection is unable to prevent overlap of the old and new sequence spaces. The TIME-WAIT delay allows all old duplicate segments time enough to die in the Internet before the connection is reopened [RFC1337]. Therefore, ports in this state must be included in calculations concerning port usage per subscriber.
単一IPv4アドレスを共有することができる加入者の総数はアクティブ加入者ごとに必要なポート数の平均値、および同時にアクティブな加入者の平均数についての仮定に依存するであろう。彼らがTIME-WAIT状態のまま、クライアントがポートを再利用するために（典型的には4分の接続後に締結している）TCPのデザインは、それが望ましくない可能ということを理解することは重要です。 TIME-WAIT状態は、クロック駆動の初期シーケンス番号の選択は、古いものと新しいシーケンス空間の重複を防ぐことができないである「高速」または「長い」接続、古い重複の危険性を除去します。 TIME-WAIT遅延は、接続が再び開かれる前にインターネットで死ぬのに十分なすべての古い重複セグメント時間[RFC1337]を可能にします。したがって、この状態のポートは、加入者ごとのポート使用に関する計算に含めなければなりません。
Most of the time the source port selected by a client application will be translated (unless there is direct knowledge of a port-range restriction in the client's stack), either by a NAT in the subscriber's device, or by a CPE NAT, or by a CPE NAT and a CGN.
加入者のデバイスでNATのいずれかによって、（クライアントのスタック内のポート範囲の制限の直接的な知識がない限り）、クライアントアプリケーションによって選択された送信元ポートが翻訳されるほとんどの時間、またはCPE NATによって、またはによってCPE NATとCGN。
[RFC1700] (which was replaced by an online database, as described by [RFC3232]) defines the Assigned Ports (both System and User). IANA has further classified the whole port space into three categories, as defined in [IANA_Ports]:
[RFC1700]（[RFC3232]で説明したように、オンラインデータベースによって置き換えられた）が割り当てポート（システムとユーザの両方）を定義します。 【IANA_Ports]で定義されるようにIANAは、更に、三つのカテゴリーに全ポート空間を分類しました。
o The Well-Known Ports are those from 0 through 1023.
Oウェルノウンポートは、0から1023のものです。
o The Registered Ports are those from 1024 through 49151.
O登録ポートは、1024から49151を介してのものです。
o The Dynamic and/or Private Ports are those from 49152 through 65535.
動的および/またはプライベートポートoを49152から65535のものです。
[RFC4787] notes that current NATs have different policies with regard to this classification; some NATs restrict their translations to the use of dynamic ports, some also include registered ports, some preserve the port if it is in the well-known range. [RFC4787] makes it clear that the use of port space (1024-65535) is safe: "mapping a source port to a source port that is already registered is unlikely to have any bad effects". Therefore, for all address sharing solutions, there is no reason to only consider a subset of the port space (1024-65535) for outgoing source ports.
[RFC4787]は、現在のNATのは、この分類に関して異なるポリシーを持っていることを指摘します。いくつかのNATは、それがよく知られている範囲内であれば、いくつかのポートを保存する、いくつかはまた、登録されたポートを含む、動的ポートの使用への変換を制限します。 「すでに登録されている送信元ポートに送信元ポートをマッピングすると、任意の悪い影響を与えることはほとんどありません」：[RFC4787]は、それが明確なポート空間の使用（1024-65535）が安全であることになります。そのため、すべてのアドレス共有ソリューションのための、唯一の発信元ポートのポート空間（1024-65535）のサブセットを検討する理由はありません。
According to measurements, the average number of outgoing ports consumed per active subscriber is much, much smaller than the maximum number of ports a subscriber can use at any given time. However, the distribution is heavy-tailed, so there are typically a small number of subscribers who use a very high number of ports [CGN_Viability]. This means that an algorithm that dynamically allocates outgoing port numbers from a central pool will typically allow more subscribers to share a single IPv4 address than algorithms that statically divide the resource by pre-allocating a fixed number of ports to each subscriber. Similarly, such an algorithm should be more able to accommodate subscribers wishing to use a relatively high number of ports.
測定によれば、アクティブ加入者当たりに消費発信ポートの平均数は、加入者が任意の時点で使用できるポートの最大数よりも、はるかに小さいです。しかし、分布はヘビーテイルであるので、[CGN_Viability]ポートの非常に高い数を使用するユーザの数が少ないが、典型的には存在します。これは、動的に中央プールから発信ポート番号を割り当てるアルゴリズムは、典型的には、より多くの加入者が静的に各加入者にポートの固定数を予め割り当てることにより、リソースを分割するアルゴリズムより単一IPv4アドレスを共有することを可能にすることを意味します。同様に、このようなアルゴリズムは、ポートの比較的高い数を使用することを望む加入者を収容することがより可能であるべきです。
It is important to note here that the desire to dynamically allocate outgoing port numbers will make a service provider's job of maintaining records of subscriber port number allocations considerably more onerous (see Section 12). The number of records per subscriber will increase from 1 in a scheme where ports are statically allocated, to a much larger number equivalent to the total number of outgoing ports consumed by that subscriber during the time period for which detailed logs must be kept.
動的に発信ポート番号を割り当てるための欲求が（セクション12を参照）かなり面倒な加入者ポート番号の割り当ての記録を維持するためのサービスプロバイダの仕事を行うことをここで注意することは重要です。加入者ごとのレコード数は、詳細なログが維持されなければならない時間期間中にその加入者によって消費される発信ポートの合計数に相当する非常に大きい数に、ポートが静的に割り当てられている方式で1から増加するであろう。
A potential problem with dynamic allocation occurs when one of the subscriber devices behind such a port-shared IPv4 address becomes infected with a worm, which then quickly sets about opening many outbound connections in order to propagate itself. Such an infection could rapidly exhaust the shared resource of the single IPv4 address for all connected subscribers. It is therefore necessary to impose limits on the total number of ports available to an individual subscriber to ensure that the shared resource (the IPv4 address) remains available in some capacity to all the subscribers using it. However, static schemes for ports assignment may introduce security issues [RFC6056] when small contiguous port ranges are statically assigned to subscribers. Another way to mitigate this issue is to kill off (randomly) established connections when the port space runs out. A user with many connections will be proportionally more likely to get impacted.
そのようなポートの共有IPv4アドレスの背後にある加入者デバイスの1つが、その後急速に自身を伝搬させるために多くのアウトバウンド接続を開くについて設定ワームに感染なったときに動的割り当ての潜在的な問題が発生します。そのような感染は急速に接続されたすべての加入者のための単一のIPv4アドレスの共有リソースを使い果たす可能性があります。共有リソース（IPv4アドレス）は、それを使用して、すべての加入者にいくつかの容量で利用可能なままであることを保証するために、個々の加入者に利用可能なポートの総数に制限を課すことが必要です。ただし、ポートの割り当てのための静的なスキームは、セキュリティ上の問題小さな連続したポート範囲を静的加入者に割り当てられている[RFC6056]を導入することができます。この問題を軽減するための別の方法は、ポートスペースがなくなったときに（ランダムに）確立された接続を殺すことです。多くの接続を持つユーザーが影響を受け得るために比例可能性が高くなります。
Session failure due to NAT state overflow or timeout (when the NAT discards session state because it's run out of resource) can be experienced when the configured quota per user is reached or if the NAT is out of resources.
NAT状態のオーバーフローまたはタイムアウトによるセッション失敗NATは、リソースの外にある場合、ユーザーごとに構成されたクォータに達したときに経験したりすることができます（これは、リソースが不足しているため、NATは、セッション状態を破棄した場合）。
It is desirable to ensure that incoming ports remain stable over time. This is challenging as the network doesn't know anything in particular about the applications that it is supporting, and therefore has no real notion of how long an application/service session is still ongoing and therefore requiring port stability.
着信ポートが経時的に安定ままであることを確実にすることが望ましいです。ネットワークは、それがサポートするので、アプリケーション/サービスのセッションがまだ進行中であり、したがって、ポート安定性を必要とするどのくらいの本当の概念を持っていないアプリケーションについて特に何も知りませんので、これは困難です。
Early measurements [CGN_Viability] also seem to indicate that, on average, only very few ports are used by subscribers for incoming connections. However, a majority of subscribers accept at least one inbound connection.
初期の測定値は、[CGN_Viability]また、平均して、ごく少数のポートが着信接続のための加入者によって使用されている、ことを示しているように見えます。しかし、加入者の大半は、少なくとも一つの着信接続を受け入れます。
This means that it is not necessary to pre-allocate a large number of incoming ports to each subscriber. It is possible to either pre-allocate a small number of ports for incoming connections or do port allocation on demand when the application wishing to receive a connection is initiated. The bulk of incoming ports can be reserved as a centralized resource shared by all subscribers using a given public IPv4 address.
これは、各加入者に着信ポートの事前に割り当てる多数する必要がないことを意味します。どちらかの着信接続用のポートの数が少ない事前に割り当てたり、接続を受信したいアプリケーションが開始されたときに、必要に応じてポートの割り当てを行うことが可能です。着信ポートの大部分は、所与のパブリックIPv4アドレスを使用して、すべての加入者によって共有される集中リソースとして予約することができます。
In current deployments, one important and widely used feature of many CPE devices is the ability to open incoming ports (port forwarding) either manually, or with a protocol such as the Universal Plug and Play Internet Gateway Device (UPnP IGD) [UPnP-IGD]. If a CGN is present, the port must also be opened in the CGN. CGN makes subscribers dependent on their service provider for this functionality.
現在の展開では、多くのCPEデバイスの一つの重要かつ広く使用されている機能は、インターネットゲートウェイデバイス（UPnPのIGD）のUPnP IGDを手動で、またはプロトコルと、ユニバーサルプラグとして受信ポート（ポートフォワーディング）を開いて再生する能力であります]。 CGNが存在する場合、ポートもCGNでオープンする必要があります。 CGNは、この機能のために彼らのサービスプロバイダに加入者が依存させます。
CPE and CGN will need to cooperate in order for port forwarding functionality to work. UPnP, or NAT-PMP proxy could be a solution if there is a direct link (or tunnel) between the CPE and the CGN. An alternative solution is a web interface to configure the incoming port mapping on the CGN. Protocol development is underway in the IETF to provide a generalized, automated solution via the Port Control Protocol [PCP].
CPEとCGNは、ポートフォワーディング機能を動作させるために協力する必要があります。 CPEとCGNの間の直接リンク（またはトンネル）が存在する場合のUPnP、またはNAT-PMPプロキシは、溶液であってもよいです。代替ソリューションは、CGNの着信ポートマッピングを設定するには、Webインタフェースです。プロトコルの開発は、ポート制御プロトコル[PCP]を経由して一般化し、自動化されたソリューションを提供するために、IETFで進行中です。
Note that such an interface effectively makes public what was previously a private management interface and this raises security concerns that must be addressed.
そのようなインタフェースは、効果的に公共のものを以前にプライベート管理インターフェイスだったし、これが取り組まなければならないセキュリティ上の懸念を提起作ることに注意してください。
For port-range solutions, port forwarding capabilities may still be present at the CPE, with the limitation that the open incoming port must be within the allocated port range (for instance, it is not possible to open port 5002 for incoming connections if port 5002 is not within the allocated port range).
ポート範囲のソリューションのため、ポートフォワーディング機能はまだ開いて受信ポートがポート5002た場合（例えば、着信接続をポート5002を開くことができない、割り当てられたポート範囲内でなければならないという制限で、CPEで存在してもよいです）に割り当てられたポート範囲内ではありません。
Using the UPnP semantic, an application asks "I want to use port number X, is that OK?", and the answer is yes or no. If the answer is no, the application will typically try the next port in sequence, until it either finds one that works or gives up after a limited number of attempts. UPnP IGD 1.0 has no way to redirect the application to use another port number. UPnP IGD 2.0 improves this situation and allows for allocation of any available port.
セマンティックのUPnPを使用して、アプリケーションは「私はポート番号Xを使用することをOKです？」尋ねると、答えはyesまたはno。答えはノーであるならば、それは動作しますか試みの限られた数の後に与えてくれるものを見つけるのいずれかまで、アプリケーションは通常、シーケンス内の次のポートをしようとします。 UPnPのIGD 1.0は、別のポート番号を使用するようにアプリケーションをリダイレクトする方法がありません。 UPnPのIGD 2.0は、この状況を改善し、使用可能な任意のポートの割り当てが可能になります。
NAT-PMP enables the NAT to redirect the requesting application to a port deemed to be available for use by the NAT state mapping table.
NAT-PMPポートがNAT状態マッピングテーブルによる使用のために利用可能であると考えを要求するアプリケーションをリダイレクトするNATを可能にします。
Once an IPv4-address sharing mechanism is in place, inbound connections to well-known port numbers will not work in the general case. Any application that is not port-agile cannot be expected to work. Some workaround (e.g., redirects to a port-specific URI) could be deployed given sufficient incentives. There exist several proposals for 'application service location' protocols that would provide a means of addressing this problem, but historically these proposals have not gained much deployment traction.
IPv4のアドレス共有メカニズムが配置されると、既知のポート番号への着信接続は、一般的なケースでは動作しません。ポートアジャイルではない任意のアプリケーションが動作するように期待することはできません。いくつかの問題を回避するには、（例えば、ポート固有のURIにリダイレクト）与えられた十分なインセンティブを導入することができます。そこにこの問題に対処する手段を提供する「アプリケーションサービスの場所のプロトコールのためのいくつかの提案が存在するが、歴史的にこれらの提案は非常に展開トラクションを得ていません。
For example, the use of DNS SRV records [RFC2782] provides a potential solution for subscribers wishing to host services in the presence of a shared-addressing scheme. SRV records make it possible to specify a port value related to a service, thereby making services accessible on ports other than the well-known ports. It is worth noting that this mechanism is not applicable to HTTP and many other protocols.
たとえば、DNS SRVレコード[RFC2782]の使用は、共有アドレス指定方式の存在下でサービスをホストしたい加入者のための潜在的なソリューションを提供します。 SRVレコードは、それが可能にすることにより、よく知られたポート以外のポート上のサービスにアクセスすること、サービスに関連するポートの値を指定するために作ります。それは、このメカニズムは、HTTPおよび他の多くのプロトコルには適用できないことは注目に値します。
Port discovery using a UDP port to discover a service available on a corresponding TCP port, either through broadcast, multicast, or unicast, is a commonly deployed mechanism. Unsolicited inbound UDP will be dropped by address sharing mechanisms as they have no live mapping to enable them to forward the packet to the appropriate host. Address sharing thereby breaks this service discovery technique.
いずれかのブロードキャスト、マルチキャスト、またはユニキャストを通じて、対応するTCPポート上で利用可能なサービスを発見するためにUDPポートを使用して、ポートの発見は、一般的に展開するメカニズムです。彼らは、適切なホストにパケットを転送することを可能にするには、noライブのマッピングを持っていないとして、未承諾のインバウンドUDPは、アドレス共有メカニズムによって破棄されます。アドレス共有は、それによって、このサービス発見技術を破ります。
Address sharing solutions will have an impact on the following types of applications:
アドレス共有ソリューションは、次のタイプのアプリケーションに影響を与えます。
o Applications that establish inbound communications - These applications will have to ensure that ports selected for inbound communications are either within the allocated range (for port-range solutions) or are forwarded appropriately by the CGN (for CGN-based solutions). See Section 5.2 for more discussion.
インバウンド通信を確立するアプリケーションO - これらのアプリケーションは、インバウンド通信に選択されたポートは、（ポートレンジソリューション用）に割り当てられた範囲内または（CGNベースのソリューションの場合）CGNによって適切に転送されるのいずれかであることを保証しなければなりません。より多くの議論については、セクション5.2を参照してください。
o Applications that carry address and/or port information in their payload - Where translation of port and/or address information is performed at the IP and transport layers by the address sharing solution, an ALG will also be required to ensure application-layer data is appropriately modified. Note that ALGs are required in some cases, and in many other cases end-to-end protocol mechanisms have developed to work around a lack of ALGs in address translators, to the point of it being preferable to avoid any support in the NAT.
そのペイロード内のアドレスおよび/またはポート情報を運ぶOアプリケーション - ポートの翻訳および/またはアドレス情報がアドレス共有ソリューションによってIPとトランスポート層で行われる場合、ALGは、アプリケーション層のデータを確保する必要がありますされています適切に修正。 ALGは、いくつかのケースで必要とされていることに注意してください、そして他の多くの例では、エンドツーエンドのプロトコルメカニズムは、それがNATのあらゆるサポートを避けることが望ましいという点まで、アドレス変換でのALGの不足を回避するために開発しました。
o Applications that use fixed ports - See Section 5.2.2 for more discussion.
固定ポートを使用するOアプリケーション - より多くの議論については、セクション5.2.2を参照してください。
o Applications that do not use any port (e.g., ICMP echo) - Such applications will require special handling -- see Section 9 for more discussion.
O任意のポートを使用しないアプリケーションは、（例えば、ICMPエコーは） - このようなアプリケーションには、特別な処理が必要になります - より多くの議論については、セクション9を参照してください。
o Applications that assume the uniqueness of source addresses (e.g., IP address as identifier) - Such applications will fail to operate correctly in the presence of multiple, discrete, simultaneous connections from the same source IP address.
送信元アドレスの一意性を仮定Oアプリケーションは、（例えば、識別子としてIPアドレス） - このようなアプリケーションは、同一の送信元IPアドレスから複数の、別個、同時接続の存在下で正常に動作しないであろう。
o Applications that explicitly prohibit concurrent connections from the same address - Such applications will fail when multiple subscribers sharing an IP address attempt to use them simultaneously.
IPアドレスの試みを共有する複数の加入者が同時にそれらを使用する場合には、このようなアプリケーションは失敗します - 明示的に同じアドレスからの同時接続を禁止Oアプリケーション。
o Applications that do not use TCP or UDP for transport - All IP-address sharing mechanisms proposed to date are limited to TCP, UDP, and ICMP, thereby preventing end-users from fully utilizing the Internet (e.g., SCTP, DCCP, RSVP, protocol 41 (IPv6-over-IPv4), protocol 50 (IPsec ESP)).
輸送のためにTCPまたはUDPを使用していないOアプリケーション - これまでに提案されているすべてのIPアドレスを共有するメカニズムは、それによって完全にインターネットを利用することから、エンドユーザーを防止し、TCP、UDP、およびICMPに限定されている（例えば、SCTP、DCCP、RSVP、プロトコル41（IPv6のオーバーのIPv4）、プロトコル50（のIPsec ESP））。
Applications already frequently implement mechanisms in order to circumvent the presence of NATs (typically CPE NATs):
アプリケーションは、既にしばしばNATを（典型的にはCPEのNAT）の存在を回避するために、メカニズムを実装します。
o Application Layer Gateways (ALGs): Many CPE devices today embed ALGs that allow applications to behave correctly despite the presence of NAT on the CPE. When the NAT belongs to the subscriber, the subscriber has flexibility to tailor the device to his or her needs. For CGNs, subscribers will be dependent on the set of ALGs that their service provider makes available. For port-range solutions, ALGs will require modification to deal with the port-range restriction, but will otherwise have the same capabilities as today. Note that ALGs are required in some cases, and in many other cases end-to-end protocol mechanisms have developed to work around a lack of ALGs, to the point of it being preferable to avoid any support in the NAT.
Oアプリケーションレイヤゲートウェイ（ALG）：アプリケーションがCPEにNATが存在するにもかかわらず、正しく動作することができます今日はのALGを埋め込む多くのCPEデバイス。 NATは、加入者に属する場合、加入者は、彼または彼女のニーズにデバイスを調整するための柔軟性を持っています。 CGNをするために、加入者は自分のサービスプロバイダが利用できるようにするのALGのセットに依存することになります。ポート範囲のソリューションについて、のALGは、ポート範囲制限に対処するための修正が必要になりますが、それ以外、今日と同じ機能を持つことになります。 ALGは、いくつかのケースで必要とされていることに注意してください、そして他の多くの例では、エンドツーエンドのプロトコルメカニズムは、それがNATのあらゆるサポートを避けることが望ましいという点まで、のALGの不足を回避するために開発しました。
o NAT Traversal Techniques: There are several commonly deployed mechanisms that support operating servers behind a NAT by forwarding specific TCP or UDP ports to specific internal hosts ([UPnP-IGD], [NAT-PMP], and manual configuration). All of these mechanisms assume the NAT's WAN address is a publicly routable IP address, and fail to work normally when that assumption is wrong. There have been attempts to avoid that problem by automatically disabling the NAT function and bridging traffic instead upon assignment of a private IP address to the WAN interface (as is required for [Windows-Logo] certification). Bridging (rather than NATting) has other side effects (DHCP requests are served by an upstream DHCP server that can increase complexity of in-home networking).
O NATトラバーサル技術：特定の内部ホストに、特定のTCPやUDPのポートを転送することにより、NATの背後に動作してサーバをサポートし、いくつかの一般的な展開メカニズムがあります（[のUPnP-IGD]、[NAT-PMP]、および手動設定）。これらのメカニズムのすべてがNATのWANアドレスはパブリックにルーティング可能なIPアドレスであると仮定し、その仮定が間違っているとき、正常に動作しません。自動的にNAT機能を無効にすると（[Windowsの-ロゴ]認証のために必要とされるような）の代わりにWANインターフェイスにプライベートIPアドレスの割り当て時にトラフィックをブリッジすることでその問題を回避するための試みがなされてきました。 （というよりも、NATting）ブリッジング（DHCP要求は家庭内ネットワークの複雑さを増すことができ、上流DHCPサーバによって提供されている）他の副作用があります。
IP addresses are frequently used to indicate, with some level of granularity and some level of confidence, where a host is physically located. Using IP addresses in this fashion is a heuristic at best, and is already challenged today by other deployed capabilities, e.g., tunnels. Geo-location services are used by content providers to allow them to conform with regional content licensing restrictions, to target advertising at specific geographic areas, or to provide customized content. Geo-location services are also necessary for emergency services provision. In some deployment contexts (e.g., centralized CGN), shared addressing will reduce the level of confidence and level of location granularity that IP-based geo-location services can provide. Viewed from the content provider, a subscriber behind a CGN geo-locates to wherever the prefix of the CGN appears to be; very often that will be in a different city than the subscriber.
IPアドレスが頻繁にホストが物理的に配置された粒度のいくつかのレベルと信頼のいくつかのレベル、と示すために使用されています。この方法でIPアドレスを使用することで、最高のヒューリスティックで、すでに他の展開能力、例えば、トンネルによって今日に挑戦しています。ジオロケーションサービスは、特定の地理的領域に広告をターゲットにする、またはカスタマイズされたコンテンツを提供するために、地域のコンテンツライセンスの制限に準拠するためにそれらを許可するために、コンテンツプロバイダによって使用されています。ジオロケーションサービスは、緊急サービスの提供のためにも必要です。いくつかの配備状況（例えば、集中CGN）では、アドレッシング共有IPベースのジオロケーションサービスを提供することができる位置粒度の信頼レベルのレベルを減少させます。コンテンツプロバイダ、CGNの接頭辞があるように思われるどこにCGNジオ突き止め背後加入者から見ました。非常に多くの場合、それは、加入者とは別の都市になります。
IP addresses are also used as input to geo-location services that resolve an IP address to a physical location using information from the network infrastructure. Current systems rely on resources such as RADIUS databases and DHCP lease tables. The use of address sharing will prevent these systems from resolving the location of a host based on IP address alone. It will be necessary for users of such systems to provide more information (e.g., TCP or UDP port numbers), and for the systems to use this information to query additional network resources (e.g., Network Address Translation - Protocol Translation (NAT-PT) binding tables). Since these new data elements tend to be more ephemeral than those currently used for geo-location, their use by geo-location systems may require them to be cached for some period of time.
IPアドレスは、ネットワーク・インフラストラクチャからの情報を使用して、物理的な場所にIPアドレスを解決するサービスロケーションジオへの入力として使用されます。現在のシステムは、このようなRADIUSデータベースとDHCPリーステーブルなどのリソースに依存しています。アドレス共有のみを使用するIPアドレスに基づいてホストの場所を解決するから、これらのシステムを防止します。これは、より多くの情報を提供するために、このようなシステムのユーザーのために必要であろう（例えば、TCPやUDPのポート番号）、およびシステムは、追加のネットワークリソースを照会し、この情報を使用するために（例えば、ネットワークアドレス変換 - プロトコル変換（NAT-PT） ）のテーブルを結合。これらの新しいデータ要素は、現在、地理的な位置のために使用されるものよりも短命になりがちので、ジオロケーションシステムによるそれらの使用はしばらくの間キャッシュされるためにそれらを必要とするかもしれません。
Other forms of geo-location will still work as usual.
ジオロケーションの他の形態は、通常どおり動作します。
A slightly different use of an IP address is to calculate the proximity of a connecting host to a particular service delivery point. This use of IP address information impacts the efficient delivery of content to an end-user. If a CGN is introduced in communications and it is far from an end-user connected to it, application performance may be degraded insofar as IP-based geo-proximity is a factor.
IPアドレスのわずかに異なる使用は、特定のサービス配信ポイントに接続するホストの近接性を計算することです。 IPアドレス情報の影響をこのように使用するエンドユーザへのコンテンツの効率的な送達。 CGNは、通信に導入され、それに接続されたエンドユーザから離れている場合、アプリケーションのパフォーマンスがIPベースの地理的近接限り分解され得る因子です。
As large-scale address sharing becomes more commonplace, monitoring the number of unique users of a service will become more complex than simply counting the number of connections from unique IP addresses. While this is a somewhat inexact methodology today due to the widespread use of CPE NAT, it will become a much less useful approach in the presence of widespread large-scale address sharing solutions. In general, all elements that monitor usage or abusage in the chain between a service provider that has deployed address sharing and a content provider will need to be upgraded to take account of the port value in addition to IP addresses.
大規模なアドレスの共有がより一般的になるにつれて、サービスのユニークユーザー数を監視することは、単純にユニークなIPアドレスからの接続の数を数えるよりも複雑になります。これはCPE NATの普及のために、やや不正確な方法論今日ですが、それは広範囲に大規模なアドレス共有ソリューションの存在にあまり有用なアプローチとなります。一般的には、アドレスの共有やコンテンツプロバイダを展開しているサービスプロバイダ間のチェーンでの使用やabusageを監視するすべての要素は、IPアドレスに加え、ポート値を考慮してアップグレードする必要があります。
ICMP does not include a port field and is consequently problematic for address sharing mechanisms. Some ICMP message types include a fragment of the datagram that triggered the signal to be sent, which is assumed to include port numbers. For some ICMP message types, the Identifier field has to be used as a de-multiplexing token. Sourcing ICMP echo messages from hosts behind an address sharing solution does not pose problems, although responses to outgoing ICMP echo messages will require special handling, such as making use of the ICMP Identifier value to route the response appropriately.
ICMPはポートフィールドが含まれており、アドレス共有機構の結果、問題があるものではありません。いくつかのICMPメッセージタイプは、ポート番号が含まれているものとする送信される信号をトリガし、データグラムの断片を含みます。いくつかのICMPメッセージタイプのために、識別子フィールドは、逆多重化トークンとして使用されなければなりません。発信ICMPエコーメッセージへの応答は、応答適切にルーティングするためにICMP識別子値を利用するように、特別な処理を必要とするが、アドレス共有ソリューションの背後にあるホストから調達ICMPエコーメッセージは、問題を提起しません。
For inbound ICMP there are two cases. The first case is that of ICMP sourced from outside the network of the address sharing solution provider. Where ICMP messages include a fragment of an outgoing packet including port numbers, it may be possible to forward the packet appropriately. In addition to these network signaling messages, several applications (e.g., peer-to-peer applications) make use of ICMP echo messages that include no hints that could be used to route the packet correctly. Measurements derived by such applications in the presence of an address sharing solution will be erroneous or fail altogether. The second case is that of ICMP sourced from within the network of the address sharing solution provider (e.g., for network management, signaling, and diagnostic purposes). In this case, ICMP can be routed normally for CGN-based solutions owing to the presence of locally unique private IP addresses for each CPE device. For port-range solutions, ICMP echo messages will not be routable without special handling, e.g., placing a port number in the ICMP Identifier field, and having port-range routers make routing decisions based upon that field.
インバウンドICMPのために2つのケースがあります。最初のケースは、ICMPのアドレス共有ソリューションプロバイダのネットワークの外部から供給することです。 ICMPメッセージは、ポート番号を含む発信パケットの断片を含む場合、適切にパケットを転送することも可能です。これらのネットワークシグナリングメッセージに加えて、いくつかのアプリケーション（例えば、ピアツーピアアプリケーション）は、パケットを正しくルーティングするために使用することができないヒントが含まれていないICMPエコーメッセージを利用します。アドレス共有溶液の存在下でこのようなアプリケーションによって誘導される測定値が誤っているか、完全に失敗します。第二の場合は、ICMPの（例えば、ネットワーク管理のために、シグナリング、および診断目的）アドレスを共有ソリューションプロバイダのネットワーク内から供給することです。この場合、ICMPは、各CPEデバイスのためのローカルで一意のプライベートIPアドレスが存在するためCGNベースのソリューションのために正常にルーティングすることができます。ポート範囲のソリューションのため、ICMPエコーメッセージが特別な処理なしでルーティング可能ではありません、例えば、ICMP識別子フィールドにポート番号を確定し、ポート範囲のルータを有するそのフィールドに基づいてルーティング決定を行います。
Considerations related to ICMP message handling in NAT-based environments are specified in [RFC5508].
NATベースの環境でのICMPメッセージの処理に関連する考察は[RFC5508]で指定されています。
In applications where the end hosts are attempting to use path MTU Discovery [RFC1191] to optimize transmitted packet size with underlying network MTU, shared addressing has a number of items that must be considered. As covered in Section 9, ICMP "Packet Too Big" messages must be properly translated through the address sharing solution in both directions. However, even when this is done correctly, MTU can be a concern. Many end hosts cache information that was received via Path MTU Discovery (PMTUD) for a certain period of time. If the MTU behind the address sharing solution is inconsistent, the public end host may have the incorrect MTU value cached. This may cause it to send packets that are too large, causing them to be dropped if the DF (Don't Fragment) bit is set, or causing them to be fragmented by the network, increasing load and overhead. Because the host eventually will reduce MTU to the lowest common value for all hosts behind a given public address, it may also send packets that are below optimal size for the specific connection, increasing overhead and reducing throughput.
エンドホストは、基礎となるネットワークMTUで送信されたパケット・サイズを最適化するために、パスMTU探索[RFC1191]を使用しようとしているアプリケーションでは、アドレッシングを考慮しなければならないアイテムの数を有する共用。第9章で説明したよう、ICMP「パケット過大」メッセージが適切に両方向のアドレス共有ソリューションによって翻訳されなければなりません。しかし、これが正しく行われている場合でも、MTUが心配することができます。多くのエンドホストは、一定期間のためのパスMTU探索（PMTUD）を介して受信された情報をキャッシュします。アドレス共有ソリューションの背後にあるMTUが矛盾している場合は、公共のエンドホストが誤ったMTU値がキャッシュされています。これはDF（しないでくださいフラグメント）ビットがセットされている場合は、それらがドロップさせる、またはそれらがネットワークによって断片化させる、負荷およびオーバーヘッドの増加、大きすぎるパケットを送信するためにそれを引き起こす可能性があります。ホストは最終的に、所与のパブリックアドレスの背後にあるすべてのホストの最低共通の値にMTUを減少させるので、それはまた、オーバーヘッド増加とスループットを低下させる、特定の接続のための最適なサイズを下回っているパケットを送信することができます。
This issue also generates a potential attack vector -- a malevolent user could send an ICMP "Packet Too Big" (Type 3, Code 4) message indicating a Next-Hop MTU of anything down to 68 octets. This value will be cached by the off-net server for all subscribers sharing the address of the malevolent user. This could lead to a denial of service (DoS) against both the remote server and the large-scale NAT device itself (as they will both have to handle many more packets per second).
この問題はまた、潜在的な攻撃ベクトルを生成する - 悪意を持ったユーザーで68オクテットまで何のネクストホップMTUを示すICMP「パケット過大」（タイプ3、コード4）メッセージを送信することができます。この値は、悪意のあるユーザーのアドレスを共有するすべての加入者のためのオフネットサーバーによってキャッシュされます。 （彼らは両方の毎秒より多くのパケットを処理する必要がありますように）これは、リモートサーバーとの大規模NATデバイス自体の両方に対するサービス拒否（DoS）につながる可能性があります。
When a packet is fragmented, transport-layer port information (either UDP or TCP) is only present in the first fragment. Subsequent fragments will not carry the port information and so will require special handling. In addition, the IP Identifier may no longer be unique as required by the receiver to aid in assembling the fragments of a datagram.
パケットが断片化されている場合、トランスポート層ポート情報（UDPまたはTCP）は、最初のフラグメントにのみ存在します。後続のフラグメントは、ポート情報を運ぶことはありませんので、特別な処理が必要になります。データグラムの断片の組み立てを補助するために受信機によって要求されるように加えて、IP識別子はもはや固有でなくてもよいです。
In many jurisdictions, service providers are legally obliged to provide the identity of a subscriber upon request to the appropriate authorities. Such legal requests have traditionally included the source IPv4 address and date (and usually the time), which is sufficient information when subscribers are assigned IPv4 addresses for a long duration.
多くの国では、サービスプロバイダは、法的に適切な当局への要請に応じて、加入者の身元を提供する義務があります。このような法的要求は、伝統的に、加入者が長時間のIPv4アドレスが割り当てられている場合、十分な情報である送信元IPv4アドレスと日付（通常は時間）、含まれています。
However, where one public IPv4 address is shared between several subscribers, the IPv4 address no longer uniquely identifies a subscriber. There are two solutions to this problem:
つのパブリックIPv4アドレスが、いくつかの加入者間で共有される場合しかし、IPv4アドレスはもはや一意の加入者を識別しません。この問題には、2つのソリューションがあります。
o The first solution is for servers to additionally log the source port of incoming connections and for the legal request to include the source port. The legal request should include the information: [Source IP address, Source Port, Timestamp] (and possibly other information). Accurate time-keeping (e.g., use of NTP or Simple NTP) is vital because port assignments are dynamic. A densely populated CGN could mean even very small amounts of clock skew between a third party's server and the CGN operator will result in ambiguity about which customer was using a specific port at a given time.
O第一の溶液は、さらに、着信接続の送信元ポートを記録するサーバーのソースポートを含むように法的要求するためのものです。 [ソースIPアドレス、送信元ポート、タイムスタンプ]（そしておそらく他の情報）：法律上の要求は、情報を含める必要があります。ポート割り当ては動的であるため、正確なタイムキーピング（例えば、NTPまたはシンプルNTPの使用）が不可欠です。人口密度の高いCGNは、顧客が特定の時間に特定のポートを使用していたかについて曖昧になり、第三者のサーバとCGNのオペレータ間のクロック・スキューのも、非常に少量を意味するかもしれません。
o The second solution considers it unrealistic to expect all servers to log the source port number of incoming connections. To deal with this, service providers using IPv4 address sharing may need to log IP destination addresses.
第二の溶液は、それは非現実的な着信接続の送信元ポート番号をログに記録するすべてのサーバーを期待すると考えて、O。これに対処するには、IPv4アドレスの共有を使用して、サービスプロバイダーは、IP宛先アドレスをログに記録する必要があるかもしれません。
Destination logging is imperfect if multiple subscribers are accessing the same (popular) server at nearly the same time; it can be impossible to disambiguate which subscriber accessed the server, especially with protocols that involve several connections (e.g., HTTP). Thus, logging the destination address on the NAT is inferior to logging the source port at the server.
複数の加入者がほぼ同時に同じ（人気の）サーバーにアクセスしている場合は、宛先のログが不完全です。特に、複数の接続（例えば、HTTP）を含むプロトコルで、サーバにアクセスしている加入者明確にすることは不可能であることができます。このように、NAT上の宛先アドレスをログに記録することは、サーバーに送信元ポートをログに劣っています。
If neither solution is used (that is, the server is not logging source port numbers and the NAT is not logging destination IP addresses), the service provider cannot trace a particular activity to a specific subscriber. In this circumstance, the service provider would need to disclose the identity of all subscribers who had active sessions on the NAT during the time period in question. This may be a large number of subscribers.
どちらのソリューションは、（つまり、サーバが送信元ポート番号をログに記録されていないとNATは、宛先のIPアドレスをログに記録されていません）を使用する場合、サービスプロバイダは、特定の加入者に特定の活動を追跡することはできません。この状況では、サービスプロバイダは、当該期間中にNAT上のアクティブなセッションを持っていたすべての加入者の身元を開示する必要があります。これは、加入者の大規模な数であってもよいです。
Address sharing solutions must record and store all mappings (typically during 6-12 months, depending on the local jurisdiction) that they create. If we consider one mapping per session, a service provider should record and retain traces of all sessions created by all subscribers during one year (if the legal storage duration is one year). This may be challenging due to the volume of data requiring storage, the volume of data to repeatedly transfer to the storage location, and the volume of data to search in response to a query.
アドレス共有ソリューションは、彼らが作成することを（ローカル管轄によっては、6-12ヶ月の間、一般的に）すべてのマッピングを記録し、保存する必要があります。私たちはセッションごとに1つのマッピングを考慮した場合（法定保存期間が1年の場合）、サービスプロバイダは、1年の間に、すべての加入者が作成したすべてのセッションのトレースを記録し、保持しなければなりません。これは、クエリに応答して検索するストレージ、ストレージの場所に繰り返し転送するデータの量、およびデータの量を必要とするデータの量に挑戦的であってもよいです。
Address sharing solutions may mitigate these issues to some extent by pre-allocating groups of ports. Then only the allocation of the group needs to be recorded, and not the creation of every session binding within that group. There are trade-offs to be made between the sizes of these port groups, the ratio of public addresses to subscribers, whether or not these groups timeout, and the impact on logging requirements and port randomization security [RFC6056].
アドレス共有ソリューションは、ポートの事前割り当て基によりある程度これらの問題を軽減することができます。その後、グループの唯一の割り当ては、記録する必要があり、すべてのセッションの作成は、そのグループ内で拘束するものではありません。これらのグループがタイムアウトかどうかをこれらのポートグループ、加入者へのパブリックアドレスの割合の大きさの間でなされるトレードオフ、およびロギング要件とポートのランダム化セキュリティ[RFC6056]への影響があります。
Before noting some specific security-related issues caused by large-scale address sharing, it is perhaps worth noting that, in general, address sharing creates a vector for attack amplification in numerous ways. See Section 10 for one example.
大規模なアドレスの共有によって引き起こされるいくつかの特定のセキュリティ関連の問題に注意する前に、一般的には、アドレスの共有がさまざまな方法で攻撃増幅のためのベクトルを作成し、ことは注目におそらく価値があります。一つの例については、セクション10を参照してください。
When an abuse is reported today, it is usually done in the form: IPv4 address X has done something bad at time T0. This is not enough information to uniquely identify the subscriber responsible for the abuse when that IPv4 address is shared by more than one subscriber. Law enforcement authorities may be particularly impacted because of this. This particular issue can be fixed by logging port numbers, although this will increase logging data storage requirements.
虐待が今日報告された場合、通常の形で行われます。IPv4アドレスXは、時刻T0悪い何かを行っています。これは一意にIPv4アドレスを複数の加入者によって共有されている虐待の責任加入者を識別するのに十分な情報ではありません。法執行当局は、特にこのための影響を受ける可能性があります。これは、ログデータのストレージ要件が増加しますが、この特定の問題は、ポート番号をロギングすることで固定することができます。
A number of services on the network today log the IPv4 source addresses used in connection attempts to protect themselves from certain attacks. For example, if a server sees too many requests from the same IPv4 address in a short period of time, it may decide to put that address in a penalty box for a certain time during which requests are denied, or it may require completion of a CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) for future requests. If an IPv4 address is shared by multiple subscribers, this would have unintended consequences in a couple of ways. First it may become the natural behavior to see many login attempts from the same address because it is now shared across a potentially large number of subscribers. Second and more likely is that one user who fails a number of login attempts may block out other users who have not made any previous attempts but who will now fail on their first attempt. In the presence of widespread large-scale address sharing, penalty box solutions to service abuse simply will not work.
ネットワーク上のサービス今日の数は、特定の攻撃から身を守るために接続試行で使用されるIPv4送信元アドレスを記録します。サーバが短期間に同じIPv4アドレスからあまりにも多くのリクエストを見ている場合、それは要求が拒否されている間、一定時間ペナルティボックスにそのアドレスを置くことを決定することができる、またはそれはの完了を必要とするかもしれませんCAPTCHA将来の要求のために（別にコンピュータと人間を伝えるために完全に自動化された公開チューリングテスト）。 IPv4アドレスを複数の加入者によって共有されている場合、これはいくつかの方法で予期しない結果をもたらすでしょう。まず、それが今の加入者の潜在的に大きな数の間で共有されているため、同じアドレスから多くのログイン試行を見るために自然な行動になることがあります。より多くの可能性が高い第二とは、ログイン試行回数を失敗した一人のユーザが任意の以前の試みを行っていないが、誰が、今彼らの最初の試みで失敗します、他のユーザーをブロックすることです。広範囲に大規模なアドレス共有の存在下で、サービスの乱用にペナルティボックスソリューションは、単に動作しません。
In addition, there are web tie-ins into different blacklists that web administrators subscribe to in order to redirect users with infected machines (e.g., detect the presence of a worm) to a URL that says "Hey, your machine is infected!". With address sharing, someone else's worm can interfere with the ability to access the service for other subscribers sharing the same IP address.
また、ウェブタイインは別のブラックリストにあるWeb管理者は、「ねえ、あなたのマシンが感染している！」というURLに（例えば、ワームの存在を検出）感染したマシンにユーザーをリダイレクトするためにに加入していること。アドレス共有を使用すると、誰か他の人のワームは、同じIPアドレスを共有する他の加入者のためのサービスにアクセスする能力を妨げることができます。
Simple address-based identification mechanisms that are used to populate access control lists will fail when an IP address is no longer sufficient to identify a particular subscriber. Including port numbers in access control list definitions may be possible at the cost of extra complexity, and may also require the service provider to make static port assignments, which conflicts with the requirement for dynamic assignments discussed in Section 5.1.
IPアドレスがもはや特定の加入者を識別するのに十分でない場合、アクセス制御リストを設定するために使用される単純なアドレスベースの識別メカニズムが失敗します。アクセス制御リストの定義のポート番号を含めると、余分な複雑さのコストで可能とすることができ、また、5.1節で述べた動的な割り当てのための要件と矛盾する静的ポート割り当てを、行うために、サービスプロバイダが必要な場合があります。
Address or DNS-name-based signatures (e.g., some X.509 signatures) may also be affected by address sharing as the address itself is now a shared token, and the name to address mapping may not be current.
アドレス自体が今や共有トークンであり、マッピングに対処するための名前は、現在でなくてもよいように、アドレスまたはDNS名ベースの署名（例えば、いくつかのX.509シグネチャ）は、アドレスを共有することによって影響を受ける可能性があります。
Another case of identifying abusers has to do with spam blacklisting. When a spammer is behind a CGN or using a port-shared address, blacklisting of their IP address will result in all other subscribers sharing that address having their ability to source SMTP packets restricted to some extent.
乱用者を特定する別の場合は、迷惑メールのブラックリストに関係しています。スパマーがCGNまたはポート共有アドレスを使用しての背後にある場合は、そのIPアドレスのブラックリストはある程度制限SMTPパケットを調達する能力を持っているアドレスを共有する他のすべての加入者になります。
A blind attack that can be performed against TCP relies on the attacker's ability to guess the 5-tuple (Protocol, Source Address, Destination Address, Source Port, Destination Port) that identifies the transport protocol instance to be attacked. [RFC6056] describes a number of methods for the random selection of the source port number, such that the ability of an attacker to correctly guess the 5-tuple is reduced. With shared IPv4 addresses, the port selection space is reduced. Preserving port randomization is important and may be more or less difficult depending on the address sharing solution and the size of the port space that is being manipulated. Allocation of non-contiguous port ranges could help to mitigate this issue.
TCPに対して実行することができブラインド攻撃が攻撃されるトランスポートプロトコルインスタンスを識別する5タプル（プロトコル、送信元アドレス、宛先アドレス、送信元ポート、宛先ポート）を推測する攻撃者の能力に依存しています。 [RFC6056]は低減され、攻撃者の能力を正しく5タプルを推測するように、送信元ポート番号をランダムに選択するための多数の方法が記載されています。共有IPv4アドレスを使用すると、ポート選択スペースが削減されます。ポートランダム化を維持することが重要であり、アドレス共有ソリューションおよび操作されているポート空間のサイズに応じて、多かれ少なかれ困難であろう。非連続ポート範囲の割り当ては、この問題を軽減するのに役立つ可能性があり。
It should be noted that guessing the port information may not be sufficient to carry out a successful blind attack. An in-window TCP Sequence Number (SN) should also be known or guessed. A TCP segment is processed only if all previous segments have been received, except for some Reset segment implementations that immediately process the
ポート情報を推測することは成功したブラインド攻撃を実行するのに十分ではないことに留意すべきです。イン・ウィンドウTCPシーケンス番号（SN）も知られている、または推測する必要があります。 TCPセグメントは、以前のすべてのセグメントが直ちに処理何らかのリセットセグメントの実装を除いて、受信された場合にのみ処理されます
Reset as long as it is within the Window. If SN is randomly chosen, it will be difficult to guess it (SN is 32 bits long); port randomization is one protection among others against blind attacks. There is more detailed discussion of improving TCP's robustness to Blind In-Window Attacks in [RFC5961].
限り、それはウィンドウ内にあるとしてリセットします。 SNがランダムに選択された場合、（SNが32ビット長である）、それを推測することは困難であろう。ポートのランダム化は、盲目の攻撃に対する他の人の中の1つの保護です。 [RFC5961]でブラインドで、ウィンドウの攻撃へのTCPの堅牢性を向上させることのより詳細な議論があります。
The impact of large-scale IP address sharing for IPsec operation should be evaluated and assessed. [RFC3947] proposes a solution to solve issues documented in [RFC3715]. [RFC5996] specifies Internet Key Exchange (IKE) Protocol Version 2, which includes NAT traversal mechanisms that are now widely used to enable IPsec to work in the presence of NATs in many cases. Nevertheless, service providers may wish to ensure that CGN deployments do not inadvertently block NAT traversal for security protocols such as IKE (refer to [NAT-SEC] for more information).
IPsecの動作のための大規模なIPアドレスの共有の影響を評価し、評価されるべきです。 [RFC3947]は、[RFC3715]で文書化の問題を解決するためのソリューションを提案しています。 [RFC5996]は、現在広く多くの場合のNATの存在下で動作するようにIPsecを有効にするために使用されているNATトラバーサルメカニズムを含み、インターネットキー交換（IKE）プロトコルバージョン2は、指定されます。それにもかかわらず、サービスプロバイダーは、CGNの展開が不注意なIKE（詳細については、[NAT-SEC]を参照）などのセキュリティプロトコルのためのNATトラバーサルをブロックしないことを確実にすることを望むかもしれません。
[RFC2827] motivates and discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS attacks that use forged IP addresses. Following this recommendation, service providers operating shared-addressing mechanisms should ensure that source addresses, or source ports in the case of port-range schemes, are set correctly in outgoing packets from their subscribers or they should drop the packets.
[RFC2827]は動機や偽造IPアドレスを使用してDoS攻撃を禁止する入力トラフィックのフィルタリングを使用するための、簡単で効果的、かつ簡単な方法を説明します。この勧告に続き、共有アドレス指定のメカニズムを操作するサービスプロバイダーは、ポート範囲のスキームの場合、その送信元アドレス、または送信元ポートを確保する必要があり、加入者からの発信パケットに正しく設定されているか、彼らがパケットをドロップする必要があります。
If some form of IPv6 ingress filtering is deployed in the broadband network and DS-Lite service is restricted to those subscribers, then tunnels terminating at the CGN and coming from registered subscriber IPv6 addresses cannot be spoofed. Thus, a simple access control list on the tunnel transport source address is all that is required to accept traffic on the internal interface of a CGN.
これらの加入者へのIPv6イングレスフィルタリングのいくつかのフォームは、ブロードバンド・ネットワークに配備され、DS-Liteのサービスが制限されている場合は、CGNで終了すると詐称することはできません登録した加入者のIPv6アドレスからトンネルを。したがって、トンネル転送元アドレスに簡単なアクセス制御リストは、CGNの内部インターフェイス上のトラフィックを受け入れるために必要とされる全てです。
One issue is systems that assume that multiple simultaneous connections to a single IP address implies connectivity to a single host -- such systems may experience unexpected results.
このようなシステムは、予期しない結果が発生する可能性があり - 1つの問題は、単一のIPアドレスへの複数の同時接続は、単一のホストへの接続を意味していることを前提とシステムです。
Another issue is systems that assume that returning to a given IP address means returning to the same physical host, as with stateful transactions. This may also affect cookie-based systems.
もう一つの問題は、与えられたIPアドレスを返すことはステートフル取引と同様に、同一の物理ホストに返す意味と仮定システムです。また、これは、クッキーベースのシステムに影響を与える可能性があります。
[RFC2140] defines a performance optimization for TCP based on sharing state between TCP control blocks that pertain to connections to the same host, as opposed to maintaining state for each discrete connection. This optimization assumes that an address says something about the properties of the path between two hosts, which is clearly not the case if the address in question is shared by multiple hosts at different physical network locations. While CPE NAT today causes problems for sharing TCP control block state across multiple connections to a given IP address, large-scale address sharing will make these issues more severe and more widespread.
[RFC2140]は各離散接続の状態を維持するとは対照的に、同じホストへの接続に関連するTCP制御ブロック間で状態を共有することに基づいてTCPの性能最適化を定義します。この最適化は、アドレスが問題のアドレスが異なる物理ネットワークの場所で複数のホストで共有されている場合、明らかにそうではない2つのホスト間のパスの性質について何かを言うことを想定しています。 CPE NATは本日、特定のIPアドレスに複数の接続間でTCP制御ブロックの状態を共有するための問題を引き起こしますが、大規模なアドレス共有は、これらの問題はより深刻とより広範囲になります。
Many service providers populate forward and reverse DNS zones for the public IPv4 addresses that they allocate to their subscribers. In the case where public addresses are shared across multiple subscribers, such strings are, by definition, no longer sufficient to identify an individual subscriber without additional information.
多くのサービスプロバイダは、前方移入し、パブリックIPv4は、彼らが自分の加入者に割り当てることをアドレス用のDNSゾーンを逆転します。パブリックアドレスは、複数の加入者間で共有されている場合には、そのような文字列は、もはや、定義により、追加情報なしに個々の加入者を識別するのに十分ではありません。
Algorithms used to balance traffic load for popular destinations may be affected by the introduction of address sharing. Where balancing is achieved by deterministically routing traffic from specific source IP addresses to specific servers, imbalances in load may be experienced as address sharing is enabled for some of those source IP addresses. This will require re-evaluation of the algorithms used in the load-balancing design. In general, as the scale of address sharing grows, load-balancing designs will need to be re-evaluated and any assumptions about average load per source IP address revisited.
人気の目的地のためのトラフィック負荷のバランスをとるために使用されるアルゴリズムは、アドレス共有の導入によって影響を受ける可能性があります。バランシングが決定論特定のサーバに特定の送信元IPアドレスからのトラフィックをルーティングすることによって実現されている場合、負荷の不均衡は、アドレスの共有がそれらの送信元IPアドレスのいくつかのために有効になっているとして経験することができます。これは、負荷分散設計に使用されるアルゴリズムの再評価が必要になります。アドレス共有の規模が大きくなるにつれ、一般的には、ロード・バランシング・デザインが再評価され、再訪元IPアドレスあたりの平均負荷に関するいかなる仮定する必要があります。
IPv4 address sharing solutions may interfere with existing IPv4 to IPv6 transition mechanisms, which were not designed with IPv4 shortage considerations in mind. With port-range solutions, for instance, incoming 6to4 packets should be able to find their way from a 6to4 relay to the appropriate 6to4 CPE router, despite the lack of direct port-range information (UDP/TCP initial source port did not pass through the CPE port range translation process). One solution would be for a 6to4 IPv6 address to embed not only an IPv4 address but also a port range value.
IPv4アドレスを共有ソリューションは、念頭に置いたIPv4不足考慮して設計されていないIPv6移行機構、既存のIPv4を妨害し得ます。ポート範囲のソリューションでは、例えば、受信した6to4パケットが直接ポート範囲情報の欠如にもかかわらず、適切な6to4のCPEルータへの6to4リレーから自分の道を見つけることができるはずです（UDP / TCP初期のソースポートが通過しませんでしたCPEポート範囲の翻訳プロセス）。 6to4のIPv6アドレスがIPv4アドレスだけでなく、ポート範囲の値だけでなくを埋め込むために一つの解決策は次のようになります。
Subscribers allocated with private addresses will not be able to utilize 6to4 [RFC3056] to access IPv6, but may be able to utilize Teredo [RFC4380].
プライベートアドレスを割り当てられた加入者は、IPv6へのアクセスに6to4の[RFC3056]を利用することはできませんが、Teredoの[RFC4380]を利用することができるかもしれません。
Some routers enable 6to4 on their WAN link. 6to4 requires a publicly routable IPv4 address. Enabling 6to4 when the apparently public IPv4 WAN address is in fact behind a NAT creates a disconnected IPv6 island.
いくつかのルータはWANリンク上の6to4を有効にします。 6to4のは、公にルーティング可能なIPv4アドレスが必要です。どうやらパブリックIPv4 WANアドレスがNATの背後にある事実にあるときの6to4を有効にすると、切断のIPv6の島を作成します。
In common with all deployments of new network functionality, the introduction of new nodes or functions to handle the multiplexing of multiple subscribers across shared IPv4 addresses could create single points of failure in the network. Any IP address sharing solution should consider the opportunity to add redundancy features in order to alleviate the impact on the robustness of the offered IP connectivity service. The ability of the solution to allow hot swapping from one machine to another should be considered. This is especially important where the address sharing solution in question requires the creation of per-flow state in the network.
新しいネットワーク機能のすべての展開に共通で、共有IPv4アドレスにまたがる複数の加入者の多重化を処理する新しいノードまたは機能の導入は、ネットワーク内の単一障害点を作成することができます。任意のIPアドレス共有ソリューションを提供するIP接続サービスの堅牢性への影響を軽減するために、冗長機能を追加するための機会を検討すべきです。あるマシンから別のマシンのホットスワップを可能とするソリューションの能力を考慮すべきです。問題のアドレス共有ソリューションは、ネットワーク内のフローごとの状態の作成を必要とする場合、これは特に重要です。
In order for hosts to maintain network state in the presence of NAT, keep-alive messages have to be sent at frequent intervals. For battery-powered devices, sending these keep-alive messages can result in significantly reduced battery performance than would otherwise be the case [Mobile_Energy_Consumption].
ホストはNATの存在下で、ネットワークの状態を維持するためには、キープアライブメッセージが頻繁に送信されることがあります。そうでない場合は、[Mobile_Energy_Consumption]とされるよりもバッテリ駆動デバイスの場合、これらのキープアライブメッセージを送信すると、大幅に減少し、電池性能をもたらす可能性があります。
[RFC5135] specifies requirements for a NAT that supports Any Source IP Multicast or Source-Specific IP Multicast. Port-range routers that form part of port-range solutions will need to support similar requirements if multicast support is required.
[RFC5135]は、任意の送信元IPマルチキャストまたはソース固有IPマルチキャストをサポートしているNATのための要件を指定します。ポート・レンジ・ソリューションの一部を形成するポートレンジルータは、マルチキャストサポートが必要な場合は、同様の要件をサポートする必要があります。
IP address sharing within the context of Mobile IP deployments (in the home network and/or in the visited network) will require Home Agents and/or Foreign Agents to be updated so as to take into account the relevant port information. There may also be issues raised when an additional layer of encapsulation is required thereby causing, or increasing the need for, fragmentation and reassembly.
アカウントに関連するポート情報を取り込むように、モバイルIPの展開（ホームネットワーク内および/または訪問先ネットワーク内）のコンテキスト内でIPアドレスの共有を更新するホームエージェントおよび/または外国のエージェントが必要になります。また、カプセル化の追加の層を引き起こし、又は断片化と再アセンブリの必要性を増加させる、それによって必要とされるときに発生する問題があってもよいです。
Issues for Mobile-IP in the presence of NAT are discussed in [NAT64-MOBILITY].
NATの存在下でのモバイルIPのための問題は[NAT64移動度]で議論されています。
This memo does not define any protocol and therefore creates no new security issues. Section 13 discusses some of the security and identity-related implications of IP address sharing.
このメモは、任意のプロトコルを定義するため、新たなセキュリティ問題を作成しません。第13節は、IPアドレスの共有のセキュリティとアイデンティティ関連の含意のいくつかを説明します。
This document is based on sources co-authored by J.L. Grimault and A. Villefranque of France Telecom.
この文書は、J。L.グリモーとフランステレコムのA. Villefranqueによる共著のソースに基づいています。
This memo was partly inspired by conversations that took place as part of Internet Society (ISOC) hosted roundtable events for operators and content providers deploying IPv6. Participants in those discussions included John Brzozowski, Leslie Daigle, Tom Klieber, Yiu Lee, Kurtis Lindqvist, Wes George, Lorenzo Colliti, Erik Kline, Igor Gashinsky, Jason Fesler, Rick Reed, Adam Bechtel, Larry Campbell, Tom Coffeen, David Temkin, Pete Gelbman, Mark Winter, Will Charnock, Martin Levy, Greg Wood, and Christian Jacquenet.
このメモは、部分的にインターネット協会（ISOC）の一環として行われたIPv6を導入する事業者やコンテンツプロバイダのための円卓会議のイベントを主催し、会話に触発されました。それらの議論の参加者はジョンBrzozowski、レスリーDaigle氏、トムKlieber、耀輝リー、カーティスLindqvist、ウェス・ジョージ、ロレンツォColliti、エリック・クライン、イゴールGashinsky、ジェイソンFesler、リック・リード、アダム・ベクテル、ラリー・キャンベル、トムCoffeen、デビッドTemkinを含め、ピートGelbman、マーク・冬、ウィルチャーノック、マーティン・レヴィ、グレッグ・ウッド、そしてクリスチャンJacquenet。
The authors are also grateful to Christian Jacquenet, Iain Calder, Joel Halpern, Brian Carpenter, Gregory Lebovitz, Bob Briscoe, Marcelo Bagnulo, Dan Wing, and Wes George for their helpful comments and suggestions for improving the document.
著者らはまた、ドキュメントを改善するための彼らの役に立つコメントと提案のためのキリスト教のJacquenet、イアン・カルダー、ジョエル・ハルパーン、ブライアン・カーペンター、グレゴリーLebovitz、ボブ・ブリスコー、マルセロBagnulo、ダン・ウィング、およびウェス・ジョージに感謝しています。
This memo was created using the xml2rfc tool.
このメモはxml2rfcツールを使用して作成されました。
[A+P] Bush, R., "The A+P Approach to the IPv4 Address Shortage", Work in Progress, February 2011.
[A + P]ブッシュ、R.、進歩、2011年2月で、作業 "IPv4アドレスの不足にA + Pアプローチ"。
[CGN_Viability] Alcock, S., "Research into the Viability of Service-Provider NAT", 2008, <http://www.wand.net.nz/~salcock/ someisp/flow_counting/result_page.html>.
[CGN_Viability]オールコック、S.、2008年 "サービス・プロバイダNATの生存率の研究"、<http://www.wand.net.nz/~salcock/ someisp / flow_counting / result_page.html>。
[DS-Lite] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", Work in Progress, May 2011.
[DS-Liteの]デュラン、A.、Droms、R.、Woodyatt、J.、およびY.リー、 "デュアルスタックLiteのブロードバンドの展開に続いてIPv4の枯渇"、進歩、2011年5月での作業。
[IANA_Ports] IANA, "Port Numbers", <http://www.iana.org>.
[IANA_Ports] IANA、 "ポート番号"、<http://www.iana.org>。
[IPv4_Pool] ICANN, "Available Pool of Unallocated IPv4 Internet Addresses Now Completely Emptied", February 2011, <http://icann.org/en/news/releases/ release-03feb11-en.pdf>.
[IPv4_Pool] ICANN、 "今、完全に空に未割り当てのIPv4インターネットアドレスの利用可能なプール"、2011年2月、<http://icann.org/en/news/releases/リリース-03feb11を-en.pdf>。
[LSN-REQS] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common requirements for IP address sharing schemes", Work in Progress, March 2011.
[LSN-REQS]ペロー、S.、山形、I.、宮川、S.、中川、A.、およびH.芦田、 "IPアドレス共有スキームのための一般的な要件"、進歩、2011年3月に作業。
[Mobile_Energy_Consumption] Haverinen, H., Siren, J., and P. Eronen, "Energy Consumption of Always-On Applications in WCDMA Networks", April 2007, <http://research.nokia.com/node/5597>.
[Mobile_Energy_Consumption] Haverinen、H.、サイレン、J.、およびP. Eronen、 "WCDMAネットワークにおける常時オンのアプリケーションのエネルギー消費"、2007年4月、<http://research.nokia.com/node/5597>。
[NAT-PMP] Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", Work in Progress, April 2008.
[NAT-PMP]チェシャー、S.、 "NATポートマッピングプロトコル（NAT-PMP）"、進歩、2008年4月の作業。
[NAT-SEC] Gont, F. and P. Srisuresh, "Security implications of Network Address Translators (NATs)", Work in Progress, October 2009.
[NAT-SEC] Gont、F.とP. Srisureshは、進歩、2009年10月に、仕事を "ネットワークのセキュリティへの影響は、翻訳者（NATのを）アドレス"。
[NAT444] Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., and H. Ashida, "NAT444", January 2011.
「なＴ４４４」 やまがた、 い。、 しらさき、 Ｙ。、 なかがわ、 あ。、 やまぐち、 Ｊ。、 あんｄ Ｈ。 あしだ、 ”なＴ４４４”、 じゃぬあｒｙ ２０１１。
[NAT64-MOBILITY] Haddad, W. and C. Perkins, "A Note on NAT64 Interaction with Mobile IPv6", Work in Progress, March 2011.
[NAT64-MOBILITY]ハダッド、W.とC.パーキンス、 "モバイルIPv6とNAT64の相互作用に関する注意事項"、進歩、2011年3月に作業。
[PCP] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", Work in Progress, May 2011.
[PCP]ウイング、D.、エド。、チェシャー、S.、Boucadair、M.、Penno、R.、およびP.セルカーク、 "ポート制御プロトコル（PCP）"、進歩、2011年5月での作業。
[PORT-RANGE] Boucadair, M., Levis, P., Bajko, G., and T. Savolainen, "IPv4 Connectivity Access in the Context of IPv4 Address Exhaustion: Port Range based IP Architecture", Work in Progress, July 2009.
[PORT-RANGE] Boucadair、M.、リーバイス、P.、Bajko、G.、およびT. Savolainenの、 "IPアドレス枯渇問題のコンテキストにおけるIPv4の接続アクセス：ポート範囲ベースのIPアーキテクチャ" が進行中で働いて、2009年7月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", RFC 1337, May 1992.
"TCPでのTIME-WAITの暗殺の危険" [RFC1337]ブレーデン、B.、RFC 1337、1992年5月。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994.
[RFC1700]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、RFC 1700、1994年10月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997.
[RFC2140]タッチ、J.、 "TCP制御ブロック相互依存"、RFC 2140、1997年4月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh、P.とM.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsenの、A.、いるVixie、P.、およびL. Esibov、 "サービスの場所を特定するためのDNS RR（DNSのSRV）"、RFC 2782、2000年2月。
[RFC2827] 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.
[RFC2827]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス攻撃の敗北拒否"、BCP 38、RFC 2827、2000年5月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993]ハイン、T.、 "NATの建築的意味"、RFC 2993、2000年11月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B.およびK.ムーア、RFC 3056、2001年2月 "のIPv4クラウドを介したIPv6ドメインの接続"。
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[RFC3232]レイノルズ、J.、 "番号が割り当てられ：RFC 1700は、オンラインデータベースで置き換えられる"、RFC 3232、2002年1月。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715] Aboba、B.とW.ディクソン、 "IPsecでネットワークアドレス変換（NAT）の互換性の要件"、RFC 3715、2004年3月。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947] Kivinen、T.、Swander、B.、Huttunen、A.、およびV.ボルペ、 "IKEにおけるNATトラバーサルのネゴシエーション"、RFC 3947、2005年1月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380]のHuitema、C.、 "のTeredo：ネットワークアドレス変換を通じてUDP経由トンネリングのIPv6器（NAT）"、RFC 4380、2006年2月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787] Audet、F.とC.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、BCP 127、RFC 4787、2007年1月。
[RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT)", BCP 135, RFC 5135, February 2008.
[RFC5135]ウイング、D.とT.エッカート、BCP 135、RFC 5135、2008年2月、 "ネットワークアドレス変換（NAT）とネットワークアドレスポート翻訳（NAPT）のためのIPマルチキャストの要件"。
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, April 2009.
[RFC5508] Srisuresh、P.、フォード、B.、シバクマー、S.、およびS.グハ、 "ICMPのためのNAT行動要件"、BCP 148、RFC 5508、2009年4月。
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, August 2010.
[RFC5961] Ramaiah、A.、スチュワート、R.、およびM. Dalal、RFC 5961、2010年8月 "ブラインドウィンドウ攻撃に対してTCPのロバスト性を向上させます"。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]カウフマン、C.、ホフマン、P.、ニール、Y.、およびP. Eronen、 "インターネット鍵交換プロトコルバージョン2（IKEv2の）"、RFC 5996、2010年9月。
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, January 2011.
[RFC6056]ラーセン、M.とF. Gont、BCP 156、RFC 6056、2011年1月 "トランスポート・プロトコルポートランダム化のための提言"。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145]のLi、X.、バオ、C.、およびF.ベイカー、 "IP / ICMP翻訳アルゴリズム"、RFC 6145、2011年4月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146] Bagnulo、M.、マシューズ、P.、およびI.バンBeijnum、 "ステートフルNAT64：IPv4のサーバーへのIPv6クライアントからのネットワークアドレスとプロトコル変換"、RFC 6146、2011年4月。
[SAM] Despres, R., "Scalable Multihoming across IPv6 Local-Address Routing Zones Global-Prefix/Local-Address Stateless Address Mapping (SAM)", July 2009.
[SAM]デプレ、R.、「グローバル・プレフィックス/ローカルアドレスステートレスアドレスマッピング（SAM）は、IPv6ローカルアドレスルーティングゾーン全体でスケーラブルマルチホーミング」、2009年7月。
[UPnP-IGD] UPnP Forum, "Universal Plug and Play (UPnP) Internet Gateway Device (IGD) V 2.0", December 2010, <http://upnp.org/specs/gw/igd2/>.
[UPnPの-IGD] UPnPフォーラム、 "ユニバーサルプラグアンドプレイ（UPnP）インターネットゲートウェイデバイス（IGD）V 2.0"、2010年12月、<http://upnp.org/specs/gw/igd2/>。
[Windows-Logo] Microsoft, "Windows Logo Program Requirements and Policies", 2006, <http://www.microsoft.com/whdc/winlogo/ hwrequirements/default.mspx>.
[Windowsの-ロゴ]マイクロソフト、 "Windowsロゴプログラムの要件とポリシー"、2006年、<http://www.microsoft.com/whdc/winlogo/ hwrequirements / default.mspx>。
Appendix A. Classes of Address Sharing Solution
アドレス共有ソリューションの付録A.クラス
IP address sharing solutions fall into two classes. Either a service-provider-operated NAT function is introduced and subscribers are allocated addresses from [RFC1918] space, or public IPv4 addresses are shared across multiple subscribers by restricting the range of ports available to each subscriber. These classes of solution are described in a bit more detail below.
IPアドレスの共有ソリューションは、2つのクラスに分類されます。いずれかのサービスプロバイダー操作NAT機能が導入され、加入者が各加入者に利用可能なポートの範囲を制限することによって、複数の加入者間で共有されている[RFC1918]空間、またはパブリックIPv4アドレスからアドレスを割り当てられます。溶液のこれらのクラスは、以下にもう少し詳細に記載されています。
o CGN-based solutions: These solutions propose the introduction of a NAPT function in the service provider's network, denoted also as Carrier Grade NAT (CGN), or Large Scale NAT (LSN) [LSN-REQS], or Provider NAT. The CGN is responsible for translating private addresses to publicly routable addresses. Private addresses are assigned to subscribers, a pool of public addresses is assigned to the CGN, and the number of public addresses is smaller than the number of subscribers. A public IPv4 address in the CGN pool is shared by several subscribers at the same time. Solutions making use of a service provider-based NAT include [NAT444] (two layers of NAT) and [DS-Lite] (a single layer of NAT).
O CGNベースのソリューション：これらのソリューションは、キャリアグレードNAT（CGN）、または大規模NAT（LSN）LSN-REQS]、またはプロバイダNATとしても示される、サービスプロバイダのネットワーク内のNAPT機能の導入を提案します。 CGNは、パブリックにルーティング可能なアドレスにプライベートアドレスを変換する責任があります。プライベートアドレスはパブリックアドレスのプールがCGNに割り当てられ、パブリックアドレスの数は、加入者数よりも小さいされ、加入者に割り当てられています。 CGNプール内のパブリックIPv4アドレスは、同時に複数の加入者によって共有されています。サービス・プロバイダ・ベースのNATを利用したソリューションは、[NAT444（NATの二層）および[DS-Liteの（NATの単層）を含みます。
o Port-range solutions: These solutions avoid the presence of a CGN function. A single public IPv4 address is assigned to several subscribers at the same time. A restricted port range is also assigned to each subscriber so that two subscribers with the same IPv4 address have two different port ranges that do not overlap. These solutions are called Address+Port [A+P], or Port Range [PORT-RANGE], or Stateless Address Mapping [SAM].
Oポート・レンジ・ソリューション：これらのソリューションは、CGN機能の存在を避けます。単一のパブリックIPv4アドレスは、同時に複数の加入者に割り当てられています。同一のIPv4アドレスを持つ2人の加入者が重ならない2つの異なるポート範囲を有するように制限されたポート範囲は、各加入者に割り当てられます。これらのソリューションは、アドレス+ポート[A + P]、またはポートの範囲[PORT-RANGE]、またはステートレスアドレスマッピング[SAM]と呼ばれています。
Appendix B. Address Space Multiplicative Factor
付録B.アドレス空間の乗算係数
The purpose of sharing public IPv4 addresses is to increase the addressing space. A key parameter is the factor by which service providers want or need to multiply their IPv4 public address space, and the consequence is the number of subscribers sharing the same public IPv4 address. We refer to this parameter as the address space multiplicative factor; the inverse is called the compression ratio.
パブリックIPv4アドレスを共有する目的は、アドレス空間を増やすことです。重要なパラメータは、サービスプロバイダがしたいか、自分のIPv4パブリックアドレス空間を乗算する必要があることで因子であり、そしてその結果は同じパブリックIPv4アドレスを共有する加入者の数です。私たちは、アドレス空間乗法因子としては、このパラメータを参照してください。逆に、圧縮比と呼ばれています。
The multiplicative factor can only be applied to the subset of subscribers that are eligible for a shared address. The reasons a subscriber cannot have a shared address can be:
倍数因子は、唯一の共有アドレスの対象となる加入者のサブセットに適用することができます。加入者が共有アドレスを持つことができない理由があることができます：
o It would not be compatible with the service to which they are currently subscribed (for example, business subscriber).
Oそれは彼らが現在（例えば、ビジネスの加入者）加入してサービスとの互換性がありません。
o Subscriber CPE is not compatible with the address sharing solution selected by the service provider (for example, it does not handle port restriction for port-range solutions or it does not allow IPv4 in IPv6 encapsulation for the DS-Lite solution), and its replacement is not easy.
O加入者CPEがサービスプロバイダによって選択されたアドレスの共有ソリューションと互換性がない（例えば、それがポート範囲ソリューションのポート制限を処理しないか、DS-Liteの溶液のIPv6カプセル化でのIPv4を許可しない）、およびその交換は簡単ではありません。
Different service providers may have very different needs. A long-lived service provider, whose number of subscribers is rather stable, may have an existing address pool that will only need a small extension to cope with the next few years, assuming that this address pool can be re-purposed for an address sharing solution (small multiplicative factor, less than 10). A new entrant or a new line of business will need a much bigger multiplicative factor (e.g., 1000). A mobile operator may see its addressing needs grow dramatically as the IP-enabled mobile handset market grows.
異なるサービスプロバイダは、非常に異なるニーズを持っていることがあります。その数は、加入者のかなり安定して長寿命のサービスプロバイダは、このアドレスプールは、アドレス共有のために再目的とすることができることを仮定して、唯一の今後数年間に対処するために、小さな拡張が必要になり、既存のアドレスプールを有していても良いです溶液（小乗法因子、10未満）。新規参入や事業の新ラインは、はるかに大きい倍数因子（例えば、1000）が必要になります。携帯電話事業者は、IP対応のモバイル端末市場の成長に合わせてその対処する必要性が飛躍的に成長することがあります。
When the multiplicative factor is large, the average number of ports per subscriber is small. Given the large measured disparity between average and peak port consumption [CGN_Viability], this will create service problems in the event that ports are allocated statically. In this case, it is essential for port allocation to map to need as closely as possible, and to avoid allocating ports for longer than necessary. Therefore, the larger the multiplicative factor, the more dynamic the port assignment has to be.
倍数因子が大きい場合には、加入者当たりのポートの平均数は少ないです。平均およびピークポートの消費量との間に大きな格差の測定[CGN_Viability]を考えると、これはポートが静的に割り当てられている場合に、サービスの問題を作成します。ポート割り当てはできるだけ密接に必要にマップするために、そして必要以上に長くのためのポートを割り当てる避けるために、この場合には、それが不可欠です。したがって、より大きな倍数因子は、より動的なポート割り当てがなければなりません。
Authors' Addresses
著者のアドレス
Mat Ford (editor) Internet Society Geneva Switzerland
マットフォード（エディタ）インターネット協会ジュネーブスイス
EMail: ford@isoc.org
メールアドレス：ford@isoc.org
Mohamed Boucadair France Telecom Rennes 35000 France
モハメド・Boucadairフランステレコム35000レンヌフランス
EMail: mohamed.boucadair@orange-ftgroup.com
メールアドレス：mohamed.boucadair@orange-ftgroup.com
Alain Durand Juniper Networks
アラン・デュランジュニパーネットワークス
EMail: adurand@juniper.net
メールアドレス：adurand@juniper.net
Pierre Levis France Telecom 42 rue des Coutures BP 6243 Caen Cedex 4 14066 France
ピエール・リーバイスフランステレコムBP 42 RUEのCoutures 6243カーンセデックス4 14066フランス
EMail: pierre.levis@orange-ftgroup.com
メールアドレス：pierre.levis@orange-ftgroup.com
Phil Roberts Internet Society Reston, VA USA
フィル・ロバーツインターネット協会レストン、VA USA
EMail: roberts@isoc.org
メールアドレス：roberts@isoc.org