[要約] RFC 6431は、HuaweiのPPP IP制御プロトコル（IPCP）のポート範囲設定オプションに関する仕様です。このRFCの目的は、Huawei製品のネットワーク機器でのIPCPのポート範囲設定を標準化し、相互運用性を向上させることです。
Independent Submission M. Boucadair
Request for Comments: 6431 P. Levis
Category: Informational France Telecom
ISSN: 2070-1721 G. Bajko
T. Savolainen
Nokia
T. Tsou
Huawei Technologies (USA)
November 2011
Huawei Port Range Configuration Options for PPP IP Control Protocol (IPCP)
PPP IPコントロールプロトコル（IPCP）のHuaweiポート範囲構成オプション
Abstract
概要
This document defines two Huawei IPCP (IP Control Protocol) options used to convey a set of ports. These options can be used in the context of port range-based solutions or NAT-based solutions for port delegation and forwarding purposes.
このドキュメントでは、一連のポートを伝えるために使用される2つのHuawei IPCP（IPコントロールプロトコル）オプションを定義します。これらのオプションは、ポートレンジベースのソリューションまたはポート委任および転送目的のためのNATベースのソリューションのコンテキストで使用できます。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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エディターによって公開が承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。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/rfc6431.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6431で取得できます。
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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Use Cases ..................................................3
1.2. Terminology ................................................3
1.3. Requirements Language ......................................4
2. Port Range Options ..............................................4
2.1. Description of Port Range Value and Port Range Mask ........4
2.2. Cryptographically Random Port Range Option .................6
2.2.1. Random Port Delegation Function .....................6
2.2.2. Description of Cryptographically Random Port
Range Option ........................................8
2.3. Illustration Examples .....................................10
2.3.1. Overview ...........................................10
2.3.2. Successful Flow: Port Range Options Supported
by Both the Client and the Server ..................10
2.3.3. Port Range Option Not Supported by the Server ......11
2.3.4. Port Range Option Not Supported by the Client ......13
3. Security Considerations ........................................14
4. Contributors ...................................................14
5. Acknowledgements ...............................................14
6. References .....................................................14
6.1. Normative References ......................................14
6.2. Informative References ....................................15
Within the context of IPv4 address depletion, several solutions have been investigated to share IPv4 addresses. Two flavors can be distinguished: NAT-based solutions (e.g., Carrier-Grade NAT (CGN) [CGN-REQS]) and port range-based solutions (e.g., [RFC6346] [PORT-RANGE-ARCH] [SAM]). Port range-based solutions do not require an additional NAT level in the service provider's domain. Several means may be used to convey port range information.
IPv4アドレスの枯渇のコンテキスト内で、IPv4アドレスを共有するためにいくつかのソリューションが調査されています。NATベースのソリューション（キャリアグレードNAT（CGN）[CGN-REQS]）とポートレンジベースのソリューション（例：[RFC6346] [Port-Range-Arch] [SAM]）の2つのフレーバーを区別できます。ポートレンジベースのソリューションでは、サービスプロバイダーのドメインに追加のNATレベルは必要ありません。ポートレンジ情報を伝えるためにいくつかの手段を使用することができます。
This document defines the notion of "Port Mask", which is generic and flexible. Several allocation schemes may be implemented when using a Port Mask. It proposes a basic mechanism that allows the allocation of a unique port range to a requesting client. This document defines Huawei IPCP options to be used to carry port range information.
このドキュメントは、一般的で柔軟な「ポートマスク」の概念を定義しています。ポートマスクを使用する場合、いくつかの割り当てスキームが実装される場合があります。要求のクライアントに一意のポート範囲を割り当てることを可能にする基本的なメカニズムを提案します。このドキュメントでは、ポートレンジ情報を運ぶために使用されるHuawei IPCPオプションを定義しています。
IPv4 address exhaustion is only provided as an example of the usage of the PPP IPCP options defined in this document. In particular, Port Range options may be used independently of the presence of the IP-Address IPCP Option.
IPv4アドレスの疲労は、このドキュメントで定義されているPPP IPCPオプションの使用例としてのみ提供されます。特に、ポート範囲のオプションは、IPアドレスIPCPオプションの存在とは無関係に使用できます。
This document adheres to the considerations defined in [RFC2153].
この文書は、[RFC2153]で定義されている考慮事項に準拠しています。
This document is not a product of the PPPEXT working group.
このドキュメントは、PPPEXTワーキンググループの製品ではありません。
Note that IPR disclosures apply to this document (see https://datatracker.ietf.org/ipr/).
iPR開示がこのドキュメントに適用されることに注意してください（https://datatracker.ietf.org/ipr/を参照）。
Port Range options can be used in port range-based solutions (e.g., [RFC6346]) or in a CGN-based solution. These options can be used in a CGN context to bypass the NAT (i.e., for transparent NAT traversal, and to avoid involving several NAT levels in the path) or to delegate one or a set of ports to the requesting client (e.g., to avoid the ALG (Application Level Gateway), or for port forwarding).
ポートレンジオプションは、ポートレンジベースのソリューション（[RFC6346]など）またはCGNベースのソリューションで使用できます。これらのオプションは、CGNコンテキストでNATをバイパスする（つまり、透明なNATトラバーサルの場合、パスにいくつかのNATレベルが関与することを避けるため）、または要求クライアントに1つまたは1つのポートを委任する（例：アルグ（アプリケーションレベルゲートウェイ）、またはポート転送用）。
Section 3.3.1 of [RFC6346] specifies an example of usage of the options defined in this document.
[RFC6346]のセクション3.3.1は、このドキュメントで定義されているオプションの使用例を指定しています。
To differentiate between a port range containing a contiguous span of port numbers and a port range with non-contiguous and possibly random port numbers, the following denominations are used:
隣接するポート番号のスパンを含むポート範囲と、非連続的でランダムなポート番号を持つポート範囲を区別するために、次の宗派が使用されます。
o Contiguous Port Range: A set of port values that form a contiguous sequence.
o 隣接するポート範囲：隣接するシーケンスを形成するポート値のセット。
o Non-Contiguous Port Range: A set of port values that do not form a contiguous sequence.
o 非連続ポート範囲：隣接するシーケンスを形成しないポート値のセット。
o Random Port Range: A cryptographically random set of port values.
o ランダムポート範囲：ポート値の暗号化的にランダムなセット。
Unless explicitly mentioned, "Port Mask" refers to the tuple (Port Range Value, Port Range Mask).
明示的に言及しない限り、「ポートマスク」とはタプル（ポートレンジ値、ポートレンジマスク）を指します。
In addition, this document makes use of the following terms:
さらに、このドキュメントでは、次の用語を使用しています。
o Delegated port or delegated port range: A port or a range of ports that belong to an IP address managed by an upstream device (such as NAT) and that are delegated to a client for use as the source address and port when sending packets.
o 委任されたポートまたは委任されたポート範囲：アップストリームデバイス（NATなど）が管理するIPアドレスに属し、パケットを送信する際にソースアドレスとして使用するためにクライアントに委任されるポートまたはポートの範囲。
o Forwarded port or forwarder port range: A port or a range of ports that belong to an IP address managed by an upstream device such as (NAT) and that are statically mapped to the internal IP address of the client and same port number of the client.
o 転送されたポートまたはフォワーダーポート範囲：（NAT）などの上流のデバイスによって管理され、クライアントの内部IPアドレスとクライアントの同じポート番号に静的にマッピングされたポートまたはポートの範囲。
This memo uses the same terminology as [RFC1661].
このメモは、[RFC1661]と同じ用語を使用します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
This section defines the IPCP Option for port range delegation. The format of vendor-specific options is defined in [RFC2153]. Below are the values to be conveyed when the Port Range Option is used:
このセクションでは、ポートレンジ代表団のIPCPオプションを定義します。ベンダー固有のオプションの形式は[RFC2153]で定義されています。以下は、ポート範囲オプションを使用するときに伝達される値です。
o Organizationally Unique Identifier (OUI): This field is set to 781DBA (hex).
o 組織的に一意の識別子（OUI）：このフィールドは781DBA（HEX）に設定されています。
o Kind: This field is set to F0 (hex).
o 種類：このフィールドはF0（六角）に設定されています。
o Value(s): The content of this field is specified in Sections 2.1 and 2.2.2.
o 値：このフィールドの内容は、セクション2.1および2.2.2で指定されています。
The Port Range Value and Port Range Mask are used to specify one range of ports (contiguous or non-contiguous) pertaining to a given IP address. Concretely, the Port Range Mask and Port Range Value are used to notify a remote peer about the Port Mask to be applied when selecting a port value as a source port. The Port Range Value is used to infer a set of allowed port values. A Port Range Mask defines a set of ports that all have in common a subset of pre-positioned bits. This set of ports is also referred to as the port range.
ポート範囲値とポートレンジマスクは、特定のIPアドレスに関連する1つの範囲のポート（連続または非連続）を指定するために使用されます。具体的には、ポートマスクとポート範囲の値を使用して、ポート値をソースポートとして選択するときに適用するポートマスクについてリモートピアに通知します。ポート範囲値は、許可されたポート値のセットを推測するために使用されます。ポートレンジマスクは、すべてが事前に位置するビットのサブセットを共通しているポートのセットを定義します。この一連のポートは、ポート範囲とも呼ばれます。
Two port numbers are said to belong to the same port range if and only if they have the same Port Range Mask.
同じポートレンジマスクがある場合にのみ、2つのポート番号が同じポート範囲に属すると言われています。
A Port Mask is composed of a Port Range Value and a Port Range Mask:
ポートマスクは、ポートレンジ値とポートレンジマスクで構成されています。
o The Port Range Value indicates the value of the significant bits of the Port Mask. The Port Range Value is coded as follows:
o ポート範囲の値は、ポートマスクの重要なビットの値を示します。ポート範囲の値は次のようにコーディングされます。
* The significant bits may take a value of 0 or 1.
* 有意なビットには、0または1の値がかかる場合があります。
* All of the other bits (i.e., non-significant ones) are set to 0.
* 他のすべてのビット（つまり、重要でないもの）は0に設定されています。
o The Port Range Mask indicates, by the bit(s) set to 1, the position of the significant bits of the Port Range Value.
o ポートレンジマスクは、1に設定されたビットで、ポート範囲値の重要なビットの位置を示します。
This IPCP Configuration Option provides a way to negotiate the Port Range to be used on the local end of the link. It allows the sender of the Configure-Request message to state which port range associated with a given IP address is desired, or to request that the peer provide the configuration. The peer can provide this information by NAKing the option, and returning a valid port range (i.e., (Port Range Value, Port Range Mask)).
このIPCP構成オプションは、リンクのローカルエンドで使用するポート範囲をネゴシエートする方法を提供します。Configure-Requestメッセージの送信者が、特定のIPアドレスに関連付けられているポート範囲が望ましい場合、またはピアが構成を提供するように要求することができます。ピアは、オプションをネイキングし、有効なポート範囲（つまり、ポートレンジ値、ポートレンジマスク）を返すことにより、この情報を提供できます。
If a peer issues a request enclosing the IPCP Port Range Option and the server does not support this option, the Port Range Option is rejected by the server.
ピアがIPCPポート範囲オプションを囲む要求を発行し、サーバーがこのオプションをサポートしていない場合、ポート範囲オプションはサーバーによって拒否されます。
The set of ports conveyed in an IPCP Port Range Option applies to all transport protocols.
IPCPポートレンジオプションで伝えられるポートのセットは、すべての輸送プロトコルに適用されます。
The set of ports conveyed in an IPCP Port Range Option is revoked when the link is no longer up (e.g., when Terminate-Request and Terminate-Ack are exchanged).
IPCPポート範囲のオプションで伝達されるポートのセットは、リンクが終了しなくなったときに取り消されます（たとえば、Terminate-RequestとTerminate-ackが交換されたとき）。
The Port Range IPCP option adheres to the format defined in Section 2.1 of [RFC2153]. The "Value(s)" field of the option defined in [RFC2153] when conveying the Port Range IPCP Option is provided in Figure 1.
ポートレンジIPCPオプションは、[RFC2153]のセクション2.1で定義されている形式に準拠しています。[RFC2153]で定義されたオプションの「値」フィールドは、ポート範囲IPCPオプションを伝達するときに図1に提供されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved | Port Range Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Range Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Most significant bit (MSB) network order is used for encoding the Port Range Value and Port Range Mask fields.
最も重要なビット（MSB）ネットワーク順序は、ポートレンジ値とポートレンジマスクフィールドをエンコードするために使用されます。
Figure 1: Format of the Port Range IPCP Option
図1：ポートレンジIPCPオプションの形式
o M: mode bit. The mode bit indicates the mode for which the port range is allocated. A value of zero indicates that the port ranges are delegated, while a value of 1 indicates that the port ranges are port-forwarded.
o M：モードビット。モードビットは、ポート範囲が割り当てられるモードを示します。ゼロの値は、ポート範囲が委任されていることを示し、1の値はポート範囲がポートに反していることを示します。
o Port Range Value (PRV): The PRV indicates the value of the significant bits of the Port Mask. By default, no PRV is assigned.
o ポート範囲値（PRV）：PRVは、ポートマスクの重要なビットの値を示します。デフォルトでは、PRVは割り当てられていません。
o Port Range Mask (PRM): The Port Range Mask indicates the position of the bits that are used to build the Port Range Value. By default, no PRM value is assigned. The 1 values in the Port Range Mask indicate by their position the significant bits of the Port Range Value.
o ポートレンジマスク（PRM）：ポートレンジマスクは、ポート範囲値の構築に使用されるビットの位置を示します。デフォルトでは、PRM値は割り当てられていません。ポートレンジマスクの1値は、ポート範囲値の重要なビットを位置によって示しています。
Figure 2 provides an example of the resulting port range:
図2に、結果のポート範囲の例を示します。
- The Port Range Mask is set to 0001010000000000 (5120).
- ポートレンジマスクは0001010000000000（5120）に設定されています。
- The Port Range Value is set to 0000010000000000 (1024).
- ポート範囲の値は0000010000000000（1024）に設定されています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0| Port Range Mask
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| | (two significant bits)
v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0| Port Range Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x 0 x 1 x x x x x x x x x x| Usable ports
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (x may be set to 0 or 1)
Figure 2: Example of Port Range Mask and Port Range Value
図2：ポートレンジマスクとポートレンジ値の例
Port values belonging to this port range must have the fourth bit from the left set to 0, and the sixth bit from the left set to 1. Only these port values will be used by the peer when enforcing the configuration conveyed by PPP IPCP.
このポート範囲に属するポート値は、左セットから0に4番目のビットを持ち、左セットから6ビットを1にしなければなりません。PPPIPCPによって伝達される構成を強制する場合、これらのポート値のみがピアによって使用されます。
A cryptographically random Port Range Option may be used as a mitigation tool against blind attacks such as those described in [RFC6056].
[RFC6056]に記載されているようなブラインド攻撃に対する緩和ツールとして、暗号化的にランダムなポート範囲オプションを使用できます。
Delegating random ports can be achieved by defining a function that takes as input a key 'K' and an integer 'x' within the 1024-65535 port range and produces an output 'y' also within the 1024-65535 port range.
ランダムポートの委任は、1024-65535ポート範囲内でキー「k」と整数「x」を入力する機能を定義することで実現でき、1024-65535ポート範囲内にも出力「Y」を生成します。
The cryptographic mechanism uses the 1024-65535 port range rather than the ephemeral range, 49152-65535, for generating a set of ports to optimize IPv4 address utilization efficiency (see "Appendix B. Address Space Multiplicative Factor" of [RFC6269]). This behavior is compliant with the recommendation to use the whole 1024-65535 port range for the ephemeral port selection algorithms (see Section 3.2 of [RFC6056]).
暗号化メカニズムは、IPv4アドレスの使用効率を最適化するために一連のポートを生成するために、一時的な範囲49152-65535ではなく1024-65535ポート範囲を使用しています（[RFC6269]の「アドレス空間乗算因子」を参照）。この動作は、一時的なポート選択アルゴリズムに1024-65535ポート範囲全体を使用することを推奨することに準拠しています（[RFC6056]のセクション3.2を参照）。
The cryptographic mechanism ensures that the entire 64k port range can be efficiently distributed to multiple nodes such that when nodes calculate the ports, the results will never overlap with ports that other nodes have calculated (property of permutation), and ports in the reserved range (smaller than 1024) are not used. As the randomization is done cryptographically, an attacker seeing a node using some port X cannot determine which other ports the node may be using (as the attacker does not know the key). Calculation of the random port list is done as follows:
暗号化メカニズムにより、64Kポート範囲全体を複数のノードに効率的に分布させることができるため、ノードがポートを計算すると、他のノードが計算したポート（順列のプロパティ）、および予約範囲のポートとは決して重複しません（1024より小さい）は使用されていません。ランダム化が暗号化されているため、ポートXを使用してノードを見る攻撃者は、ノードが使用している他のポートを決定できません（攻撃者はキーを知らないため）。ランダムポートリストの計算は、次のように行われます。
The cryptographic mechanism uses an encryption function y = E(K,x) that takes as input a key K (for example, 128 bits) and an integer x (the plaintext) in the 1024-65535 port range, and produces an output y (the ciphertext), also an integer in the 1024-65535 port range. This section describes one such encryption function, but others are also possible.
暗号化メカニズムは、1024-65535ポート範囲でキーK（たとえば、128ビット）と整数X（プレーンテキスト）を入力して、出力yを生成する暗号化関数y = e（k、x）を使用します。（ciphertext）、1024-65535ポートレンジの整数も。このセクションでは、そのような暗号化関数の1つについて説明しますが、他にも可能です。
The server will select the key K. When the server wants to allocate, for example, 2048 random ports, it selects a starting point 'a' (1024 <= a <= 65536-2048) such that the port range (a, a+2048) does not overlap with any other active client, and calculates the values E(K,a), E(K,a+1), E(K,a+2), ..., E(K,a+2046), E(K,a+2047). These are the port numbers allocated for this node. Instead of sending the port numbers individually, the server just sends the values 'K', 'a', and '2048'. The client will then repeat the same calculation.
サーバーはキーKを選択します。たとえば、2048ランダムポートなど、サーバーが割り当てを行うと、ポート範囲（A、A、A、A、A、A <= 65536-2048）を選択します。2048）他のアクティブなクライアントと重複せず、値e（k、a）、e（k、a 1）、e（k、a 2）、...、e（k、a 2046）の値を計算します。E（K、A 2047）。これらは、このノードに割り当てられたポート番号です。ポート番号を個別に送信する代わりに、サーバーは値「K」、「A」、および「2048」を送信するだけです。クライアントは同じ計算を繰り返します。
The server SHOULD use a different key K for each IPv4 address it allocates, to make attacks as difficult as possible. This way, learning the key K used in IPv4 address IP1 would not help in attacking IPv4 address IP2 where IP2 is allocated by the same server to different nodes.
サーバーは、割り当てたIPv4アドレスごとに異なるキーKを使用して、攻撃を可能な限り困難にする必要があります。このようにして、IPv4アドレスIP1で使用されるキーKを学習しても、IP2アドレスIP2アドレスを攻撃するのに役立ちません。ここでは、同じサーバーによって異なるノードに割り当てられます。
With typical encryption functions (such as AES and DES), the input (plaintext) and output (ciphertext) are blocks of some fixed size -- for example, 128 bits for AES, and 64 bits for DES. For port randomization, we need an encryption function whose input and output is an integer in the 1024-65535 port range.
典型的な暗号化関数（AESやDESなど）では、入力（プレーンテキスト）と出力（ciphertext）は、ある固定サイズのブロックです。たとえば、AESの128ビット、DESの64ビットです。ポートランダム化には、入力と出力が1024-65535ポート範囲の整数である暗号化関数が必要です。
One possible way to do this is to use the 'Generalized Feistel Cipher' [CIPHERS] construction by Black and Rogaway, with AES as the underlying round function.
これを行うための可能な方法の1つは、BlackとRogawayによる「一般化されたFeistel Cipher」[Ciphers]構造を使用し、AEを基礎となる丸い関数として使用することです。
This would look as follows (using pseudo-code):
これは次のように見えます（擬似コードを使用）：
def E(k, x):
y = Feistel16(k, x)
if y >= 1024:
return y
else:
return E(k, y)
Note that although E(k,x) is recursive, it is guaranteed to terminate. The average number of iterations is just slightly over 1.
E（k、x）は再帰的ですが、終了することが保証されていることに注意してください。反復の平均数は1をわずかに超えています。
Feistel16 is a 16-bit block cipher:
Feistel16は16ビットブロック暗号です。
def Feistel16(k, x):
left = x & 0xff
right = x >> 8
for round = 1 to 3:
temp = left ^ FeistelRound(k, round, right))
left = right
right = temp
return (right << 8) | left
The Feistel round function uses:
Feistelラウンド関数は次のとおりです。
def FeistelRound(k, round, x): msg[0] = round msg[1] = x msg[2...15] = 0 return AES(k, msg)[0]
def feistelround（k、round、x）：msg [0] = round msg [1] = x msg [2 ... 15] = 0 return aes（k、msg）[0]
Performance: To generate a list of 2048 port numbers, about 6000 calls to AES are required (i.e., encrypting 96 kilobytes). Thus, it will not be a problem for any device that can do, for example, HTTPS (web browsing over Secure Sockets Layer/Transport Layer Security (SSL/TLS)).
パフォーマンス：2048ポート番号のリストを生成するには、AEへの約6000個の呼び出しが必要です（つまり、96キロバイトを暗号化します）。したがって、たとえば、HTTPS（Secure Socketsレイヤー/トランスポートレイヤーセキュリティ（SSL/TLS）上のWebブラウジング）でできるデバイスにとっては問題にはなりません。
The cryptographically random Port Range IPCP Option adheres to the format defined in Section 2.1 of [RFC2153]. The "Value(s)" field of the option defined in [RFC2153] when conveying the cryptographically random Port Range IPCP Option is illustrated in Figure 3.
暗号化的にランダムなポート範囲IPCPオプションは、[RFC2153]のセクション2.1で定義されている形式に準拠しています。暗号的にランダムなポート範囲IPCPオプションを伝えるときに[RFC2153]で定義されたオプションの「値」フィールドを図3に示します。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved | function |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| starting point | number of delegated ports |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key K ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of the Cryptographically Random Port Range Option
図3：暗号化的にランダムなポート範囲オプションの形式
o M: mode bit. The mode bit indicates the mode for which the port range is allocated. A value of zero indicates that the port ranges are delegated, while a value of 1 indicates that the port ranges are port-forwarded.
o M：モードビット。モードビットは、ポート範囲が割り当てられるモードを示します。ゼロの値は、ポート範囲が委任されていることを示し、1の値はポート範囲がポートに反していることを示します。
o Function: A 16-bit field whose value is associated with predefined encryption functions. This specification associates value 1 with the predefined function described in Section 2.2.1.
o 関数：値が定義された暗号化関数に関連付けられている16ビットフィールド。この仕様は、値1をセクション2.2.1で説明した事前定義された関数と関連付けます。
o Starting Point: A 16-bit value used as an input to the specified function.
o 開始点：指定された関数への入力として使用される16ビット値。
o Number of delegated ports: A 16-bit value specifying the number of ports delegated to the client for use as source port values.
o 委任されたポートの数：ソースポート値として使用するためにクライアントに委任されたポートの数を指定する16ビット値。
o Key K: A 128-bit key used as input to the predefined function for delegated port calculation.
o キーK：委任されたポート計算の事前定義された関数への入力として使用される128ビットキー。
When the option is included in the IPCP Configure-Request, the "Key K" and "Starting Point" fields SHALL be set to all zeros. The requester MAY indicate in the "Function" field which encryption function the requester prefers, and in the "Number of Delegated Ports" field the number of ports the requester would like to obtain. If the requester has no preference, it SHALL also set the "Function" field and/or "Number of Delegated Ports" field to zero.
オプションがIPCP Configure-Requestに含まれている場合、「キーK」および「開始点」フィールドをすべてのゼロに設定するものとします。要求者は、要求者が好む暗号化関数の「関数」フィールドを示す場合があり、「委任されたポートの数」フィールドでは、リクエスターが取得したいポートの数を示します。要求者に好みがない場合、「関数」フィールドおよび/または「委任されたポートの数」フィールドをゼロに設定するものとします。
The usage of the option in IPCP message negotiation (Request/Reject/ Nak/Ack) follows the logic described for Port Mask and Port Range options in Section 2.1.
IPCPメッセージネゴシエーション（Request/Reject/Nak/ACK）でのオプションの使用は、セクション2.1のポートマスクおよびポート範囲オプションについて説明したロジックに従います。
The following flows provide examples of the usage of IPCP to convey the Port Range Option. As illustrated in Figures 4, 5, and 6, IPCP messages are exchanged between a Host and a BRAS (Broadband Remote Access Server).
次のフローは、ポート範囲オプションを伝えるためにIPCPの使用例を提供します。図4、5、および6に示すように、IPCPメッセージはホストとBRA（ブロードバンドリモートアクセスサーバー）の間で交換されます。
2.3.2. Successful Flow: Port Range Options Supported by Both the Client and the Server
2.3.2. 成功したフロー：クライアントとサーバーの両方でサポートされるポートレンジオプション
The following message exchange (Figure 4) depicts a successful IPCP configuration operation where the Port Range IPCP Option is used.
次のメッセージ交換（図4）は、ポート範囲IPCPオプションが使用される場合のIPCP構成操作の成功を示しています。
+-----+ +-----+
| Host| | BRAS|
+-----+ +-----+
| |
| (1) IPCP Configure-Request |
| IP ADDRESS=0.0.0.0 |
| PORT RANGE VALUE=0 |
| PORT RANGE MASK=0 |
|===============================================>|
| |
| (2) IPCP Configure-Nak |
| IP ADDRESS=a.b.c.d |
| PORT RANGE VALUE=80 |
| PORT RANGE MASK=496 |
|<===============================================|
| |
| (3) IPCP Configure-Request |
| IP ADDRESS=a.b.c.d |
| PORT RANGE VALUE=80 |
| PORT RANGE MASK=496 |
|===============================================>|
| |
| (4) IPCP Configure-Ack |
| IP ADDRESS=a.b.c.d |
| PORT RANGE VALUE=80 |
| PORT RANGE MASK=496 |
|<===============================================|
| |
Figure 4: Successful Flow
図4：成功したフロー
The main steps of this flow are listed below:
このフローの主な手順を以下に示します。
(1) The Host sends a first Configure-Request, which includes the set of options it desires to negotiate. All of these configuration options are negotiated simultaneously. In this step, the Configure-Request carries information about the IP address, the Port Range Value, and the Port Range Mask. The IP-Address Option is set to 0.0.0.0, the Port Range Value is set to 0, and the Port Range Mask is set to 0.
(1) ホストは、交渉を望む一連のオプションを含む最初のConfigure-Requestを送信します。これらの構成オプションはすべて同時にネゴシエートされます。このステップでは、Configure-Requestには、IPアドレス、ポート範囲値、およびポートレンジマスクに関する情報が含まれています。IPアドレスオプションは0.0.0.0に設定され、ポート範囲値は0に設定され、ポートレンジマスクは0に設定されています。
(2) The BRAS sends back a Configure-Nak and sets the enclosed options to its preferred values. In this step, the IP-Address Option is set to a.b.c.d, the Port Range Value is set to 80, and the Port Range Mask is set to 496.
(2) ブラジャーはConfigure-nakを送り返し、囲まれたオプションを優先値に設定します。このステップでは、IPアドレスオプションはA.B.C.Dに設定され、ポート範囲値は80に設定され、ポートレンジマスクは496に設定されています。
(3) The Host re-sends a Configure-Request requesting that the IP-Address Option be set to a.b.c.d, the Port Range Value be set to 80, and the Port Range Mask be set to 496.
(3) ホストは、ip-addressオプションをA.B.C.Dに設定し、ポート範囲値を80に設定し、ポートレンジマスクを496に設定することを要求するConfigure-Requestを再送信します。
(4) The BRAS sends a Configure-Ack message.
(4) ブラジャーは、configure-ackメッセージを送信します。
As a result of this exchange, the Host is configured to use a.b.c.d as its local IP address, and the following 128 contiguous port ranges resulting from the Port Mask (Port Range Value == 0, Port Range Mask == 496):
この交換の結果、ホストはA.B.C.DをローカルIPアドレスとして使用するように構成されており、ポートマスク（ポート範囲値== 0、ポートレンジマスク== 496）に起因する次の128の隣接するポート範囲：
- from 80 to 95
- 80から95
- from 592 to 607
- 592から607まで
- ...
- ...
- from 65104 to 65119
- 65104から65119まで
Figure 5 depicts an exchange of messages where the BRAS does not support the IPCP Port Range Option.
図5は、BRAがIPCPポート範囲オプションをサポートしていないメッセージの交換を示しています。
+-----+ +-----+
| Host| | BRAS|
+-----+ +-----+
| |
| (1) IPCP Configure-Request |
| IP ADDRESS=0.0.0.0 |
| PORT RANGE VALUE=0 |
| PORT RANGE MASK=0 |
|===============================================>|
| |
| (2) IPCP Configure-Reject |
| PORT RANGE VALUE=0 |
| PORT RANGE MASK=0 |
|<===============================================|
| |
| (3) IPCP Configure-Request |
| IP ADDRESS=0.0.0.0 |
|===============================================>|
| |
| (4) IPCP Configure-Nak |
| IP ADDRESS=a.b.c.d |
|<===============================================|
| |
| (5) IPCP Configure-Request |
| IP ADDRESS=a.b.c.d |
|===============================================>|
| |
| (6) IPCP Configure-Ack |
| IP ADDRESS=a.b.c.d |
|<===============================================|
| |
Figure 5: Failed Flow: Port Range Option Not Supported by the Server
図5：フローの失敗：サーバーによってサポートされていないポートレンジオプション
The main steps of this flow are listed below:
このフローの主な手順を以下に示します。
(1) The Host sends a first Configure-Request, which includes the set of options it desires to negotiate. All of these configuration options are negotiated simultaneously. In this step, the Configure-Request carries the codes of the IP-Address, Port Range Value, and Port Range Mask options. The IP-Address Option is set to 0.0.0.0, the Port Range Value is set to 0, and the Port Range Mask is set to 0.
(1) ホストは、交渉を望む一連のオプションを含む最初のConfigure-Requestを送信します。これらの構成オプションはすべて同時にネゴシエートされます。このステップでは、Configure-Requestには、IPアドレス、ポートレンジ値、およびポートレンジマスクオプションのコードが搭載されています。IPアドレスオプションは0.0.0.0に設定され、ポート範囲値は0に設定され、ポートレンジマスクは0に設定されています。
(2) The BRAS sends back a Configure-Reject to decline the Port Range Option.
(2) ブラジャーは、configure-rejectを送り返し、ポートレンジオプションを拒否します。
(3) The Host sends a Configure-Request, which includes only the codes of the IP-Address Option. In this step, the IP-Address Option is set to 0.0.0.0.
(3) ホストは、IPアドレスオプションのコードのみを含むConfigure-Requestを送信します。このステップでは、IPアドレスオプションは0.0.0.0に設定されています。
(4) The BRAS sends back a Configure-Nak and sets the enclosed option to its preferred value. In this step, the IP-Address Option is set to a.b.c.d.
(4) ブラジャーはConfigure-nakを送り返し、囲まれたオプションを優先値に設定します。このステップでは、IPアドレスオプションはA.B.C.Dに設定されています。
(5) The Host re-sends a Configure-Request requesting that the IP-Address Option be set to a.b.c.d.
(5) ホストは、IP-AddressオプションをA.B.C.Dに設定するように設定するConfigure-Requestを再送信します。
(6) The BRAS sends a Configure-Ack message.
(6) ブラジャーは、configure-ackメッセージを送信します。
As a result of this exchange, the Host is configured to use a.b.c.d as its local IP address. This IP address is not a shared IP address.
この交換の結果、ホストはA.B.C.DをローカルIPアドレスとして使用するように構成されています。このIPアドレスは、共有IPアドレスではありません。
Figure 6 depicts exchanges where only shared IP addresses are assigned to end-users' devices. The server is configured to assign only shared IP addresses. If Port Range options are not enclosed in the configuration request, the request is rejected, and the requesting peer will be unable to access the service.
図6は、共有IPアドレスのみがエンドユーザーのデバイスに割り当てられている交換を示しています。サーバーは、共有IPアドレスのみを割り当てるように構成されています。構成要求にポートレンジオプションが囲まれていない場合、リクエストは拒否され、リクエストピアはサービスにアクセスできません。
+-----+ +-----+
| Host| | BRAS|
+-----+ +-----+
| |
| (1) IPCP Configure-Request |
| IP ADDRESS=0.0.0.0 |
|===============================================>|
| |
| (2) IPCP Protocol-Reject |
|<===============================================|
| |
Figure 6: Port Range Option Not Supported by the Client
図6：クライアントによってサポートされていないポートレンジオプション
The main steps of this flow are listed below:
このフローの主な手順を以下に示します。
(1) The Host sends a Configure-Request requesting that the IP-Address Option be set to 0.0.0.0, and without enclosing the Port Range Option.
(1) ホストは、ip-addressオプションを0.0.0.0に設定し、ポート範囲オプションを囲むことなく、Configure-Requestを要求します。
(2) The BRAS sends a Protocol-Reject message.
(2) ブラジャーは、プロトコル拒否メッセージを送信します。
As a result of this exchange, the Host is not able to access the service.
この交換の結果、ホストはサービスにアクセスできません。
This document does not introduce any security issues in addition to those related to PPP. Service providers should use authentication mechanisms such as the Challenge Handshake Authentication Protocol (CHAP) [RFC1994] or PPP link encryption [RFC1968].
この文書は、PPPに関連するものに加えて、セキュリティの問題を導入しません。サービスプロバイダーは、チャレンジハンドシェイク認証プロトコル（CHAP）[RFC1994]やPPPリンク暗号化[RFC1968]などの認証メカニズムを使用する必要があります。
The use of small and non-random port ranges may increase host exposure to attacks, as described in [RFC6056]. This risk can be reduced by using larger port ranges, by using the random Port Range Option, or by activating means to improve the robustness of TCP against blind in-window attacks [RFC5961].
[RFC6056]に記載されているように、小型および非ランダムポート範囲の使用は、攻撃への宿主暴露を増加させる可能性があります。このリスクは、より大きなポート範囲を使用して、ランダムポート範囲オプションを使用することで、または盲目のウィンドウ攻撃[RFC5961]に対するTCPの堅牢性を改善する手段をアクティブにすることで減らすことができます。
Jean-Luc Grimault and Alain Villefranque contributed to this document.
Jean-Luc GrimaultとAlain Villefranqueがこの文書に貢献しました。
The authors would like to thank C. Jacquenet, J. Carlson, B. Carpenter, M. Townsley, and J. Arkko for their review.
著者は、C。Jacquenet、J。Carlson、B。Carpenter、M。Townsley、およびJ. Arkkoのレビューに感謝したいと思います。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661] Simpson、W.、ed。、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月。
[RFC1968] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.
[RFC1968] Meyer、G。、「PPP暗号化制御プロトコル（ECP）」、RFC 1968、1996年6月。
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994]シンプソン、W。、「PPPチャレンジハンドシェイク認証プロトコル（CHAP）」、RFC 1994、1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2153] Simpson, W., "PPP Vendor Extensions", RFC 2153, May 1997.
[RFC2153]シンプソン、W。、「PPPベンダー拡張機能」、RFC 2153、1997年5月。
[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月。
[CGN-REQS] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common requirements for Carrier Grade NAT (CGN)", Work in Progress, October 2011.
[cgn-reqs] Perreault、S.、ed。、Yamagata、I.、Miyakawa、S.、Nakagawa、A。、およびH. Ashida、「キャリアグレードNAT（CGN）の共通要件」、進行中の作業、10月2011年。
[CIPHERS] Black, J. and P. Rogaway, "Ciphers with Arbitrary Finite Domains. Topics in Cryptology", CT-RSA 2002, Lecture Notes in Computer Science, vol. 2271, 2002.
[暗号] Black、J。およびP. Rogaway、「任意の有限ドメインを持つ暗号。暗号学のトピック」、CT-RSA 2002、コンピューターサイエンスの講義ノート、Vol。2271、2002。
[PORT-RANGE-ARCH] Boucadair, M., Ed., 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-Arch] Boucadair、M.、Ed。、Levis、P.、Bajko、G。、およびT. Savolainen、「IPv4アドレスのコンテキストでのIPv4接続アクセス：ポートレンジベースのIPアーキテクチャ」、作業進行中、2009年7月。
[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月。
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
[RFC6269] Ford、M.、Ed。、Boucadair、M.、Durand、A.、Levis、P.、およびP. Roberts、「IPアドレス共有の問題」、RFC 6269、2011年6月。
[RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, August 2011.
[RFC6346] Bush、R.、ed。、「IPv4アドレス不足に対するアドレスプラスポート（A P）アプローチ」、RFC 6346、2011年8月。
[SAM] Despres, R., "Scalable Multihoming across IPv6 Local-Address Routing Zones Global-Prefix/Local-Address Stateless Address Mapping (SAM)", Work in Progress, July 2009.
[SAM] Despres、R。、「IPv6ローカルアドレスルーティングゾーングローバルプレフィックス/ローカルアドレスステートレスアドレスマッピング（SAM）全体でスケーラブルなマルチホミング」、2009年7月の作業進行中。
Authors' Addresses
著者のアドレス
Mohamed Boucadair France Telecom Rennes 35000 France
Mohamed Boucadair France Telecom Rennes 35000 France
EMail: mohamed.boucadair@orange.com
Pierre Levis France Telecom Caen France
ピエール・レビス・フランス・テレコム・カエン・フランス
EMail: pierre.levis@orange.com
Gabor Bajko Nokia
Gabor Bajko Nokia
EMail: gabor.bajko@nokia.com
Teemu Savolainen Nokia
Teemu Savolainen Nokia
EMail: teemu.savolainen@nokia.com
Tina Tsou Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050 USA
Tina Tsou Huawei Technologies（USA）2330 Central Expressway Santa Clara、CA 95050 USA
Phone: +1 408 330 4424
EMail: tina.tsou.zouting@huawei.com