Softwire Working Group M. Boucadair
Internet-Draft France Telecom
Intended status: Standards Track N. Skoberne
Expires: March 8, 2012 Viris
W. Dec
Cisco
September 5, 2011
Analysis of Port Indexing Algorithms
draft-bsd-softwire-stateless-port-index-analysis-00
Abstract
This document analyzes various algorithm proposals for building port
sets. These algorithms are used to encode the range of ports in an
IPv6 address and prefix in the context of stateless solutions. The
ultimate goal of this analysis is to converge on one or a set of
algorithms to be used by all stateless solutions.
This is a companion document to
[I-D.boucadair-softwire-stateless-rfc6052-update].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 8, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
Boucadair, et al. Expires March 8, 2012 [Page 1]
Internet-Draft Port Set Analysis September 2011
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Analysis of Proposed Schemes to Encode Port Sets . . . . . . . 4
2.1. Address Formats and Port-Set Derivation Algorithms . . . . 5
2.1.1. Format: portrange . . . . . . . . . . . . . . . . . . 5
2.1.1.1. Address Format . . . . . . . . . . . . . . . . . . 5
2.1.1.2. Port-Set Derivation Algorithm . . . . . . . . . . 6
2.1.2. Format: Non-contiguous portrange . . . . . . . . . . . 8
2.1.2.1. Address Format . . . . . . . . . . . . . . . . . . 8
2.1.2.2. Port-Set Derivation Algorithm . . . . . . . . . . 8
2.1.3. Format: divi . . . . . . . . . . . . . . . . . . . . . 10
2.1.3.1. Address Format . . . . . . . . . . . . . . . . . . 10
2.1.3.2. Port-Set Derivation Algorithm . . . . . . . . . . 12
2.1.4. Format: divi-pd . . . . . . . . . . . . . . . . . . . 14
2.1.4.1. Address Format . . . . . . . . . . . . . . . . . . 14
2.1.4.2. Port-Set Derivation Algorithm . . . . . . . . . . 15
2.1.5. Format: murakami-4rd . . . . . . . . . . . . . . . . . 16
2.1.5.1. Address Format . . . . . . . . . . . . . . . . . . 16
2.1.5.2. Port-Set Derivation Algorithm . . . . . . . . . . 17
2.1.6. Format: despres-4rd . . . . . . . . . . . . . . . . . 19
2.1.6.1. Address Format . . . . . . . . . . . . . . . . . . 19
2.1.6.2. Port-Set Derivation Algorithm . . . . . . . . . . 20
3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Normative References . . . . . . . . . . . . . . . . . . . 23
7.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Boucadair, et al. Expires March 8, 2012 [Page 2]
Internet-Draft Port Set Analysis September 2011
1. Introduction
Several solutions have been proposed in the past to embed the port
information in an IPv4-embedded IPv6 address or IPv4-translatable
IPv6 prefix. Below is provided a list of these solutions (in no
particular order):
o [I-D.boucadair-behave-ipv6-portrange]
o [I-D.xli-behave-divi]
o [I-D.murakami-softwire-4v6-translation]
o [I-D.murakami-softwire-4rd]
o [I-D.despres-softwire-4rd-addmapping]
For interoperability purposes, the softwire WG should converge to one
address format to be used in the context of stateless 4/6 solutions.
This memo aims at analyzing the proposed algorithms to convey the
port information in an IPv4-embedded IPv6 address/prefix and
hopefully make a recommendation on the address format to be used by
stateless 4/6 solutions.
This document is a companion document to
[I-D.boucadair-softwire-stateless-rfc6052-update].
For further information about the motivations for stateless
solutions, the reader is invited to refer to
[I-D.operators-softwire-stateless-4v6-motivation].
1.1. Terminology
This document makes use of the following terms:
o IPv4-translatable IPv6 address/prefix: denotes an IPv6 address/
prefix assigned to an IPv6 node for use with stateless IPv4-IPv6
translation [RFC6052].
o DomPref: or Domain Prefix, is a prefix belonging to the service
provider. The length of this field is variable (may be different
from a service provider to another).
o PRD: Port Restricted Device. A device, which can only use a
subset (Port-Set) of all 2^16 transport-layer ports.
o Port-Set: A set of ports, allocated to a PRD for the purpose of
IPv4 address sharing.
o @v4: encloses 32-bits or only some bits of the shared IPv4
address.
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Boucadair, et al. Expires March 8, 2012 [Page 3]
Internet-Draft Port Set Analysis September 2011
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Analysis of Proposed Schemes to Encode Port Sets
First we list and describe all proposed address formats and port-set
derivation algorithms. Next, we compare and analyze them. The
following template is used to describe the properties of each port
set derivation scheme:
o Complexity: Complexity level of the algorithm
o Address Sharing Ratio: Number of users sharing the same IPv4
address
o Number of ports in a Port-Set: Number of assigned ports
o Guessing Complexity of a Valid Port: Level of complexity to guess
a valid port within the assigned port set
o Guessing Complexity of the whole Port-Set: Level of complexity to
guess the whole assigned port set
o Excluded ports: Indicates whether ports are from the assigned port
set. This provides a hint about the efficiency of the port set
algorithm.
o Minimal Sharing Ratio: Minimum number of users able to share the
same IPv4 address
o Maximal Sharing Ratio: Maximum number of users able to share the
same IPv4 address
o Multiple Port Ranges: Capability to assign multiple contiguous
port ranges to a single PRD
o Differentiated Port Ranges: Capability to assign port ranges of
different sizes to customers attached to the same network.
o DomPref Flexibility: Ability to support DomPref prefixes of
different lengths.
o IPv4 traffic isolation: Ability to distinguish between IPv4-
embedded IPv6 traffic and native IPv6 traffic
o Prefix Aggregation: Impact on prefix aggregation
o Encode Routing Bits in 64 bits: Ability to encode all routing bits
in 64
o Compliancy with RTP/RTCP: Compatibility with RTP/RTCP applications
In each analyzed port derivation algorithm, an attacker may implement
a redirection loop to detect a significant amount of allowed ports.
For all monotonously scattered schemes, the whole Port-Set may be
deduced by extrapolation while this is not applicable for contiguous
port ranges (because no information about port bounds is leaked in
the IPv4-translatable IPv6 address).
Boucadair, et al. Expires March 8, 2012 [Page 4]
Internet-Draft Port Set Analysis September 2011
2.1. Address Formats and Port-Set Derivation Algorithms
We have assigned nicknames to address formats (and corresponding
port-set derivation algorithms) so we can refer to them easily.
2.1.1. Format: portrange
These prefix and address formats have been documented in
[I-D.boucadair-behave-ipv6-portrange].
[I-D.boucadair-dhcpv6-shared-address-option] defines the DHCPv6
options to convey the shared IPv4 address, port range and the prefix
to use to build IPv4-converted IPv6 addresses. Additional options
are defined in [I-D.boucadair-dhcpv6-shared-address-option] such as
retrieving the address formats supported by a PRD.
2.1.1.1. Address Format
The address format is shown in Figure 1. The service provider has to
delegate specially formatted prefixes to CPEs, which also encode
shared IPv4 address and Port Range Mask (PRM). By choosing the
length of Domain Prefix (DomPref) and by choosing the length of
delegated prefix, the length of PRM field is determined, and
therefore the address sharing ratio as well. The same format is used
to build IPv4-embedded IPv6 addresses; instead of encoding the PRM
the destination/source port are enclosed in the address.
0 127
+---------------+-----------+-----+---+-----------------------------+
| DomPref | @v4 | PRM + p | zero |
+---------------+-----------+-----+---+-----------------------------+
<------n------> <----32---> <---16--> <------------80-n----------->
<-----------------L------------->
Figure 1: "portrange" prefix format
Description of attributes:
PRM: (Port Range Mask) are the significant bits of the Port Range.
The maximum length of this field is 16 bits. The length of this
field is determined by prefix length.
p: variable bits of the port range. Together with PRM they form the
destination port number.
n: prefix length of DomPref.
Boucadair, et al. Expires March 8, 2012 [Page 5]
Internet-Draft Port Set Analysis September 2011
L: prefix length of the prefix delegated to a PRD.
2.1.1.2. Port-Set Derivation Algorithm
The algorithm is very straightforward and produces Port-Sets as
consecutive ranges of ports, one for each PRD. The bits of Port
Range Mask determine the fixed bits in all port numbers the PRD can
use. All other bits are variable. An example of Port Set
calculation is shown on Figure 2.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0| Port Range Mask
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| | | (3 significant bits)
v v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0| Port Range Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 x x x x x x x x x x x x x| Usable ports (x are variable bits).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: "portrange" Port-Set derivation algorithm.
The properties of the algorithm are shown in Table 1.
Boucadair, et al. Expires March 8, 2012 [Page 6]
Internet-Draft Port Set Analysis September 2011
+-------------------------------------------+--------------+
| Property | Value |
+-------------------------------------------+--------------+
| Complexity | Low |
| Address Sharing Ratio | 1:2^(L-n-32) |
| Number of ports in a Port-Set | 2^(48-L+n) |
| Guessing Complexity of a Valid Port | Low |
| Guessing Complexity of the whole Port-Set | Medium |
| Excluded ports | None |
| Minimal Sharing Ratio | 1:1 |
| Maximal Sharing Ratio | 1:65536 |
| Multiple Port-Sets | Supported |
| Differentiated Port-Sets | Supported |
| DomPref Flexibility | High |
| IPv4 traffic Isolation | Supported |
| Prefix Aggregation | Preserved |
| Encode Routing Bits in 64 bits | Supported |
| Compliancy with RTP/RTCP | Compliant |
+-------------------------------------------+--------------+
Table 1: Properties of "portrange" algorithm
Note that in practice, the sharing ratio will probably be
significantly lower than Maximal Sharing Ratio, since each PRD has to
have a certain amount of available ports to operate normally. Also,
Domain Prefix length has to be very short in order to achieve high
sharing ratios, which may be difficult to achieve if all the bits are
to be encoded in the first 64 bits of the IPv4-translatable IPv6
prefix.
For illustration purposes let's assume an environment with the
following parameters:
o Domain Prefix (DomPref): 2001:db8::/29
o Number of PRDs sharing an IPv4 address: 8
o Shared IPv4 address: 203.0.113.10
Using the parameters above, we can assign the following 8 prefixes
and Port-Sets to 8 PRDs:
o PRD 1:
Delegated Prefix: 2001:dbe:5803:8850::/64
Port-Set: 0-8191
o PRD 2:
Delegated Prefix: 2001:dbe:5803:8851::/64
Boucadair, et al. Expires March 8, 2012 [Page 7]
Internet-Draft Port Set Analysis September 2011
Port-Set: 8192-16383
o ...
o PRD 8:
Delegated Prefix: 2001:dbe:5803:8857::/64
Port-Set: 57344-65535
2.1.2. Format: Non-contiguous portrange
These prefix and address formats have been defined in
[I-D.boucadair-behave-ipv6-portrange].
2.1.2.1. Address Format
The address format is shown in Figure 1. The only difference
compared to portrange is that port values are encoded using the LSB
order instead of the MSB. This leads to generating monotonously
scattered ports.
Note: Other advanced modes to assign non-contiguous port ranges
have been investigated ([I-D.boucadair-pppext-portrange-option])
such as:
1. Assign 64 Port Ranges with one single Port Mask: e.g., if the
Port Mask is set to 768 and the address is shared between 4
PRDs, 64 contiguous Port Ranges can be assigned to each PRD,
there is always one within the span of the first 1024 well-
known port values.
2. Assign 128 Port Ranges with one single Port Mask: e.g., if the
Port Mask is set to 496 and the address is shared between 32
PRDs, 128 contiguous Port Ranges can be assigned to each PRD,
each one with a length of 16 port values. The first two Port
Ranges are both in the well-known ports span (i.e. 0-1023).
Porting these advanced port assignment modes to stateless
solutions would require more complexity in encoding the Port
Mask's significant bits in the IPv4-embedded IPv6 address.
2.1.2.2. Port-Set Derivation Algorithm
The algorithm is very straightforward and produces Port-Sets as non-
contiguous ports. The bits of the Port Range Mask determine the
fixed bits in all port numbers the PRD can use. All other bits are
variable.
Boucadair, et al. Expires March 8, 2012 [Page 8]
Internet-Draft Port Set Analysis September 2011
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0| Port Range Mask
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| | | (3 significant bits)
v v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0| Port Range Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LSB MSB
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 x x x x x x x x x x x x x| Usable ports (x are variable bits).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Non-Contiguous "portrange" Port-Set Derivation Algorithm.
The properties of the algorithm are shown in Table 2.
+-------------------------------------------+---------------+
| Property | Value |
+-------------------------------------------+---------------+
| Complexity | Low |
| Address Sharing Ratio | 1:2^(L-n-32) |
| Number of ports in a Port-Set | 2^(48-L+n) |
| Guessing Complexity of a Valid Port | Medium |
| Guessing Complexity of the whole Port-Set | Low |
| Excluded ports | None |
| Minimal Sharing Ratio | 1:1 |
| Maximal Sharing Ratio | 1:65536 |
| Multiple Port-Sets | Not supported |
| Differentiated Port-Sets | Supported |
| DomPref Flexibility | High |
| IPv4 traffic Isolation | Supported |
| Prefix Aggregation | Preserved |
| Encode Routing Bits in 64 bits | Supported |
| Compliancy with RTP/RTCP | Not Compliant |
+-------------------------------------------+---------------+
Table 2: Properties of a non-contiguous "portrange" algorithm
For illustration purposes, let's assume an environment with the
following parameters:
o Domain Prefix (DomPref): 2001:db8::/29
Boucadair, et al. Expires March 8, 2012 [Page 9]
Internet-Draft Port Set Analysis September 2011
o Number of PRDs sharing an IPv4 address: 8
o Shared IPv4 address: 203.0.113.10
Using the parameters above, we can assign the following 8 prefixes
and Port-Sets to 8 PRDs:
o PRD 1:
Delegated Prefix: 2001:dbe:5803:8850::/64
Port-Set: 0, 8, 16, ...
o PRD 2:
Delegated Prefix: 2001:dbe:5803:8851::/64
Port-Set: 1, 9, 17, ...
o ...
o PRD 8:
Delegated Prefix: 2001:dbe:5803:8857::/64
Port-Set: 7, 15, 23, ...
2.1.3. Format: divi
The basis for this address format has been defined in [RFC6052] and
has been extended in [I-D.xli-behave-divi], where suffix is defined
which contains Port-Set information.
This document does not specify an IPv4 address sharing mechanism with
prefix delegation. Prefix delegation is supported in
[I-D.xli-behave-divi-pd].
2.1.3.1. Address Format
The address format is shown in Figure 4. Each PRD in the access
network is assigned a special IPv6 address, which embeds the shared
IPv4 address and the Port-Set. IPv6 addressing in the network behind
the PRD (if any) must be considered a separate issue.
Only Domain Prefixes of lengths 32, 40, 48, 56 and 64 are supported.
Boucadair, et al. Expires March 8, 2012 [Page 10]
Internet-Draft Port Set Analysis September 2011
a) DomPref Length = 32
0 32 64 72 88 127
+----------------+----------------+---+--------+--------------------+
| DomPref | @v4(32) | u | suffix | zero |
+----------------+----------------+---+--------+--------------------+
<------32------> <------32------> <8> <--16--> <--------40-------->
b) DomPref Length = 40
0 40 64 72 80 96 127
+--------------------+------------+---+---+--------+----------------+
| DomPref | @v4(24) | u |(8)| suffix | zero |
+--------------------+------------+---+---+--------+----------------+
<--------40--------> <----24----> <8> <8> <--16--> <------32------>
c) DomPref Length = 48
0 48 64 72 88 104 127
+------------------------+--------+---+-------+--------+------------+
| DomPref |@v4(16) | u |@v4(16)| suffix | zero |
+------------------------+--------+---+-------+--------+------------+
<----------48----------> <--16--> <8> <--16-> <--16--> <----24---->
d) DomPref Length = 56
0 56 64 72 96 112 127
+-----------------------------+---+---+-----------+--------+--------+
| DomPref |(8)| u | @v4(24) | suffix | zero |
+-----------------------------+---+---+-----------+--------+--------+
<-------------56------------> <8> <8> <----24---> <--16--> <--16-->
e) DomPref Length = 64
0 64 72 104 120
+---------------------------------+---+---------------+--------+----+
| DomPref | u | @v4(32) | suffix |zero|
+---------------------------------+---+---------------+--------+----+
<---------------64--------------> <8> <------32-----> <--16--> <8->
Figure 4: "divi" address format
Description of attributes:
Boucadair, et al. Expires March 8, 2012 [Page 11]
Internet-Draft Port Set Analysis September 2011
u: bits 64 to 71 of the address are reserved for compatibility with
the host identifier format defined in the IPv6 addressing
architecture [RFC4291]. These bits MUST be set to zero.
suffix: 16-bit suffix is composed of 4-bit exponent E and 12-bit K
values.
E: exponent used to obtain the sharing ratio N, maximum value is 12.
N: sharing ratio, which is 1:N. N is calculated as 2^E. The maximum
sharing ratio is 1:4096.
K: node index.
2.1.3.2. Port-Set Derivation Algorithm
The algorithm uses the modulo operator to define Port-Set for each
PRD:
o For a given multiplexing ratio N, the port-set numbers of an IPv4-
translatable address with port-set-id K is composed of P=j*N + K +
1024, for all the values of j=0, 1, ..., (65536-N)/N.
o For a destination port number (P), the port-set-id of a given
IPv4-tanslatable address with port-set-id K is determined by the
modulo operation: K=((P-1024)%N) (% is the Modulus Operator).
For example, If N=128, then IPv6 node K=5 is only allowed to use port
numbers 1029, 1157, ... 65,413 as the source port, while the packets
with these port numbers as destination port numbers will be forwarded
to the IPv6 node with node index K=5. An example is provided by
Figure 5.
Boucadair, et al. Expires March 8, 2012 [Page 12]
Internet-Draft Port Set Analysis September 2011
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1|0 0 0 0 0 0 0 0 0 1 0 1| suffix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<--E--> <----------K---------->
\________ /
\ |
P = 1 * 2^E + K + 1024 (= j * N + K + 1024)
\_________
\
<--------------P-------------->
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0 1 0 0 0 0 1 0 1| second usable port (j=1)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: "divi" Port-Set derivation algorithm
The properties of the algorithm are shown in Table 3.
+-------------------------------------------+---------------+
| Property | Value |
+-------------------------------------------+---------------+
| Complexity | Medium (?) |
| Address Sharing Ratio | 1:N (1:2^E) |
| Number of ports in a Port-Set | 2^(16-E) |
| Guessing Complexity of a Valid Port | Medium |
| Guessing Complexity of the whole Port-Set | Low |
| Excluded ports | 0-1023 |
| Minimal Sharing Ratio | 1:1 |
| Maximal Sharing Ratio | 1:4096 |
| Multiple Port-Sets | Not supported |
| Differentiated Port-Sets | Not supported |
| DomPref Flexibility | Medium |
| IPv4 traffic Isolation | ?? |
| Prefix Aggregation | ?? |
| Encode Routing Bits in 64 bits | Not supported |
| Compliant with RTP/RTCP | Not compliant |
+-------------------------------------------+---------------+
Table 3: Properties of "divi" algorithm
For sharing ratios above 1024 users per IP address, port aliasing
becomes an issue leading to less fairness in the allocation of ports.
In other words, for sharing ratios above 1024, it is not possible to
assure that each user will receive exactly the same number of ports,
with some users receiving a port less than others. This effect goes
away when the reserved port limit is removed, which however possibly
Boucadair, et al. Expires March 8, 2012 [Page 13]
Internet-Draft Port Set Analysis September 2011
introduces unfairness in the allocation of well known ports.
The limit of 0-1023 ports may be seen as lost of port for service
providers.
For illustration purposes, let's assume an environment with the
following parameters:
o Domain Prefix (DomPref): 2001:db8::/32
o Number of PRDs sharing an IPv4 address: 128
o Shared IPv4 address: 203.0.113.10
Using the parameters above, we can assign the following 8 prefixes
and Port-Sets to 8 PRDs:
o PRD 1:
Assigned IPv6 address: 2001:db8:cb00:710a:0700:0000::
Port-Set: 1024, 1152, 1280, ..., 65408
o PRD 2:
Assigned IPv6 address: 2001:db8:cb00:710a:0700:1000::
Port-Set: 1025, 1153, 1281, ..., 65409
o ...
o PRD 8:
Assigned IPv6 address: 2001:db8:cb00:710a:0707:f000::
Port-Set: 1151, 1279, 1407, ..., 65535
2.1.4. Format: divi-pd
The basis for this address format has been defined in [RFC6052] and
has been modified in [I-D.xli-behave-divi-pd], where additional
suffix and CPE index are defined. Suffix contains Port-Set
information.
In contrast to [I-D.xli-behave-divi], divi-pd supports prefix
delegation scenarios.
2.1.4.1. Address Format
The address format is shown in Figure 6. Each PRD in the access
network is delegated a prefix of length 56 to 64 bits. This prefix
encodes the CPE index. It does not, however, encode the shared IPv4
address and/or the Port-Set. The delegated prefix can be used for
SLAAC to assign addresses behind the PRD, since the probability of
collision with IPv4-translatable addresses is supposed to be
neglectable.
Boucadair, et al. Expires March 8, 2012 [Page 14]
Internet-Draft Port Set Analysis September 2011
|0 |64 |72 |104 |120
+----------------+-----------+----+---+---------------+--------+----+
| DomPref | CPE index |zero| u | @v4(32) | suffix |zero|
+----------------+-----------+----+---+---------------+--------+----+
<------d-------> <---s+k---> <m-> <8> <------32-----> <--16--> <8->
Figure 6: "divi-pd" address format
Description of attributes:
u: bits 64 to 71 of the address are reserved for compatibility with
the host identifier format defined in the IPv6 addressing
architecture [RFC4291]. These bits MUST be set to zero.
suffix: 16-bit suffix is composed of 4-bit exponent E and 12-bit K
values.
E: exponent used to obtain the sharing ratio N, maximum value is 12.
N: sharing ratio, which is 1:N. N is calculated as 2^E. The maximum
sharing ratio is 1:4096.
K: node index.
CPE index: used to uniquely identify different CPEs in the specific
domain. For the reason of simplicity, the CPE index consists of
(k) bits identifying the IPv4 devices using different Port-Sets of
same IPv4 address and (s) bits for the IPv4 subnet to serve for
this specific domain.
2.1.4.2. Port-Set Derivation Algorithm
The algorithm is the same as in Figure 5.
For illustration purposes let's assume an environment with the
following parameters:
o Domain Prefix (DomPref): 2001:db8::/32
o Number of PRDs sharing an IPv4 address: 32
o Shared IPv4 subnet: 203.0.113.8/30 (2 addresses)
Using the parameters above, we can assign the following prefixes and
Port-Sets to 32 PRDs:
o PRD 1:
Assigned IPv6 prefix: 2001:db8:???
Boucadair, et al. Expires March 8, 2012 [Page 15]
Internet-Draft Port Set Analysis September 2011
Port-Set: 1024, 1056, 1088, ... 65504
o PRD 2:
Assigned IPv6 address: 2001:db8:???
Port-Set: 1025, 1057, 1089, ... 65505
o ...
o PRD 32:
Assigned IPv6 address: 2001:db8:???
Port-Set: 1026, 1058, 1090, ... 65506
2.1.5. Format: murakami-4rd
This address formats have been defined and used in
[I-D.murakami-softwire-4rd].
2.1.5.1. Address Format
The address format is shown in Figure 7. The service provider has to
delegate specially formatted prefixes to PRDs, which also encode an
IPv4 prefix, IPv4 address or a part of the shared IPv4 address and
the Port-Set ID, which together form EA-bits (Embedded Address). By
choosing the length of Domain Prefix (DomPref) and by choosing the
length of delegated prefix, the length of EA-bits is determined. By
also choosing the Domain 4rd prefix, it is determined if the EA-bits
encode an IPv4 prefix, IPv4 address or part of IPv4 address. For
more thorough definition of these terms see the original draft.
|0 <EA-bits> 127|
+--------------+-----+---+--------+---------------------------------+
| DomPref | 4RD | P | suffix | 0 |
+--------------+-----+---+--------+---------------------------------+
<------n-----> <p>
<-----------L---------->
<-----------max. 64------------->
Figure 7: "murakami-4rd" address format
Description of attributes:
4RD: Identifies an IPv4 prefix, IPv4 address or part of an IPv4
address (depending on the EA-bits length and Domain 4rd prefix
length).
Boucadair, et al. Expires March 8, 2012 [Page 16]
Internet-Draft Port Set Analysis September 2011
P: Port-Set ID. Uniquely identifies the Port-Set.
p: Port-Set ID length.
suffix: optional domain suffix. Can be used in 4rd mapping rules.
n: prefix length of DomPref.
L: prefix length of the prefix delegated to a PRD.
2.1.5.2. Port-Set Derivation Algorithm
The algorithm produces Port-Sets as ranges of ports, depending on the
length and the value of the Port-Set ID.
Each port range is prefixed with a different "head", followed by the
Port-Set ID. The remaining bits are variable bits in the port range.
An example of port range derivation from the Port-Set ID is shown in
Figure 8.
0 1 2 3 4 5 6
+-+-+-+-+-+-+-+
|1 0 1 1 0 1 0| Port-Set ID from EA-bits (7 bits in this example)
+-+-+-+-+-+-+-+
\ \
0| | 1
0|1 2 3 4 5 6 7|8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1 0 1 1 0 1 0|x x x x x x x x| Port-Range 1: 55808-56063
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1|1 0 1 1 0 1 0|x x x x x x x| Port-Range 2: 27904-28031
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1|1 0 1 1 0 1 0|x x x x x x| Port-Range 3: 13952-14015
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|1 0 1 1 0 1 0|x x x x x| Port-Range 4: 6976-7007
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<head-> <-----p----->
Figure 8: "murakami-4rd" Port-Set derivation algorithm
For lengths of Port-Set ID exceeding 12 bits, effectively
representing a 1:2^12 sharing ratio, successive heads are not
Boucadair, et al. Expires March 8, 2012 [Page 17]
Internet-Draft Port Set Analysis September 2011
applied, with the head + Port-Set ID lengths being limited to 16
bits. Thus, for a Port-Set ID length of 13 bits, only heads 0x1,
0x01, and 0x001 are applied. While for a port-set-id length of 14,
only heads 0x1 and 0x01 are applied, etc.
Let N be the length of the Port-Set ID. The number M of ports in
each Port-Set is given by:
------------------------------------------------------------
Range 1 Range 2 Range 3 Range 4 N
------------------------------------------------------------
M = { 2^(12-N) + 2^(13-N) + 2^(14-N) + 2^(15-N) ; N < 13
{ 2^(13-N) + 2^(14-N) + 2^(15-N) = 7 ; N = 13
{ 2^(14-N) + 2^(15-N) = 3 ; N = 14
{ 2^(15-N) = 1 ; N = 15
------------------------------------------------------------
Figure 9: Number of ports as a function of Port-Set ID length
The properties of the algorithm are shown in Table 4.
+-------------------------------------------+----------------+
| Property | Value |
+-------------------------------------------+----------------+
| Complexity | Medium |
| Address Sharing Ratio | 1:2^p |
| Number of ports in a Port-Set | See Figure 9 |
| Guessing Complexity of a Valid Port | Medium? |
| Guessing Complexity of the whole Port-Set | Medium |
| Excluded ports | 0-4095 |
| Minimal Sharing Ratio | 1:1 |
| Maximal Sharing Ratio | 1:32768 |
| Multiple Port-Sets | Supported |
| Differentiated Port-Sets | Not Supported? |
| DomPref Flexibility | High |
| IPv4 traffic Isolation | Supported? |
| Prefix Aggregation | Preserved |
| Encode Routing Bits in 64 bits | Supported |
| Compliancy with RTP/RTCP | Compliant (*) |
+-------------------------------------------+----------------+
Table 4: Properties of "murakami-4rd" algorithm.
(*) there is a risk N+1 be out of range.
Note that in practice, the sharing ratio will probably be
significantly lower than Maximal Sharing Ratio, since each PRD has to
have a certain amount of available ports to operate normally.
Boucadair, et al. Expires March 8, 2012 [Page 18]
Internet-Draft Port Set Analysis September 2011
The limit of 0-4095 ports appears rather arbitrary and represents a
likely waste of ports, if not more that an operator may be interested
in utilizing.
For each additional bit beyond 12 bits of port-indexing (i.e., when
the head is < 4 bits), the number of ports that cannot be used
increases by a factor of 2 from the 4096 limit. Thus, for a 13 bit
port-set-id, only ports above 8k can be used, ports above 16k for a
14 bit port-set-id, and for a 15 bit port-set-id, only ports above
32k can be used assigned, etc. The port usage efficiency with a 15
bit port-set id is 50%.
For illustration purposes, let's assume an environment with the
following parameters:
o Domain Prefix (DomPref): 2001:db8::/32
o Delegated Prefix length: 44
o 4rd prefix: 203.0.113.0/24
o Number of PRDs sharing an IPv4 address: 16
o Shared IPv4 address: 203.0.113.10
Using the parameters above, we can assign the following 16 prefixes
and Port-Sets to 16 PRDs:
o PRD 1:
Delegated Prefix: 2001:db8:0a00::/44
Port-Sets: 32768-34815, 16384-17407, 8192-8703, 4096-4351
o PRD 2:
Delegated Prefix: 2001:db8:0a01::/44
Port-Sets: 34816-36864, 17408-18432, 8704-9216, 4352-4608
o ...
o PRD 16:
Delegated Prefix: 2001:db8:0aff::/44
Port-Sets: 63488-65535, 31744-32767, 15872-16383, 7936-8191
2.1.6. Format: despres-4rd
This address formats have been defined and used in
[I-D.despres-softwire-4rd-addmapping].
2.1.6.1. Address Format
The address format is shown in Figure 10. The service provider has
to delegate specially formatted prefixes to PRDs, which also encode
an IPv4 prefix, IPv4 address or a part of the shared IPv4 address and
Boucadair, et al. Expires March 8, 2012 [Page 19]
Internet-Draft Port Set Analysis September 2011
the Port-Set ID, which together form EA-bits (Embedded Address). By
choosing the length of Domain Prefix (DomPref) and by choosing the
length of delegated prefix, the length of EA-bits is determined. By
also choosing the Domain 4rd prefix, it is determined if the EA-bits
encode an IPv4 prefix, IPv4 address or part of IPv4 address. For
more thorough definition of these terms see the original draft.
|0 <EA-bits> 127|
+-------------+-----+---+-----+---+--------------------+------------+
| DomPref | 4RD | P | suf | z | IID | addr |
+-------------+-----+---+-----+---+--------------------+------------+
<-----n-----> <p>
<-----------L--------->
<-----------max. 64------------->
Figure 10: "despres-4rd" address format
Description of attributes:
4RD Identifies an IPv4 prefix, IPv4 address or part of an IPv4
address (depending on the EA-bits length and Domain 4rd prefix
length).
P Port-Set ID. Uniquely identifies the Port-Set.
p Port-Set ID length.
suf: optional domain suffix. Can be used in 4rd mapping rules.
z: optional padding to 64 bits (if needed).
IID: 4rd IID prefix (TBD by IANA) for encapsulation-based or double-
translation based solutions OR zero per [RFC6145] for IPv6-only
PRDs.
addr: zero for encapsulation-based solutions OR the IPv4 address for
translation-based solutions.
n: prefix length of DomPref.
L: prefix length of the prefix delegated to a PRD.
2.1.6.2. Port-Set Derivation Algorithm
The algorithm produces Port-Sets as interleaved port-pairs, scattered
monotonously through the whole 2^16 port range, with the first 4096
ports excluded. The density depends on the length Port-Set ID.
Boucadair, et al. Expires March 8, 2012 [Page 20]
Internet-Draft Port Set Analysis September 2011
An example of port range derivation from the Port-Set ID is shown in
Figure 11. To exclude first 4096 ports, the value of the head bits
in the Port-Set pattern cannot be zero.
0 1 2 3 4 5 6
+-+-+-+-+-+-+-+
|1 0 1 1 0 1 0| Port-Set ID from EA-bits (7 bits in this example)
+-+-+-+-+-+-+-+
|
R....... Reverse bits left to right (ABC... => ...CBA)
|
| +-+-+-+-+-+-+-+
\------->|0 1 0 1 1 0 1| Reversed Port-Set ID
+-+-+-+-+-+-+-+
| |
| |
0| | 1 |
0|1 2 3 4 5 6 7|8 9 0 1 2 3 4|5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|y y y y|x x x x|0 1 0 1 1 0 1|x| Port-Set pattern, x are the variable bits
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<head-> <-----p----->
Figure 11: "despres-4rd" Port-Set derivation algorithm
The properties of the algorithm are shown in Table 5.
+-------------------------------------------+---------------------+
| Property | Value |
+-------------------------------------------+---------------------+
| Complexity | High |
| Address Sharing Ratio | 1:2^p |
| Number of ports in a Port-Set | 2^(16-p) - 2^(12-p) |
| Guessing Complexity of a Valid Port | Low |
| Guessing Complexity of the whole Port-Set | Medium |
| Excluded ports | 0-4095 |
| Minimal Sharing Ratio | 1:1 |
| Maximal Sharing Ratio | 1:2048 |
| Multiple Port Sets | Supported |
| Differentiated Port Sets | Not Supported |
| DomPref Flexibility | High (?) |
| IPv4 traffic Isolation | ??? |
| Prefix Aggregation | ??? |
| Encode Routing Bits in 64 bits | Supported |
| Compliancy with RTP/RTCP | Compliant (*) |
+-------------------------------------------+---------------------+
Boucadair, et al. Expires March 8, 2012 [Page 21]
Internet-Draft Port Set Analysis September 2011
Table 5: Properties of "despres-4rd" algorithm.
(*) there is a risk N+1 be out of range.
The limit of 0-4095 ports appears rather arbitrary and represents a
likely waste of ports, if not more that an operator may be interested
in utilizing.
For illustration purposes, let's assume an environment with the
following parameters:
o Domain Prefix (DomPref): 2001:db8::/32
o Delegated Prefix length: 44
o 4rd prefix: 203.0.113.0/24
o Number of PRDs sharing an IPv4 address: 16
o Shared IPv4 address: 203.0.113.10
Using the parameters above, we can assign the following 16 prefixes
and Port-Sets to 16 PRDs:
o PRD 1:
Delegated Prefix: 2001:db8:0a00::/44
Port-Set: 4096, 4097; 4128, 4129; ...; 65504, 65505
o PRD 2:
Delegated Prefix: 2001:db8:0a01::/44
Port-Set: 4098, 4099; 4130, 4131; ...; 65506, 65507
o ...
o PRD 16:
Delegated Prefix: 2001:db8:0aff::/44
Port-Set: 4126, 4127; 4128, 4129; ...; 65534, 65535
3. Conclusion
TBC.
4. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
Boucadair, et al. Expires March 8, 2012 [Page 22]
Internet-Draft Port Set Analysis September 2011
5. Security Considerations
Security considerations discussed in [RFC6052] should be taken into
account.
6. Acknowledgments
Many thanks to C. Jacquenet for his review.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
7.2. Informative References
[I-D.boucadair-behave-ipv6-portrange]
Boucadair, M., Levis, P., Grimault, J., Villefranque, A.,
Kassi-Lahlou, M., Bajko, G., Lee, Y., Melia, T., and O.
Vautrin, "Flexible IPv6 Migration Scenarios in the Context
of IPv4 Address Shortage",
draft-boucadair-behave-ipv6-portrange-04 (work in
progress), October 2009.
[I-D.boucadair-dhcpv6-shared-address-option]
Boucadair, M., Levis, P., Grimault, J., Savolainen, T.,
and G. Bajko, "Dynamic Host Configuration Protocol
(DHCPv6) Options for Shared IP Addresses Solutions",
draft-boucadair-dhcpv6-shared-address-option-01 (work in
progress), December 2009.
[I-D.boucadair-pppext-portrange-option]
Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and
T. Tsou, "Huawei Port Range Configuration Options for PPP
Boucadair, et al. Expires March 8, 2012 [Page 23]
Internet-Draft Port Set Analysis September 2011
IPCP", draft-boucadair-pppext-portrange-option-08 (work in
progress), August 2011.
[I-D.boucadair-softwire-stateless-rfc6052-update]
Boucadair, M., Skoberne, N., and W. Dec, "Embedding Port
Information in IPv4-Translatable IPv6 Prefixes and IPv4-
Embedded IPv6 Addresses", September 2011,
<draft-boucadair-softwire-stateless-rfc6052-update-00>.
[I-D.despres-softwire-4rd-addmapping]
Despres, R., Qin, J., Perreault, S., and X. Deng,
"Stateless Address Mapping for IPv4 Residual Deployment
(4rd)", draft-despres-softwire-4rd-addmapping-00 (work in
progress), August 2011.
[I-D.murakami-softwire-4rd]
Murakami, T. and O. Troan, "IPv4 Residual Deployment on
IPv6 infrastructure - protocol specification",
draft-murakami-softwire-4rd-00 (work in progress),
July 2011.
[I-D.murakami-softwire-4v6-translation]
Murakami, T., Chen, G., Deng, H., Dec, W., and S.
Matsushima, "4via6 Stateless Translation",
draft-murakami-softwire-4v6-translation-00 (work in
progress), July 2011.
[I-D.operators-softwire-stateless-4v6-motivation]
Boucadair, M., Matsushima, S., Lee, Y., Bonness, O.,
Borges, I., and G. Chen, "Motivations for Stateless IPv4
over IPv6 Migration Solutions",
draft-operators-softwire-stateless-4v6-motivation-02 (work
in progress), June 2011.
[I-D.xli-behave-divi]
Bao, C., Li, X., Zhai, Y., and W. Shang, "dIVI: Dual-
Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-03
(work in progress), July 2011.
[I-D.xli-behave-divi-pd]
Li, X., Bao, C., Dec, W., and R. Asati, "dIVI-pd: Dual-
Stateless IPv4/IPv6 Translation with Prefix Delegation",
draft-xli-behave-divi-pd-00 (work in progress), July 2011.
Boucadair, et al. Expires March 8, 2012 [Page 24]
Internet-Draft Port Set Analysis September 2011
Authors' Addresses
Mohamed Boucadair
France Telecom
Email: mohamed.boucadair@orange-ftgroup.com
Nejc Skoberne
Viris
Smartinska cesta 130
Ljubljana 1000
SI
Phone: +386 31 883 217
Email: nejc@viris.si
Wojciech Dec
Cisco
Phone:
Email: wdec@cisco.com
Boucadair, et al. Expires March 8, 2012 [Page 25]