RFC 7422 - Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7422
タイトル : RFC 7422 - キャリアグレードのNAT展開でのロギングを削減する確定的アドレスマッピング
翻訳編集 : 自動生成

[要約] RFC 7422は、キャリアグレードNATデプロイメントにおけるログの削減を目的とした、決定論的アドレスマッピングに関するものです。このRFCの目的は、NATデバイスのログの量を減らし、ネットワーク管理者の作業を簡素化することです。

Independent Submission                                         C. Donley
Request for Comments: 7422                                     CableLabs
Category: Informational                                    C. Grundemann
ISSN: 2070-1721                                         Internet Society
                                                              V. Sarawat
                                                           K. Sundaresan
                                                               CableLabs
                                                              O. Vautrin
                                                        Juniper Networks
                                                           December 2014

Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments

キャリアグレードのNAT展開でのロギングを削減する確定的アドレスマッピング

Abstract

概要

In some instances, Service Providers (SPs) have a legal logging requirement to be able to map a subscriber's inside address with the address used on the public Internet (e.g., for abuse response). Unfortunately, many logging solutions for Carrier-Grade NATs (CGNs) require active logging of dynamic translations. CGN port assignments are often per connection, but they could optionally use port ranges. Research indicates that per-connection logging is not scalable in many residential broadband services. This document suggests a way to manage CGN translations in such a way as to significantly reduce the amount of logging required while providing traceability for abuse response. IPv6 is, of course, the preferred solution. While deployment is in progress, SPs are forced by business imperatives to maintain support for IPv4. This note addresses the IPv4 part of the network when a CGN solution is in use.

場合によっては、サービスプロバイダー（SP）は、サブスクライバーの内部アドレスをパブリックインターネットで使用されているアドレス（たとえば、不正行為の応答）にマップできるようにするための法的なログ記録要件があります。残念ながら、Carrier-Grade NAT（CGN）の多くのロギングソリューションでは、動的変換のアクティブなロギングが必要です。 CGNポートの割り当ては接続ごとに行われることがよくありますが、オプションでポート範囲を使用することもできます。調査によると、接続ごとのロギングは、多くの住宅用ブロードバンドサービスでは拡張性がありません。このドキュメントは、乱用応答のトレーサビリティを提供しながら、必要なロギングの量を大幅に削減するような方法でCGN変換を管理する方法を提案します。もちろん、IPv6が推奨されるソリューションです。展開が進行している間、SPはビジネス上の義務によりIPv4のサポートを維持することを余儀なくされます。このノートは、CGNソリューションが使用されているときのネットワークのIPv4部分を扱います。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc7422.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7422で入手できます。

著作権表示

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.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。

Table of Contents

   1. Introduction ....................................................2
      1.1. Requirements Language ......................................4
   2. Deterministic Port Ranges .......................................4
      2.1. IPv4 Port Utilization Efficiency ...........................7
      2.2. Planning and Dimensioning ..................................7
      2.3. Deterministic CGN Example ..................................8
   3. Additional Logging Considerations ...............................9
      3.1. Failover Considerations ...................................10
   4. Impact on the IPv6 Transition ..................................10
   5. Privacy Considerations .........................................11
   6. Security Considerations ........................................11
   7. References .....................................................11
      7.1. Normative References ......................................11
      7.2. Informative References ....................................12
   Acknowledgements ..................................................13
   Authors' Addresses ................................................14

1. Introduction

1. はじめに

It is becoming increasingly difficult to obtain new IPv4 address assignments from Regional/Local Internet Registries due to depleting supplies of unallocated IPv4 address space. To meet the growing demand for Internet connectivity from new subscribers, devices, and service types, some operators will be forced to share a single public IPv4 address among multiple subscribers using techniques such as Carrier-Grade NAT (CGN) [RFC6264] (e.g., NAT444 [NAT444], Dual-Stack Lite (DS-Lite) [RFC6333], NAT64 [RFC6146], etc.). However, address sharing poses additional challenges to operators when considering how they manage service entitlement, public safety requests, or attack/abuse/fraud reports [RFC6269]. In order to identify a specific user associated with an IP address in response to such a request or for service entitlement, an operator will need to map a subscriber's internal source IP address and source port with the global public IP address and source port provided by the CGN for every connection initiated by the user.

未割り当てのIPv4アドレス空間の供給が枯渇するため、地域/ローカルインターネットレジストリから新しいIPv4アドレス割り当てを取得することがますます困難になっています。新しい加入者、デバイス、およびサービスタイプからのインターネット接続に対する需要の高まりに対応するために、一部の事業者は、キャリアグレードNAT（CGN）[RFC6264]（たとえば、 NAT444 [NAT444]、Dual-Stack Lite（DS-Lite）[RFC6333]、NAT64 [RFC6146]など）。ただし、アドレスの共有は、サービス資格、公共安全要求、または攻撃/不正使用/詐欺報告[RFC6269]を管理する方法を検討するときに、オペレーターに追加の課題をもたらします。このような要求に応じて、またはサービス資格のためにIPアドレスに関連付けられた特定のユーザーを識別するために、オペレーターは、サブスクライバーの内部ソースIPアドレスとソースポートを、によって提供されるグローバルパブリックIPアドレスとソースポートにマップする必要があります。ユーザーが開始したすべての接続のCGN。

CGN connection logging satisfies the need to identify attackers and respond to abuse/public safety requests, but it imposes significant operational challenges to operators. In lab testing, we have observed CGN log messages to be approximately 150 bytes long for NAT444 [NAT444] and 175 bytes for DS-Lite [RFC6333] (individual log messages vary somewhat in size). Although we are not aware of definitive studies of connection rates per subscriber, reports from several operators in the US sets the average number of connections per household at approximately 33,000 connections per day. If each connection is individually logged, this translates to a data volume of approximately 5 MB per subscriber per day, or about 150 MB per subscriber per month; however, specific data volumes may vary across different operators based on myriad factors. Based on available data, a 1-million-subscriber SP will generate approximately 150 terabytes of log data per month, or 1.8 petabytes per year. Note that many SPs compress log data after collection; compression factors of 2:1 or 3:1 are common.

CGN接続ログは、攻撃者を特定し、虐待/公衆安全要求に対応する必要性を満たしますが、オペレーターに運用上の大きな課題を課します。ラボテストでは、CGNログメッセージがNAT444 [NAT444]の場合は約150バイト、DS-Lite [RFC6333]の場合は175バイトになることが確認されています（個々のログメッセージのサイズは多少異なります）。加入者ごとの接続率の明確な調査については認識していませんが、米国の複数の事業者からのレポートでは、世帯あたりの平均接続数が1日あたり約33,000接続に設定されています。各接続が個別にログに記録される場合、これは、サブスクライバーあたり1日あたり約5 MB、またはサブスクライバーあたり1か月あたり約150 MBのデータ量に相当します。ただし、特定のデータ量は、無数の要因に基づいて、オペレーターごとに異なる場合があります。利用可能なデータに基づいて、100万のサブスクライバーSPは1か月あたり約150テラバイトのログデータ、または1年あたり1.8ペタバイトを生成します。多くのSPは収集後にログデータを圧縮することに注意してください。 2：1または3：1の圧縮係数が一般的です。

The volume of log data poses a problem for both operators and the public safety community. On the operator side, it requires a significant infrastructure investment by operators implementing CGN. It also requires updated operational practices to maintain the logging infrastructure, and requires approximately 23 Mbps of bandwidth between the CGN devices and the logging infrastructure per 50,000 users. On the public safety side, it increases the time required for an operator to search the logs in response to an abuse report, and it could delay investigations. Accordingly, an international group of operators and public safety officials approached the authors to identify a way to reduce this impact while improving abuse response.

ログデータの量は、オペレーターと公安コミュニティの両方に問題を引き起こします。オペレーター側では、CGNを実装するオペレーターによるインフラストラクチャへの多大な投資が必要です。また、ログインフラストラクチャを維持するために更新された運用方法が必要であり、50,000ユーザーあたりCGNデバイスとログインフラストラクチャの間には約23 Mbpsの帯域幅が必要です。公安面では、乱用報告に応じてオペレーターがログを検索するのに必要な時間が増加し、調査が遅れる可能性があります。したがって、国際的なオペレーターのグループと公安当局は、虐待対応を改善しながらこの影響を減らす方法を特定するために著者にアプローチしました。

The volume of CGN logging can be reduced by assigning port ranges instead of individual ports. Using this method, only the assignment of a new port range is logged. This may massively reduce logging volume. The log reduction may vary depending on the length of the assigned port range, whether the port range is static or dynamic, etc. This has been acknowledged in [RFC6269], which recommends the logging of source ports at the server and/or destination logging at the CGN, and [NAT-LOGGING], which describes information to be logged at a NAT.

個々のポートの代わりにポート範囲を割り当てることにより、CGNロギングの量を減らすことができます。この方法を使用すると、新しいポート範囲の割り当てのみが記録されます。これにより、ログ量が大幅に減少する可能性があります。ログの削減は、割り当てられたポート範囲の長さ、ポート範囲が静的か動的かなどによって異なる場合があります。これは[RFC6269]で認められており、サーバーでの送信元ポートのロギングや宛先のロギングが推奨されていますCGN、および[NAT-LOGGING]には、NATで記録される情報が記述されています。

However, the existing solutions still pose an impact on operators and public safety officials for logging and searching. Instead, CGNs could be designed and/or configured to deterministically map internal addresses to {external address + port range} in such a way as to be able to algorithmically calculate the mapping. Only inputs and configuration of the algorithm need to be logged. This approach reduces both logging volume and subscriber identification times. In some cases, when full deterministic allocation is used, this approach can eliminate the need for translation logging.

ただし、既存のソリューションは依然として、ロギングと検索のためにオペレーターと公安当局に影響を与えます。代わりに、CGNは、アルゴリズムでマッピングを計算できるような方法で、内部アドレスを{外部アドレス+ポート範囲}に決定論的にマッピングするように設計または構成できます。ログに記録する必要があるのは、アルゴリズムの入力と構成のみです。このアプローチにより、ロギングボリュームとサブスクライバー識別時間の両方が削減されます。場合によっては、完全な確定的割り当てが使用されている場合、このアプローチにより、翻訳ログの必要性を排除できます。

This document describes a method for such CGN address mapping, combined with block port reservations, that significantly reduces the burden on operators while offering the ability to map a subscriber's inside IP address with an outside address and external port number observed on the Internet.

このドキュメントでは、このようなCGNアドレスマッピングとブロックポート予約を組み合わせた方法について説明します。これにより、加入者の内部IPアドレスをインターネット上で観察される外部アドレスおよび外部ポート番号にマッピングする機能を提供しながら、オペレーターの負担を大幅に軽減できます。

The activation of the proposed port range allocation scheme is compliant with BEHAVE requirements such as the support of Application-specific functions (APP).

提案されたポート範囲割り当て方式のアクティブ化は、アプリケーション固有機能（APP）のサポートなどのBEHAVE要件に準拠しています。

1.1. Requirements Language

1.1. 要件言語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。

2. Deterministic Port Ranges

2. 確定的なポート範囲

While a subscriber uses thousands of connections per day, most subscribers use far fewer resources at any given time. When the compression ratio (see Appendix B of RFC 6269 [RFC6269]) is low (e.g., the ratio of the number of subscribers to the number of public IPv4 addresses allocated to a CGN is closer to 10:1 than 1000:1), each subscriber could expect to have access to thousands of TCP/UDP ports at any given time. Thus, as an alternative to logging each connection, CGNs could deterministically map customer private addresses (received on the customer-facing interface of the CGN, a.k.a., internal side) to public addresses extended with port ranges (used on the Internet-facing interface of the CGN, a.k.a., external side). This algorithm allows an operator to identify a subscriber internal IP address when provided the public side IP and port number without having to examine the CGN translation logs. This prevents an operator from having to transport and store massive amounts of session data from the CGN and then process it to identify a subscriber.

サブスクライバーは1日あたり数千の接続を使用しますが、ほとんどのサブスクライバーは、常にはるかに少ないリソースを使用します。圧縮率（RFC 6269 [RFC6269]の付録Bを参照）が低い場合（たとえば、CGNに割り当てられたパブリックIPv4アドレスの数に対するサブスクライバーの数の比率は、1000：1よりも10：1に近い）各サブスクライバーは、常に何千ものTCP / UDPポートへのアクセスを期待できます。したがって、各接続をログに記録する代わりに、CGNは顧客のプライベートアドレス（CGNの顧客に面するインターフェイスで受信、別名、内部側）をポート範囲（インターネットに面するインターフェイスで使用）で拡張されたパブリックアドレスに決定的にマッピングできます。 CGN、別名、外部側）。このアルゴリズムにより、オペレーターは、CGN変換ログを調べなくても、パブリック側のIPおよびポート番号が提供されたときにサブスクライバーの内部IPアドレスを識別できます。これにより、オペレーターはCGNから大量のセッションデータを転送して保存し、それを処理して加入者を識別する必要がなくなります。

The algorithmic mapping can be expressed as:

アルゴリズムマッピングは次のように表すことができます。

(External IP Address, Port Range) = function 1 (Internal IP Address)

（外部IPアドレス、ポート範囲）=機能1（内部IPアドレス）

Internal IP Address = function 2 (External IP Address, Port Number) The CGN SHOULD provide a method for administrators to test both mapping functions (e.g., enter an External IP Address + Port Number and receive the corresponding Internal IP Address).

内部IPアドレス=機能2（外部IPアドレス、ポート番号）CGNは、管理者が両方のマッピング機能をテストする方法を提供する必要があります（たとえば、外部IPアドレス+ポート番号を入力し、対応する内部IPアドレスを受信します）。

Deterministic Port Range allocation requires configuration of the following variables:

確定的なポート範囲の割り当てには、次の変数の構成が必要です。

o Inside IPv4/IPv6 address range (I);

o IPv4 / IPv6アドレス範囲の内側（I）;

o Outside IPv4 address range (O);

o IPv4アドレス範囲外（O）;

o Compression ratio (e.g., inside IP addresses I / outside IP addresses O) (C);

o 圧縮率（例：内部IPアドレスI /外部IPアドレスO）（C）;

o Dynamic address pool factor (D), to be added to the compression ratio in order to create an overflow address pool;

o 動的アドレスプール係数（D）。オーバーフローアドレスプールを作成するために圧縮率に追加されます。

o Maximum ports per user (M);

o ユーザーあたりの最大ポート（M）;

o Address assignment algorithm (A) (see below); and

o アドレス割り当てアルゴリズム（A）（下記参照）そして

o Reserved TCP/UDP port list (R)

o 予約済みTCP / UDPポートリスト（R）

Note: The inside address range (I) will be an IPv4 range in NAT444 operation (NAT444 [NAT444]) and an IPv6 range in DS-Lite operation (DS-Lite [RFC6333]).

注：内部アドレス範囲（I）は、NAT444操作のIPv4範囲（NAT444 [NAT444]）およびDS-Lite操作のIPv6範囲（DS-Lite [RFC6333]）になります。

A subscriber is identified by an internal IPv4 address (e.g., NAT44) or an IPv6 prefix (e.g., DS-Lite or NAT64).

サブスクライバーは、内部IPv4アドレス（NAT44など）またはIPv6プレフィックス（DS-LiteまたはNAT64など）で識別されます。

The algorithm may be generalized to L2-aware NAT [L2NAT], but this requires the configuration of the Internal interface identifiers (e.g., Media Access Control (MAC) addresses).

アルゴリズムはL2対応NAT [L2NAT]に一般化できますが、これには内部インターフェイス識別子（メディアアクセスコントロール（MAC）アドレスなど）の構成が必要です。

The algorithm is not designed to retrieve an internal host among those sharing the same internal IP address (e.g., in a DS-Lite context, only an IPv6 address/prefix can be retrieved using the algorithm while the internal IPv4 address used for the encapsulated IPv4 datagram is lost).

アルゴリズムは、同じ内部IPアドレスを共有するホスト間で内部ホストを取得するようには設計されていません（たとえば、DS-Liteコンテキストでは、アルゴリズムを使用してIPv6アドレス/プレフィックスのみを取得できますが、内部IPv4アドレスはカプセル化されたIPv4に使用されます。データグラムが失われます）。

Several address-assignment algorithms are possible. Using predefined algorithms, such as those that follow, simplifies the process of reversing the algorithm when needed. However, the CGN MAY support additional algorithms. Also, the CGN is not required to support all of the algorithms described below. Subscribers could be restricted to ports from a single IPv4 address or could be allocated ports across all addresses in a pool, for example. The following algorithms and corresponding values of A are as follows:

いくつかのアドレス割り当てアルゴリズムが可能です。次のような事前定義されたアルゴリズムを使用すると、必要に応じてアルゴリズムを元に戻すプロセスが簡単になります。ただし、CGNは追加のアルゴリズムをサポートする場合があります。また、CGNは、以下で説明するすべてのアルゴリズムをサポートする必要はありません。たとえば、サブスクライバーは、単一のIPv4アドレスからのポートに制限されたり、プール内のすべてのアドレスにわたってポートが割り当てられたりする可能性があります。次のアルゴリズムと対応するAの値は次のとおりです。

0: Sequential (e.g., the first block goes to address 1, the second block to address 2, etc.).

0：順次（たとえば、最初のブロックはアドレス1に移動し、2番目のブロックはアドレス2に移動する、など）。

1: Staggered (e.g., for every n between 0 and ((65536-R)/(C+D))-1 , address 1 receives ports n*C+R, address 2 receives ports (1+n)*C+R, etc.).

1：互い違い（たとえば、0から（（65536-R）/（C + D））-1までのnごとに、アドレス1はポートn * C + Rを受信し、アドレス2はポート（1 + n）* C +を受信Rなど）。

2: Round robin (e.g., the subscriber receives the same port number across a pool of external IP addresses. If the subscriber is to be assigned more ports than there are in the external IP pool, the subscriber receives the next highest port across the IP pool, and so on. Thus, if there are 10 IP addresses in a pool and a subscriber is assigned 1000 ports, the subscriber would receive a range such as ports 2000-2099 across all 10 external IP addresses).

2：ラウンドロビン（たとえば、サブスクライバーは外部IPアドレスのプール全体で同じポート番号を受け取ります。サブスクライバーに外部IPプール内のポートよりも多くのポートが割り当てられる場合、サブスクライバーはIPで次に高いポートを受け取りますしたがって、プールに10個のIPアドレスがあり、サブスクライバーに1000個のポートが割り当てられている場合、サブスクライバーは、10個のすべての外部IPアドレスにわたってポート2000〜2099などの範囲を受け取ります。

3: Interlaced horizontally (e.g., each address receives every Cth port spread across a pool of external IP addresses).

3：水平方向にインターレースします（たとえば、各アドレスは、外部IPアドレスのプール全体に広がるすべてのC番目のポートを受信します）。

4: Cryptographically random port assignment (Section 2.2 of RFC6431 [RFC6431]). If this algorithm is used, the SP needs to retain the keying material and specific cryptographic function to support reversibility.

4：暗号的にランダムなポート割り当て（RFC6431 [RFC6431]のセクション2.2）。このアルゴリズムを使用する場合、SPは、可逆性をサポートするために、キー情報と特定の暗号化機能を保持する必要があります。

5: Vendor-specific. Other vendor-specific algorithms may also be supported.

5：ベンダー固有。他のベンダー固有のアルゴリズムもサポートされる場合があります。

The assigned range of ports MAY also be used when translating ICMP requests (when rewriting the Identifier field).

割り当てられたポートの範囲は、ICMP要求を変換するとき（識別子フィールドを書き換えるとき）にも使用できます（MAY）。

The CGN then reserves ports as follows:

次に、CGNは次のようにポートを予約します。

1. The CGN removes reserved ports (R) from the port candidate list (e.g., 0-1023 for TCP and UDP). At a minimum, the CGN SHOULD remove system ports [RFC6335] from the port candidate list reserved for deterministic assignment.

1. CGNはポート候補リストから予約済みポート（R）を削除します（たとえば、TCPおよびUDPの場合は0-1023）。少なくとも、CGNは決定論的な割り当て用に予約されているポート候補リストからシステムポート[RFC6335]を削除する必要があります（SHOULD）。

2. The CGN calculates the total compression ratio (C+D), and allocates 1/(C+D) of the available ports to each internal IP address. Specific port allocation is determined by the algorithm (A) configured on the CGN. Any remaining ports are allocated to the dynamic pool.

2. CGNは合計圧縮率（C + D）を計算し、使用可能なポートの1 /（C + D）を各内部IPアドレスに割り当てます。特定のポート割り当ては、CGNで構成されたアルゴリズム（A）によって決定されます。残りのポートは動的プールに割り当てられます。

Note: Setting D to 0 disables the dynamic pool. This option eliminates the need for per-subscriber logging at the expense of limiting the number of concurrent connections that 'power users' can initiate.

注：Dを0に設定すると、動的プールが無効になります。このオプションにより、「パワーユーザー」が開始できる同時接続の数を制限する代わりに、サブスクライバーごとのログ記録が不要になります。

3. When a subscriber initiates a connection, the CGN creates a translation mapping between the subscriber's inside local IP address/port and the CGN outside global IP address/port. The CGN MUST use one of the ports allocated in step 2 for the translation as long as such ports are available. The CGN SHOULD allocate ports randomly within the port range assigned by the deterministic algorithm. This is to increase subscriber privacy. The CGN MUST use the pre-allocated port range from step 2 for Port Control Protocol (PCP, [RFC6887]) reservations as long as such ports are available. While the CGN maintains its mapping table, it need not generate a log entry for translation mappings created in this step.

3. サブスクライバーが接続を開始すると、CGNはサブスクライバーの内部ローカルIPアドレス/ポートとCGN外部グローバルIPアドレス/ポートの間に変換マッピングを作成します。 CGNは、ステップ2で割り当てられたポートの1つを、そのポートが利用可能である限り、変換に使用する必要があります。 CGNは決定論的アルゴリズムによって割り当てられたポート範囲内でランダムにポートを割り当てる必要があります（SHOULD）。これは、加入者のプライバシーを高めるためです。 CGNは、ポートが利用可能である限り、ポート制御プロトコル（PCP、[RFC6887]）の予約に、手順2で事前に割り当てられたポート範囲を使用する必要があります。 CGNはそのマッピングテーブルを維持しますが、この手順で作成された変換マッピングのログエントリを生成する必要はありません。

4. If D>0, the CGN will have a pool of ports left for dynamic assignment. If a subscriber uses more than the range of ports allocated in step 2 (but fewer than the configured maximum ports M), the CGN assigns a block of ports from the dynamic assignment range for such a connection or for PCP reservations. The CGN MUST log dynamically assigned port blocks to facilitate subscriber-to-address mapping. The CGN SHOULD manage dynamic ports as described in [LOG-REDUCTION].

4. D> 0の場合、CGNには動的割り当て用に残されたポートのプールがあります。サブスクライバーがステップ2で割り振られたポートの範囲よりも多く（ただし、構成された最大ポートMよりは少ない）を使用する場合、CGNはそのような接続またはPCP予約のために動的割り当て範囲からポートのブロックを割り当てます。 CGNは、サブスクライバーとアドレスのマッピングを容易にするために、動的に割り当てられたポートブロックをログに記録する必要があります。 [LOG-REDUCTION]で説明されているように、CGNは動的ポートを管理する必要があります（SHOULD）。

5. Configuration of reserved ports (e.g., system ports) is left to operator configuration.

5. 予約済みポート（システムポートなど）の構成は、オペレーターの構成に任されています。

Thus, the CGN will maintain translation mapping information for all connections within its internal translation tables; however, it only needs to externally log translations for dynamically assigned ports.

したがって、CGNは内部変換テーブル内のすべての接続の変換マッピング情報を維持します。ただし、動的に割り当てられたポートの変換を外部でログに記録するだけで済みます。

2.1. IPv4 Port Utilization Efficiency

2.1. IPv4ポートの使用効率

For SPs requiring an aggressive address-sharing ratio, the use of the algorithmic mapping may impact the efficiency of the address sharing. A dynamic port range allocation assignment is more suitable in those cases.

積極的なアドレス共有比率を必要とするSPの場合、アルゴリズムマッピングを使用すると、アドレス共有の効率に影響を与える可能性があります。このような場合は、動的なポート範囲割り当ての割り当てが適しています。

2.2. Planning and Dimensioning

2.2. 計画と寸法決定

Unlike dynamic approaches, the use of the algorithmic mapping requires more effort from operational teams to tweak the algorithm (e.g., size of the port range, address sharing ratio, etc.). Dedicated alarms SHOULD be configured when some port utilization thresholds are fired so that the configuration can be refined.

ダイナミックアプローチとは異なり、アルゴリズムマッピングを使用するには、運用チームがアルゴリズムを微調整するために、より多くの労力を必要とします（たとえば、ポート範囲のサイズ、アドレス共有比率など）。構成を調整できるように、ポート使用率のしきい値が発生したときに専用アラームを構成する必要があります（SHOULD）。

The use of algorithmic mapping also affects geolocation. Changes to the inside and outside address ranges (e.g., due to growth, address allocation planning, etc.) would require external geolocation providers to recalibrate their mappings.

アルゴリズムマッピングの使用もジオロケーションに影響します。内外の住所範囲の変更（たとえば、成長、住所割り当て計画などによる）には、外部の地理位置情報プロバイダーがマッピングを再調整する必要があります。

2.3. Deterministic CGN Example

2.3. 確定的CGNの例

To illustrate the use of deterministic NAT, let's consider a simple example. The operator configures an inside address range (I) of 198.51.100.0/28 [RFC6598] and outside address (O) of 192.0.2.1. The dynamic address pool factor (D) is set to '2'. Thus, the total compression ratio is 1:(14+2) = 1:16. Only the system ports (e.g., ports < 1024) are reserved (R). This configuration causes the CGN to pre-allocate ((65536-1024)/16 =) 4032 TCP and 4032 UDP ports per inside IPv4 address. For the purposes of this example, let's assume that they are allocated sequentially, where 198.51.100.1 maps to 192.0.2.1 ports 1024-5055, 198.51.100.2 maps to 192.0.2.1 ports 5056-9087, etc. The dynamic port range thus contains ports 57472-65535 (port allocation illustrated in the table below). Finally, the maximum ports/subscriber is set to 5040.

確定的NATの使用を説明するために、簡単な例を考えてみましょう。オペレーターは、198.51.100.0 / 28 [RFC6598]の内部アドレス範囲（I）と192.0.2.1の外部アドレス（O）を構成します。動的アドレスプール係数（D）は「2」に設定されます。したがって、合計圧縮率は1：（14 + 2）= 1:16です。システムポート（例：1024未満のポート）のみが予約されています（R）。この構成により、CGNは内部IPv4アドレスごとに（（65536-1024）/ 16 =）4032 TCPおよび4032 UDPポートを事前に割り当てます。この例では、それらが順番に割り当てられていると仮定します。ここで、198.51.100.1は192.0.2.1ポート1024-5055に、198.51.100.2は192.0.2.1ポート5056-9087にマッピングされます。動的ポート範囲には、ポート57472-65535（下の表に示されているポート割り当て）。最後に、最大ポート/サブスクライバーは5040に設定されています。

            +-----------------------+------------------------+
            | Inside Address / Pool | Outside Address & Port |
            +-----------------------+------------------------+
            | Reserved              | 192.0.2.1:0-1023       |
            | 198.51.100.1          | 192.0.2.1:1024-5055    |
            | 198.51.100.2          | 192.0.2.1:5056-9087    |
            | 198.51.100.3          | 192.0.2.1:9088-13119   |
            | 198.51.100.4          | 192.0.2.1:13120-17151  |
            | 198.51.100.5          | 192.0.2.1:17152-21183  |
            | 198.51.100.6          | 192.0.2.1:21184-25215  |
            | 198.51.100.7          | 192.0.2.1:25216-29247  |
            | 198.51.100.8          | 192.0.2.1:29248-33279  |
            | 198.51.100.9          | 192.0.2.1:33280-37311  |
            | 198.51.100.10         | 192.0.2.1:37312-41343  |
            | 198.51.100.11         | 192.0.2.1:41344-45375  |
            | 198.51.100.12         | 192.0.2.1:45376-49407  |
            | 198.51.100.13         | 192.0.2.1:49408-53439  |
            | 198.51.100.14         | 192.0.2.1:53440-57471  |
            | Dynamic               | 192.0.2.1:57472-65535  |
            +-----------------------+------------------------+

When subscriber 1 using 198.51.100.1 initiates a low volume of connections (e.g., < 4032 concurrent connections), the CGN maps the outgoing source address/port to the pre-allocated range. These translation mappings are not logged.

198.51.100.1を使用するサブスクライバー1が少量の接続（たとえば、4032未満の同時接続）を開始すると、CGNは発信ソースアドレス/ポートを事前に割り当てられた範囲にマッピングします。これらの変換マッピングはログに記録されません。

Subscriber 2 concurrently uses more than the allocated 4032 ports (e.g., for peer-to-peer, mapping, video streaming, or other connection-intensive traffic types), the CGN allocates up to an additional 1008 ports using bulk port reservations. In this example, subscriber 2 uses outside ports 5056-9087, and then 100-port blocks between 58000-58999. Connections using ports 5056-9087 are not logged, while 10 log entries are created for ports 58000-58099, 58100-58199, 58200-58299, ..., 58900-58999.

サブスクライバー2は、割り当てられた4032ポートより多くを同時に使用します（たとえば、ピアツーピア、マッピング、ビデオストリーミング、またはその他の接続集約型のトラフィックタイプの場合）、CGNは、バルクポート予約を使用して最大1008ポートまで割り当てます。この例では、サブスクライバー2は外部ポート5056-9087を使用し、次に58000-58999の間の100ポートブロックを使用します。ポート5056-9087を使用した接続はログに記録されませんが、ポート58000-58099、58100-58199、58200-58299、...、58900-58999に対して10個のログエントリが作成されます。

In order to identify a subscriber behind a CGN (regardless of port allocation method), public safety agencies need to collect source address and port information from content provider log files. Thus, content providers are advised to log source address, source port, and timestamp for all log entries, per [RFC6302]. If a public safety agency collects such information from a content provider and reports abuse from 192.0.2.1, port 2001, the operator can reverse the mapping algorithm to determine that the internal IP address subscriber 1 has been assigned generated the traffic without consulting CGN logs (by correlating the internal IP address with DHCP/PPP lease connection records). If a second abuse report comes in for 192.0.2.1, port 58204, the operator will determine that port 58204 is within the dynamic pool range, consult the log file, correlate with connection records, and determine that subscriber 2 generated the traffic (assuming that the public safety timestamp matches the operator timestamp. As noted in RFC 6292 [RFC6292], accurate timekeeping (e.g., use of NTP or Simple NTP) is vital).

（ポート割り当て方法に関係なく）CGNの背後にある加入者を識別するために、公安機関はコンテンツプロバイダーのログファイルから送信元アドレスとポート情報を収集する必要があります。したがって、コンテンツプロバイダーは、[RFC6302]に従って、すべてのログエントリの送信元アドレス、送信元ポート、およびタイムスタンプを記録することをお勧めします。公共安全機関がコンテンツプロバイダーからそのような情報を収集し、192.0.2.1、ポート2001からの不正行為を報告した場合、オペレーターはマッピングアルゴリズムを逆にして、CGNログを参照することなく、サブスクライバー1に割り当てられたトラフィックを生成したことを確認できます（内部IPアドレスをDHCP / PPPリース接続レコードと関連付けることにより）。 192.0.2.1、ポート58204の2番目の不正使用レポートが届いた場合、オペレーターはポート58204が動的プールの範囲内にあると判断し、ログファイルを調べ、接続レコードと関連付け、サブスクライバー2がトラフィックを生成したと判断します（公共安全のタイムスタンプはオペレーターのタイムスタンプと一致します。RFC6292 [RFC6292]に記載されているように、正確なタイムキーピング（例：NTPまたはSimple NTPの使用）は不可欠です）。

In this example, there are no log entries for the majority of subscribers, who only use pre-allocated ports. Only minimal logging would be needed for those few subscribers who exceed their pre-allocated ports and obtain extra bulk port assignments from the dynamic pool. Logging data for those users will include inside address, outside address, outside port range, and timestamp.

この例では、事前に割り当てられたポートのみを使用する大多数のサブスクライバーのログエントリはありません。事前に割り当てられたポートを超え、動的プールから追加のバルクポート割り当てを取得する少数のサブスクライバーには、最小限のログ記録のみが必要です。これらのユーザーのログデータには、内部アドレス、外部アドレス、外部ポート範囲、およびタイムスタンプが含まれます。

Note that in a production environment, operators are encouraged to consider [RFC6598] for assigning inside addresses.

運用環境では、オペレーターは内部アドレスを割り当てるために[RFC6598]を検討することをお勧めします。

3. Additional Logging Considerations

3. 追加のログに関する考慮事項

In order to be able to identify a subscriber based on observed external IPv4 address, port, and timestamp, an operator needs to know how the CGN was configured with regard to internal and external IP addresses, dynamic address pool factor, maximum ports per user, and reserved port range at any given time. Therefore, the CGN MUST generate a record any time such variables are changed. The CGN SHOULD generate a log message any time such variables are changed. The CGN MAY keep such a record in the form of a router configuration file. If the CGN does not generate a log message, it would be up to the operator to maintain version control of router config changes. Also, the CGN SHOULD generate such a log message once per day to facilitate quick identification of the relevant configuration in the event of an abuse notification.

観測された外部IPv4アドレス、ポート、およびタイムスタンプに基づいてサブスクライバーを識別できるようにするために、オペレーターは、CGNが内部および外部IPアドレス、動的アドレスプール係数、ユーザーあたりの最大ポートに関してどのように構成されているかを知る必要があります。また、予約されたポートの範囲をいつでも指定できます。したがって、CGNはそのような変数が変更されるたびにレコードを生成する必要があります。 CGNは、そのような変数が変更されるたびにログメッセージを生成する必要があります（SHOULD）。 CGNは、そのような記録をルーター構成ファイルの形式で保持する場合があります。 CGNがログメッセージを生成しない場合、ルーターの設定変更のバージョン管理を維持するのはオペレーターの責任です。また、CGNは、乱用の通知が発生した場合に関連する構成をすばやく特定できるように、このようなログメッセージを1日に1回生成する必要があります（SHOULD）。

Such a log message MUST, at minimum, include the timestamp, inside prefix I, inside mask, outside prefix O, outside mask, D, M, A, and reserved port list R; for example:

このようなログメッセージには、少なくとも、タイムスタンプ、内部プレフィックスI、内部マスク、外部プレフィックスO、外部マスク、D、M、A、および予約済みポートリストRを含める必要があります。例えば：

[Wed Oct 11 14:32:52 2000]:198.51.100.0:28:192.0.2.0:32:2:5040:0:1-1023,5004,5060.

[Wed Oct 11 14:32:52 2000]：198.51.100.0：28：192.0.2.0：32：2：5040：0：1-1023,5004,5060。

3.1. Failover Considerations

3.1. フェイルオーバーに関する考慮事項

Due to the deterministic nature of algorithmically assigned translations, no additional logging is required during failover conditions provided that inside address ranges are unique within a given failover domain. Even when directed to a different CGN server, translations within the deterministic port range on either the primary or secondary server can be algorithmically reversed, provided the algorithm is known. Thus, if 198.51.100.1 port 3456 maps to 192.0.2.1 port 1000 on CGN 1 and 198.51.100.1 port 1000 on Failover CGN 2, an operator can identify the subscriber based on outside source address and port information.

アルゴリズムによって割り当てられた変換の確定的な性質により、特定のフェイルオーバードメイン内で内部アドレス範囲が一意である場合、フェイルオーバー状態の間に追加のロギングは必要ありません。別のCGNサーバーに転送する場合でも、アルゴリズムがわかっていれば、プライマリサーバーまたはセカンダリサーバーの確定的なポート範囲内の変換をアルゴリズム的に逆にすることができます。したがって、198.51.100.1ポート3456がCGN 1の192.0.2.1ポート1000およびフェイルオーバーCGN 2の198.51.100.1ポート1000にマップされている場合、オペレーターは外部ソースアドレスとポート情報に基づいてサブスクライバーを識別できます。

Similarly, assignments made from the dynamic overflow pool need to be logged as described above, whether translations are performed on the primary or failover CGN.

同様に、変換がプライマリCGNで実行されるかフェイルオーバーCGNで実行されるかにかかわらず、動的オーバーフロープールから行われた割り当ては、上記のようにログに記録する必要があります。

4. Impact on the IPv6 Transition

4. IPv6移行への影響

The solution described in this document is applicable to CGN transition technologies (e.g., NAT444, DS-Lite, and NAT64). As discussed in [RFC7021], the authors acknowledge that native IPv6 will offer subscribers a better experience than CGN. However, many Customer Premises Equipment (CPE) devices only support IPv4. Likewise, as of October 2014, only approximately 5.2% of the top 1 million websites were available using IPv6. Accordingly, Deterministic CGN should in no way be understood as making CGN a replacement for IPv6 service; however, until such time as IPv6 content and devices are widely available, Deterministic CGN will provide operators with the ability to quickly respond to public safety requests without requiring excessive infrastructure, operations, and bandwidth to support per-connection logging.

このドキュメントで説明するソリューションは、CGN移行テクノロジー（NAT444、DS-Lite、NAT64など）に適用できます。 [RFC7021]で説明されているように、著者はネイティブIPv6がCGNよりも優れたエクスペリエンスを加入者に提供することを認めています。ただし、多くの顧客宅内機器（CPE）デバイスはIPv4のみをサポートしています。同様に、2014年10月の時点で、IPv6を使用して利用できるのは上位100万のWebサイトの約5.2％のみでした。したがって、確定的CGNは、CGNをIPv6サービスの代わりにするものとして決して理解されるべきではありません。ただし、IPv6コンテンツとデバイスが広く利用できるようになるまでは、Deterministic CGNは、接続ごとのロギングをサポートするために過剰なインフラストラクチャ、操作、および帯域幅を必要とせずに、公共の安全要求に迅速に応答する機能をオペレーターに提供します。

5. Privacy Considerations

5. プライバシーに関する考慮事項

The algorithm described above makes it easier for SPs and public safety officials to identify the IP address of a subscriber through a CGN system. This is the equivalent level of privacy users could expect when they are assigned a public IP address and their traffic is not translated. However, this algorithm could be used by other actors on the Internet to map multiple transactions to a single subscriber, particularly if ports are distributed sequentially. While still preserving traceability, subscriber privacy can be increased by using one of the other values of the Address Assignment Algorithm (A), which would require interested parties to know more about the Service Provider's CGN configuration to be able to tie multiple connections to a particular subscriber.

上記のアルゴリズムにより、SPおよび公安当局は、CGNシステムを介して加入者のIPアドレスを特定しやすくなります。これは、パブリックIPアドレスが割り当てられており、トラフィックが変換されていない場合にユーザーが期待できるプライバシーと同等のレベルです。ただし、このアルゴリズムは、インターネット上の他のアクターが複数のトランザクションを単一のサブスクライバーにマップするために使用できます（特に、ポートが順次分散されている場合）。トレーサビリティを維持しながら、アドレス割り当てアルゴリズム（A）の他の値のいずれかを使用することにより、サブスクライバーのプライバシーを向上させることができます。これにより、関係者は、サービスプロバイダーのCGN構成の詳細を知って、複数の接続を特定の接続に関連付けることができます。加入者。

6. Security Considerations

6. セキュリティに関する考慮事項

The security considerations applicable to NAT operation for various protocols as documented in, for example, RFC 4787 [RFC4787] and RFC 5382 [RFC5382] also apply to this document.

たとえば、RFC 4787 [RFC4787]やRFC 5382 [RFC5382]に記載されているように、さまざまなプロトコルのNAT動作に適用されるセキュリティの考慮事項は、このドキュメントにも適用されます。

Note that, with the possible exception of cryptographically based port allocations, attackers could reverse-engineer algorithmically derived port allocations to either target a specific subscriber or to spoof traffic to make it appear to have been generated by a specific subscriber. However, this is exactly the same level of security that the subscriber would experience in the absence of CGN. CGN is not intended to provide additional security by obscurity.

暗号ベースのポート割り当ての可能性のある例外を除いて、攻撃者はアルゴリズムによって導出されたポート割り当てをリバースエンジニアリングして、特定のサブスクライバーをターゲットにするか、トラフィックを偽装して、特定のサブスクライバーによって生成されたように見せかけることに注意してください。ただし、これは、CGNがない場合に加入者が経験するセキュリティとまったく同じレベルです。 CGNは、あいまいさによる追加のセキュリティを提供することを意図していません。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。

[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007, <http://www.rfc-editor.org/info/rfc4787>.

[RFC4787] Audet、F。およびC. Jennings、「ユニキャストUDPのネットワークアドレス変換（NAT）動作要件」、BCP 127、RFC 4787、2007年1月、<http://www.rfc-editor.org/info/ rfc4787>。

[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008, <http://www.rfc-editor.org/info/rfc5382>.

[RFC5382] Guha、S.、Biswas、K.、Ford、B.、Sivakumar、S。、およびP. Srisuresh、「NAT Behavioral Requirements for TCP」、BCP 142、RFC 5382、2008年10月、<http：// www.rfc-editor.org/info/rfc5382>。

[RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, June 2011, <http://www.rfc-editor.org/info/rfc6264>.

[RFC6264] Jiang、S.、Guo、D。、およびB. Carpenter、「IPv6移行のための増分キャリアグレードNAT（CGN）」、RFC 6264、2011年6月、<http：//www.rfc-editor。 org / info / rfc6264>。

[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011, <http://www.rfc-editor.org/info/rfc6269>.

[RFC6269]フォード、M。、ブーカデア、M。、デュランド、A。、リーバイス、P。、およびP.ロバーツ、「IPアドレス共有の問題」、RFC 6269、2011年6月、<http：//www.rfc -editor.org/info/rfc6269>。

7.2. Informative References

7.2. 参考引用

[L2NAT] Miles, D. and M. Townsley, "Layer2-Aware NAT", Work in Progress, draft-miles-behave-l2nat-00, March 2009.

[L2NAT] Miles、D.およびM. Townsley、「Layer2-Aware NAT」、Work in Progress、draft-miles-behave-l2nat-00、2009年3月。

[LOG-REDUCTION] Tsou, T., Li, W., Taylor, T., and J. Huang, "Port Management To Reduce Logging In Large-Scale NATs", Work in Progress, draft-tsou-behave-natx4-log-reduction-04, July 2013.

[LOG-REDUCTION] Tsou、T.、Li、W.、Taylor、T。、およびJ. Huang、「大規模なNATでのログインを減らすためのポート管理」、作業中、draft-tsou-behave-natx4- log-reduction-04、2013年7月。

[NAT-LOGGING] Sivakumar, S. and R. Penno, "IPFIX Information Elements for logging NAT Events", Work in Progress, draft-ietf-behave-ipfix-nat-logging-04, July 2014.

[NAT-LOGGING] Sivakumar、S。およびR. Penno、「NATイベントをログに記録するためのIPFIX情報要素」、作業中、draft-ietf-behave-ipfix-nat-logging-04、2014年7月。

[NAT444] Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., and H. Ashida, "NAT444", Work in Progress, draft-shirasaki-nat444-06, July 2012.

「なＴ４４４」やまがた、い。、しらさき、Ｙ。、なかがわ、あ。、やまぐち、Ｊ。、あんｄＨ。あしだ、 ”なＴ４４４”、をｒｋいんＰろｇれっｓ、ｄらｆｔーしらさきーなｔ４４４ー０６、じゅｌｙ２０１２。

[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, <http://www.rfc-editor.org/info/rfc6146>.

[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「ステートフルNAT64：IPv6クライアントからIPv4サーバーへのネットワークアドレスおよびプロトコル変換」、RFC 6146、2011年4月、<http：//www.rfc -editor.org/info/rfc6146>。

[RFC6292] Hoffman, P., "Requirements for a Working Group Charter Tool", RFC 6292, June 2011, <http://www.rfc-editor.org/info/rfc6292>.

[RFC6292] Hoffman、P。、「Working Group Charter Toolの要件」、RFC 6292、2011年6月、<http://www.rfc-editor.org/info/rfc6292>。

[RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, "Logging Recommendations for Internet-Facing Servers", BCP 162, RFC 6302, June 2011, <http://www.rfc-editor.org/info/rfc6302>.

[RFC6302] Durand、A.、Gashinsky、I.、Lee、D。、およびS. Sheppard、「インターネットに面したサーバーのログに関する推奨事項」、BCP 162、RFC 6302、2011年6月、<http：//www.rfc -editor.org/info/rfc6302>。

[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011, <http://www.rfc-editor.org/info/rfc6333>.

[RFC6333] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4枯渇後のデュアルスタックLiteブロードバンド展開」、RFC 6333、2011年8月、<http：//www.rfc- editor.org/info/rfc6333>。

[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, August 2011, <http://www.rfc-editor.org/info/rfc6335>.

[RFC6335]綿、M。、エガート、L。、タッチ、J。、ウェスターランド、M。、およびS.チェシャー、「サービス名とトランスポートプロトコルのポート番号レジストリの管理のためのInternet Assigned Numbers Authority（IANA）手順"、BCP 165、RFC 6335、2011年8月、<http://www.rfc-editor.org/info/rfc6335>。

[RFC6431] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and T. Tsou, "Huawei Port Range Configuration Options for PPP IP Control Protocol (IPCP)", RFC 6431, November 2011, <http://www.rfc-editor.org/info/rfc6431>.

[RFC6431] Boucadair、M.、Levis、P.、Bajko、G.、Savolainen、T。、およびT. Tsou、「Huawei Port Range Configuration Options for PPP IP Control Protocol（IPCP）」、RFC 6431、2011年11月、 <http://www.rfc-editor.org/info/rfc6431>。

[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, April 2012, <http://www.rfc-editor.org/info/rfc6598>.

[RFC6598] Weil、J.、Kuarsingh、V.、Donley、C.、Liljenstolpe、C。、およびM. Azinger、「IANA-Reserved IPv4 Prefix for Shared Address Space」、BCP 153、RFC 6598、2012年4月、< http://www.rfc-editor.org/info/rfc6598>。

[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013, <http://www.rfc-editor.org/info/rfc6887>.

[RFC6887] Wing、D.、Cheshire、S.、Boucadair、M.、Penno、R。、およびP. Selkirk、「Port Control Protocol（PCP）」、RFC 6887、2013年4月、<http：// www。 rfc-editor.org/info/rfc6887>。

[RFC7021] Donley, C., Howard, L., Kuarsingh, V., Berg, J., and J. Doshi, "Assessing the Impact of Carrier-Grade NAT on Network Applications", RFC 7021, September 2013, <http://www.rfc-editor.org/info/rfc7021>.

[RFC7021] Donley、C.、Howard、L.、Kuarsingh、V.、Berg、J。、およびJ. Doshi、「ネットワークアプリケーションに対するキャリアグレードNATの影響の評価」、RFC 7021、2013年9月、<http ：//www.rfc-editor.org/info/rfc7021>。

Acknowledgements

謝辞

The authors would like to thank the following people for their suggestions and feedback: Bobby Flaim, Lee Howard, Wes George, Jean-Francois Tremblay, Mohammed Boucadair, Alain Durand, David Miles, Andy Anchev, Victor Kuarsingh, Miguel Cros Cecilia, Fred Baker, Brian Carpenter, and Reinaldo Penno.

著者は、以下の人々に提案とフィードバックを提供したいと思います。ボビーフレイム、リーハワード、ウェスジョージ、ジャンフランソワトランブレ、モハメッドブーカデール、アランデュラン、デビッドマイルス、アンディアンシェフ、ビクタークアルシン、ミゲルクロスセシリア、フレッドベイカー、ブライアンカーペンター、レイナルドペンノ。

Authors' Addresses

著者のアドレス

Chris Donley CableLabs 858 Coal Creek Cir Louisville, CO 80027 United States

Chris Donley CableLabs 858 Coal Creek Cir Louisville、CO 80027アメリカ合衆国

   EMail: c.donley@cablelabs.com

Chris Grundemann Internet Society Denver, CO United States

Chris Grundemann Internet Societyデンバー、COアメリカ合衆国

   EMail: cgrundemann@gmail.com

Vikas Sarawat CableLabs 858 Coal Creek Cir Louisville, CO 80027 United States

Vikas Sarawat CableLabs 858 Coal Creek Cir Louisville、CO 80027アメリカ合衆国

   EMail: v.sarawat@cablelabs.com

Karthik Sundaresan CableLabs 858 Coal Creek Cir Louisville, CO 80027 United States

Karthik Sundaresan CableLabs 858 Coal Creek Cir Louisville、CO 80027アメリカ合衆国

   EMail: k.sundaresan@cablelabs.com

Olivier Vautrin Juniper Networks 1194 N Mathilda Avenue Sunnyvale, CA 94089 United States

Olivier Vautrin Juniper Networks 1194 N Mathilda Avenue Sunnyvale、CA 94089アメリカ合衆国

   EMail: olivier@juniper.net