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)
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.
この文書では、ポートのセットを伝達するために使用される二つの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 Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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アドレスを共有することが検討されています。 2種類を区別することができる：NATベースのソリューション（例えば、キャリアグレードNAT（CGN）CGN-REQS]）とポート範囲ベースのソリューション（例えば、[RFC6346] [PORT-RANGE-ARCH] [SAM]）。ポート範囲ベースのソリューションは、サービスプロバイダーのドメインに追加の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ベースのソリューションで使用することができます。これらのオプションは、NATをバイパスする（透明NATトラバーサルのためのすなわち、パスのいくつかのNATのレベルを含む避けるために）、または避けるために、例えば（要求元のクライアントに1またはポートのセットを委任するCGNのコンテキストで使用することができますALG（アプリケーションレベルゲートウェイ）、またはポート転送のため）。
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アドレスに属するポートの範囲および静的クライアントの内部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).
組織固有識別子（OUI）O：このフィールドは781DBA（16進数）に設定されています。
o Kind: This field is set to F0 (hex).
カインドO：このフィールドは、F0（16進数）に設定されています。
o Value(s): The content of this field is specified in Sections 2.1 and 2.2.2.
O値（S）：このフィールドの内容はセクション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構成オプションは、リンクのローカルエンドで使用するポート範囲を交渉する方法を提供します。これは、ポート範囲は、与えられたIPアドレスに関連付けられた状態に設定要求メッセージの送信者が望まれる、またはピア構成を提供することを要求することを可能にします。ピアは、オプションをNAKing、および有効なポート範囲（すなわち、（ポート範囲値、ポート範囲マスクを））返すことによって、この情報を提供することができます。
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ポート範囲オプションで搬送ポートのセットは、（例えば、リクエストを終了したときに終了肯定応答が交換される）リンクがアップしなくなったときに取り消されます。
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で定義されたフォーマットに準拠しています。ポート範囲IPCPオプションを搬送する際に、[RFC2153]で定義されたオプションの「値（複数可）」フィールドは、図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番目のビットを持っている必要があり、そしてPPP IPCPにより搬送される構成を実施するとき1に設定し、左から6番目のビットはこれらのポート値は、ピアによって使用されるであろう。
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.
委任ランダムポートは、入力として、キー「K」と1024〜65535のポート範囲内の整数「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]の「付録B.宇宙倍数因子のアドレス」を参照）を使用します。この現象は、エフェメラルポート選択アルゴリズムの全体の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.
入力として、キーK（例えば、128ビット）を受け取り、整数x（平文）1024〜65535のポート範囲で、出力Yを生成する暗号化機構の暗号化関数yを使用= E（K、X）また、（暗号文）、1024〜65535のポート範囲の整数。このセクションでは、そのような暗号化機能を説明するが、他のものも可能です。
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ランダムポートは、それが出発点を「」（1024 <= A <= 65536から2048）は、そのポート範囲（選択します2048）、E（K、A + 1）、E（K、A + 2）、···、E（K、A、他のアクティブなクライアントと重複し、値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のに使用されるキーKを学習IP1がIPv4を攻撃するには役に立たない対処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は128ビット、DESのための64ビット - 、入力（平文）と出力（暗号文）（例えば、AESやDESなどの）一般的な暗号化機能を用いて、いくつかの固定サイズのブロックです。ポートのランダム化のために、我々は、その入力および出力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つの可能な方法は、基礎となるラウンド関数としてAESで、黒とRogawayによって「一般化Feistel暗号」[暗号]建設を使用することです。
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]
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ポート番号のリストを生成するには、AESには約6000のコールは（すなわち、96キロバイトを暗号化）が必要とされています。したがって、それは行うことができます任意のデバイス、例えば、HTTPS（セキュア・ソケット・レイヤー/トランスポート層セキュリティ（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で定義されたフォーマットに準拠します。 「値（S）は、」暗号ランダムポート範囲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設定要求に含まれている場合は、「キー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メッセージの交渉におけるオプションの使用方法は、（リクエスト/ / 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メッセージは、ホストとBRAS（ブロードバンドリモートアクセスサーバ）との間で交換されます。
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）ホストは、それが交渉を希望するオプションのセットを含む第1の設定要求を送信します。これらの設定オプションのすべてが同時に交渉しています。このステップでは、設定要求は、IPアドレス、ポート範囲値、およびポート範囲のマスクについての情報を運びます。 IP-addressオプションが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）BRASを設定-NAKを返送し、その好ましい値に囲まれたオプションを設定します。このステップでは、IP-addressオプションが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アドレスオプションがA.B.C.Dに設定することを要求する設定要求を再送信し、ポート範囲の値を80に設定すること、およびポート範囲マスクを496に設定すること。
(4) The BRAS sends a Configure-Ack message.
（4）BRASを設定肯定応答メッセージを送信します。
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):
この交換の結果として、ホストはそのローカルIPアドレスとしてA.B.C.Dを使用するように構成されており、以下の128個の連続したポートがポート・マスクから生じる範囲（ポート範囲値== 0、ポート範囲は== 496をマスク）：
- 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は、BRASは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：失敗したフロー：Serverでサポートされていないポート範囲オプション
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）ホストは、それが交渉を希望するオプションのセットを含む第1の設定要求を送信します。これらの設定オプションのすべてが同時に交渉しています。このステップでは、設定要求は、IPアドレス、ポート範囲値、およびポート範囲のマスクオプションのコードを運びます。 IP-addressオプションが0.0.0.0に設定されている、ポート範囲の値は0に設定されており、ポート範囲マスクが0に設定されています。
(2) The BRAS sends back a Configure-Reject to decline the Port Range Option.
（2）BRASは、ポート範囲のオプションを辞退する設定が拒否送り返します。
(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アドレスオプションのみコードを含む設定要求を送信します。このステップでは、IP-addressオプションは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）BRASを設定-NAKを返送し、その好ましい値に囲まれたオプションを設定します。このステップでは、IP-addressオプションは、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アドレスオプションは、A.B.C.Dに設定することを要求する設定要求を再送信します
(6) The BRAS sends a Configure-Ack message.
（6）BRASを設定肯定応答メッセージを送信します。
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.
この交換の結果、ホストは、そのローカルIPアドレスとしてA.B.C.Dを使用するように設定されています。この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に設定することを要求する設定要求を送信し、ポート範囲のオプションを囲むなし。
(2) The BRAS sends a Protocol-Reject message.
（2）BRASは、プロトコル拒否メッセージを送信します。
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.
ジャン=リュック・グリモーとアランVillefranqueは、この文書に貢献しました。
The authors would like to thank C. Jacquenet, J. Carlson, B. Carpenter, M. Townsley, and J. Arkko for their review.
作者は彼らのレビューのためにC. Jacquenet、J.カールソン、B.大工、M. Townsley、およびJ. Arkkoに感謝したいと思います。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W.、編、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[RFC1968] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.
[RFC1968]マイヤー、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、スチュワート、R.、およびM. Dalal、RFC 5961、2010年8月 "ブラインドウィンドウ攻撃に対してTCPのロバスト性を向上させます"。
[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]ペロー、S.、エド。、山形、I.、宮川、S.、中川、A.、およびH.芦田、 "キャリアグレード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.
[暗号]ブラック、J.とP. Rogawayは、「任意の有限領域を持つ暗号は暗号学のトピックは」CT-RSA 2002は、コンピュータサイエンス、巻でノートレクチャー。 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、 "IPアドレス枯渇問題のコンテキストにおけるIPv4の接続アクセス：ポート範囲ベースのIPアーキテクチャ" M.、エド、リーバイス、P.、Bajko、G.、およびT. Savolainenの、。、仕事進捗7月2009インチ
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, January 2011.
[RFC6056]ラーセン、M.とF. Gont、BCP 156、RFC 6056、2011年1月 "トランスポート・プロトコルポートランダム化のための提言"。
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
[RFC6269]フォード、M.、エド。、Boucadair、M.、デュラン、A.、リーバイス、P.、およびP.ロバーツ、RFC 6269、2011年6月、 "IPアドレスの共有に関する問題"。
[RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, August 2011.
[RFC6346]ブッシュ、R.、エド。、 "アドレスプラス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]デプレ、R.、「グローバル・プレフィックス/ローカルアドレスステートレスアドレスマッピング（SAM）は、IPv6ローカルアドレスルーティングゾーン全体でスケーラブルマルチホーミング」、進歩、2009年7月での作業。
Authors' Addresses
著者のアドレス
Mohamed Boucadair France Telecom Rennes 35000 France
モハメド・Boucadairフランステレコム35000レンヌフランス
EMail: mohamed.boucadair@orange.com
メールアドレス：mohamed.boucadair@orange.com
Pierre Levis France Telecom Caen France
ピエール・リーバイスフランステレコムカーンフランス
EMail: pierre.levis@orange.com
メールアドレス：pierre.levis@orange.com
Gabor Bajko Nokia
ガボールノキアBajko
EMail: gabor.bajko@nokia.com
メールアドレス：gabor.bajko@nokia.com
Teemu Savolainen Nokia
テームSavolainenのノキア
EMail: teemu.savolainen@nokia.com
メールアドレス：teemu.savolainen@nokia.com
Tina Tsou Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050 USA
ティナツオウ華為技術（USA）2330セントラルエクスプレスサンタクララ、CA 95050 USA
Phone: +1 408 330 4424 EMail: tina.tsou.zouting@huawei.com
電話：+1 408 330 4424 Eメール：tina.tsou.zouting@huawei.com