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---> <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 127| +--------------+-----+---+--------+---------------------------------+ | DomPref | 4RD | P | suffix | 0 | +--------------+-----+---+--------+---------------------------------+ <------n----->

<-----------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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <-----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 127| +-------------+-----+---+-----+---+--------------------+------------+ | DomPref | 4RD | P | suf | z | IID | addr | +-------------+-----+---+-----+---+--------------------+------------+ <-----n----->

<-----------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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <-----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, . [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]