[要約] RFC 6269は、IPアドレス共有に関する問題を議論し、解決策を提案するためのドキュメントです。その目的は、IPアドレス共有の課題を理解し、ネットワークのパフォーマンスやセキュリティを向上させるためのガイドラインを提供することです。
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
IPアドレス共有の問題
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および地域のインターネットレジストリ（RIRS）からのIPv4アドレスの割り当ての完了により、世界中のサービスプロバイダーが、サブスクライバーの1つを割り当てるのに十分なIPv4アドレスがなくなった場合、サブスクライバーに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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
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
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年2月3日[IPv4_pool]に完了しました。地域のインターネットレジストリ（RIR）からの割り当ては、1年後に完了すると予想されますが、正確な日付はレジストリごとに異なります。これにより、世界中のサービスプロバイダーが、サブスクライバーごとに1つを割り当てるのに十分なIPv4アドレスがない場合、サブスクライバーに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アクセスの両方を備えたサブスクライバーでのみ発生します。これにより、共有IPv4アクセスをIPv6アクセスに体系的にバインドする戦略が動機付けられます。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アドレス（[RFC1918]アドレス）を、サービスプロバイダーによって割り当てられたパブリックIPv4アドレスに翻訳する（[RFC1918]アドレス）を埋め込んだ（およびその逆）。したがって、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 A.K.A. LSN for大規模NAT）[LSN-Reqs]、デュアルスタックLite [DS-Lite]、NAT64 [RFC6145] [RFC6146]、アドレスポート（A P）[A P] [ポート-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、Enterprise NAT、および複数のサブスクライバーで個々のIPv4アドレスを共有する非NATソリューションに共通しています。このドキュメントは、これらすべての問題を1か所にまとめることを目的としています。
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」で）（「xx 'を使用して））を示しました。典型的なCPE NATの場合、単一の「X」とマークされた問題が現在既に存在しています。ただし、大規模な住所共有の場合、それらはより深刻で広く普及することが期待できます。
+------------------------------------------------+--------+---------+
| 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：第一党と第三者の共有アドレス指定の問題
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アドレスを共有できる加入者の総数は、アクティブサブスクライバーごとに必要なポートの平均数と、同時にアクティブなサブスクライバーの平均数に関する仮定によって異なります。TCPの設計により、クライアントが時間待機状態のままでいる間にポートを再利用することが望ましくないことを認識することが重要です（通常、接続が終了してから4分後）。タイムウェイト状態は、「高速」または「長い」接続に対する古い重複の危険性を削除します。この接続では、時計駆動型の初期シーケンス数の選択では、古いシーケンススペースと新しいシーケンススペースの重複を防ぐことができません。時間待ち遅延により、接続が再開される前にインターネットで死ぬほど、すべての古い重複セグメント時間が十分になります[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、または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は、[IANA_PORTS]で定義されているように、ポートスペース全体を3つのカテゴリに分類しました。
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]は、平均して、着信接続のためにサブスクライバーが使用するポートはごくわずかであることを示しているようです。ただし、サブスクライバーの大部分は、少なくとも1つのインバウンド接続を受け入れます。
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デバイスの重要かつ広く使用されている機能の1つは、手動で入力ポート（ポート転送）を開くか、ユニバーサルプラグアンドプレイインターネットゲートウェイデバイス（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インターフェイスです。IETFでプロトコル開発が進行中で、ポート制御プロトコル[PCP]を介して一般化された自動化されたソリューションを提供します。
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).
ポートレンジソリューションの場合、ポート転送機能はまだCPEに存在する可能性があり、オープンな着信ポートが割り当てられたポート範囲内にある必要があるという制限があります（たとえば、ポート5002の場合、着信接続のためにポート5002を開くことはできません。割り当てられたポート範囲内ではありません）。
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を使用したい、それは大丈夫ですか？」と尋ねます。答えはYESまたはNOです。回答が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-Address共有メカニズムが整ったら、よく知られているポート番号へのインバウンド接続は、一般的なケースでは機能しません。ポートアジャイルではないアプリケーションは、機能するとは期待できません。十分なインセンティブを考慮して、いくつかの回避策（例：ポート固有の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.
UDPポートを使用したポートディスカバリーは、ブロードキャスト、マルチキャスト、またはユニキャストを通じて、対応するTCPポートで利用可能なサービスを発見することは、一般的に展開されているメカニズムです。未承諾のインバウンド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も必要です修正。ALGSは場合によっては必要であり、他の多くの場合、エンドツーエンドのプロトコルメカニズムは、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.
o 同じアドレスからの同時接続を明示的に禁止するアプリケーション - そのようなアプリケーションは、IPアドレスを共有する複数のサブスクライバーがそれらを同時に使用しようとすると失敗します。
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)).
o TCPまたはUDPを輸送に使用しないアプリケーション - これまで提案されているすべてのIPアドレス共有メカニズムはTCP、UDP、およびICMPに限定されているため、エンドユーザーがインターネットを完全に利用することができません（例：SCTP、DCCP、RSVP、プロトコル41（IPV6-Over-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 アプリケーションレイヤーゲートウェイ（ALGS）：現在、多くのCPEデバイスは、CPEにNATが存在しているにもかかわらず、アプリケーションが正しく動作できるようにするALGを埋め込みました。NATがサブスクライバーに属している場合、サブスクライバーはデバイスを自分のニーズに合わせて調整する柔軟性があります。CGNの場合、サブスクライバーは、サービスプロバイダーが利用できるアルグのセットに依存します。ポートレンジソリューションの場合、ALGSはポートレンジ制限に対処するために修正が必要ですが、それ以外の場合は今日と同じ機能があります。ALGSは場合によっては必要であり、他の多くの場合、ALGの不足を回避するためにエンドツーエンドのプロトコルメカニズムが開発されており、NATでのサポートを回避するために望ましい点があります。
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ポートを特定の内部ホスト（[UPNP-IGD]、[NAT-PMP]、および手動構成）に転送することにより、NATの背後にある動作サーバーをサポートする一般的に展開されたメカニズムがいくつかあります。これらのメカニズムはすべて、NATのWANアドレスが公開可能なIPアドレスであると仮定し、その仮定が間違っている場合に正常に機能しません。NAT機能を自動的に無効にし、Private IPアドレスをWANインターフェイスに割り当てるときにトラフィックを橋渡しすることにより、その問題を回避する試みがありました（[Windows-Logo]認証に必要なように）。ブリッジング（ナットではなく）には他の副作用があります（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が広く使用されているため、今日のやや不正確な方法論ですが、広範な大規模な住所共有ソリューションの存在下では、はるかに有用なアプローチになります。一般に、アドレス共有を展開したサービスプロバイダーとコンテンツプロバイダーの間でチェーン内の使用または虐待を監視するすべての要素は、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メッセージタイプの場合、識別子フィールドを脱3OLxlexingトークンとして使用する必要があります。アドレス共有ソリューションの背後にあるホストからの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エコーメッセージを使用します。アドレス共有ソリューションの存在下でそのようなアプリケーションによって導出された測定は誤っているか、完全に失敗します。2番目のケースは、アドレス共有ソリューションプロバイダーのネットワーク内から供給された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.
最終ホストがPath MTU Discovery [RFC1191]を使用して、基礎となるネットワークMTUを使用して送信されたパケットサイズを最適化しようとしているアプリケーションでは、共有アドレス指定には考慮する必要がある多くのアイテムがあります。セクション9でカバーされているように、ICMPの「パケットが大きすぎる」メッセージは、両方向のアドレス共有ソリューションを介して適切に翻訳する必要があります。ただし、これが正しく行われたとしても、MTUが懸念事項になる可能性があります。多くのエンドホストは、一定期間Path MTU Discovery（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）につながる可能性があります（どちらも1秒あたりより多くのパケットを処理する必要があるため）。
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:
ただし、1つのパブリック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 2番目のソリューションは、すべてのサーバーが着信接続のソースポート番号をログに記録することを期待することを非現実的であると考えています。これに対処するには、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アドレスが複数のサブスクライバーによって共有されている場合、これはいくつかの方法で意図しない結果をもたらします。まず、同じアドレスから多くのログインの試みを見るのは自然な動作になる可能性があります。これは、潜在的に多数のサブスクライバーで共有されているためです。2番目であり、多数のログイン試行に失敗したユーザーが1人のユーザーが、以前の試みを行っていないが、最初の試みで失敗する他のユーザーをブロックする可能性があることです。広範囲にわたる大規模な住所共有の存在下では、サービス乱用のペナルティボックスソリューションは単に機能しません。
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管理者が購読するさまざまなブラックリストにWebタイインがあり、感染したマシンを持つユーザーをリダイレクトする（ワームの存在を検出するなど）、「ねえ、マシンは感染している！」アドレス共有により、他の誰かのワームは、同じ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 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].
ポート情報を推測するだけでは、ブラインド攻撃を成功させるのに十分ではないかもしれないことに注意する必要があります。ウィンドウ内のTCPシーケンス番号（SN）も既知または推測する必要があります。TCPセグメントは、ウィンドウ内にある限りリセットをすぐに処理するリセットセグメントの実装を除き、以前のすべてのセグメントを受信した場合にのみ処理されます。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]は、多くの場合、IPSECが多くの場合NATの存在下で機能するために現在広く使用されているNATトラバーサルメカニズムを含むInternet Key Exchange（IKE）プロトコルバージョン2を指定します。それにもかかわらず、サービスプロバイダーは、IKEなどのセキュリティプロトコル（詳細については[NAT-SEC]を参照）について、CGNの展開が不注意に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アドレスに戻ることは、ステートフルトランザクションと同じ物理ホストに戻ることを意味すると仮定するシステムです。これは、Cookieベースのシステムにも影響を与える可能性があります。
[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リレーから適切な6to4 CPEルーターへの道を見つけることができるはずです（UDP/TCP初期ソースポートは通過しませんでしたCPEポート範囲の翻訳プロセス）。1つのソリューションは、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].
プライベートアドレスで割り当てられた加入者は、6to4 [RFC3056]を使用してIPv6にアクセスすることはできませんが、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の存在下でネットワーク状態を維持するためには、頻繁な間隔でキープアライブメッセージを送信する必要があります。バッテリーを搭載したデバイスの場合、これらのキープアライブメッセージを送信すると、バッテリー性能が大幅に低下する可能性があります。
[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。GrimaultとFrance Telecomの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.
このメモは、IPv6を展開するオペレーターとコンテンツプロバイダー向けに、インターネットソサエティ（ISOC）がホストした円卓会議のイベントの一部として行われた会話に一部触発されました。これらの議論の参加者には、ジョン・ブラゾゾフスキー、レスリー・デイグル、トム・クリーバー、Yiu Lee、Kurtis Lindqvist、Wes George、Lorenzo Colliti、Erik Kline、Igor Gashinsky、Jason Fesler、Rick Leed、Adam Bebtel、Larry Campell、Tomピート・ゲルブマン、マーク・ウィンター、ウィル・チャーノック、マーティン・レヴィ、グレッグ・ウッド、クリスチャン・ジャケネット。
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.
著者は、クリスチャン・ジャックエネット、イアン・カルダー、ジョエル・ハルパーン、ブライアン・カーペンター、グレゴリー・レボビッツ、ボブ・ブリスコ、マルセロ・バグヌロ、ダン・ウィング、ウェス・ジョージにも感謝しています。
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] Bush、R。、「IPv4アドレス不足へのA Pアプローチ」、2011年2月、進行中の作業。
[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] Alcock、S。、「サービスプロバイダーNatの生存率の研究」、2008、<http://www.wand.net.nz/~salcock/ shotisp/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] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4排出後のデュアルスタックLiteブロードバンド展開」、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、「Unallocated IPv4インターネットアドレスの利用可能なプールが完全に空になりました」、2011年2月<http://icann.org/en/news/releases/ release-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] Perreault、S.、Yamagata、I.、Miyakawa、S.、Nakagawa、A。、およびH. Ashida、「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.、Siren、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] Cheshire、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、「ネットワークアドレス翻訳者（NAT）のセキュリティへの影響」、2009年10月、進行中の作業。
[NAT444] Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., and H. Ashida, "NAT444", January 2011.
[Nat444] Yamagata、I.、Shirasaki、Y.、Nakagawa、A.、Yamaguchi、J。、およびH. Ashida、「Nat444」、2011年1月。
[NAT64-MOBILITY] Haddad, W. and C. Perkins, "A Note on NAT64 Interaction with Mobile IPv6", Work in Progress, March 2011.
[NAT64-Mobility] Haddad、W。およびC. Perkins、「Mobile 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] Wing、D.、ed。、Cheshire、S.、Boucadair、M.、Penno、R.、およびP. Selkirk、「ポートコントロールプロトコル（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.、Levis、P.、Bajko、G。、およびT. Savolainen、「IPv4のコンテキストでのIPv4接続アクセス排出：ポートレンジベースのIPアーキテクチャ」、2009年7月の作業。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", RFC 1337, May 1992.
[RFC1337] Braden、B。、「TCPにおける時間待ち暗殺の危険」、RFC 1337、1992年5月。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994.
[RFC1700] Reynolds、J。およびJ. Postel、「割り当てられた番号」、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.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997.
[RFC2140] Touch、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. Holdrege、「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.セニー、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、BCP 38、RFC 2827、2000年5月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993] Hain、T。、「Natの建築的意味」、RFC 2993、2000年11月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] Carpenter、B。およびK. Moore、「IPv4 Cloudsを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[RFC3232] Reynolds、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. Dixon、「Ipsec-Networkアドレス翻訳（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. Volpe、「IKEにおけるNat-Traversalの交渉」、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：ネットワークアドレス翻訳（NAT）を介してUDPを介したIPv6のトンネル」、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. Jennings、「Unicast UDPのネットワークアドレス変換（NAT）行動要件」、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] Wing、D。およびT. Eckert、「ネットワークアドレス翻訳者（NAT）およびネットワークアドレスポート翻訳者（NAPT）のIPマルチキャスト要件」、BCP 135、RFC 5135、2008年2月。
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, April 2009.
[RFC5508] Srisuresh、P.、Ford、B.、Sivakumar、S。、およびS. Guha、「ICMPのNAT行動要件」、BCP 148、RFC 5508、2009年4月。
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, August 2010.
[RFC5961] Ramaiah、A.、Stewart、R。、およびM. Dalal、「Window Inwindow攻撃に対するTCPの堅牢性の改善」、RFC 5961、2010年8月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「Internet Key Exchange Protocolバージョン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] Larsen、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.、Bao、C。、およびF. Baker、「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.、Matthews、P。、およびI. Van Beijnum、「Stateful Nat64：IPv6クライアントからIPv4サーバーへのネットワークアドレスとプロトコル翻訳」、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] Despres、R。、「IPv6ローカルアドレスルーティングゾーン全体でスケーラブルなマルチホミンググローバルプレフィックス/ローカルアドレスステートレスアドレスマッピング（SAM）」、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-Logo] Microsoft、「Windowsロゴプログラムの要件とポリシー」、2006、<http://www.microsoft.com/whdc/winlogo/ hwrequirements/default.mspx>。
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の2層）と[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]、またはポート範囲[ポート範囲]、またはステートレスアドレスマッピング[SAM]と呼ばれます。
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
Mohamed Boucadair France Telecom Rennes 35000 France
Mohamed Boucadair France Telecom Rennes 35000 France
EMail: mohamed.boucadair@orange-ftgroup.com
Alain Durand Juniper Networks
Alain Durand Juniper Networks
EMail: adurand@juniper.net
Pierre Levis France Telecom 42 rue des Coutures BP 6243 Caen Cedex 4 14066 France
ピエール・レビス・フランス・テレコム42 rue des coutures bp 6243 caen cedex 4 14066フランス
EMail: pierre.levis@orange-ftgroup.com
Phil Roberts Internet Society Reston, VA USA
フィルロバーツインターネットソサエティレストン、米国バージニア州
EMail: roberts@isoc.org