<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC1332 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1332.xml">
<!ENTITY RFC5382 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5382.xml">
<!ENTITY RFC6056 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6056.xml">
<!ENTITY RFC6333 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6333.xml">
<!ENTITY RFC6431 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6431.xml">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-tsou-softwire-port-set-algorithms-analysis-04" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
        or pre5378Trust200902
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the full title is longer than 39 characters -->

    <title abbrev="Port Set Algorithm Analysis">Analysis of Algorithms For Deriving Port Sets</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Tina Tsou" initials="T." role="editor"
            surname="Tsou">
      <organization>Huawei Technologies (USA)</organization>
      <address>
        <postal>
          <street>2330 Central Expressway</street>
          <city>Santa Clara</city>
          <code>CA  95050</code>
          <country>USA</country>
        </postal>
        <phone>+1 408 330 4424</phone>
        <email>tina.tsou.zouting@huawei.com</email>
      </address>
    </author>

    <author fullname="Tetsuya Murakami" initials="T." surname="Murakami">
      <organization>IP Infusion</organization>
      <address>
        <postal>
          <street>1188 East Arques Avenue</street>
          <city>Sunnyvale</city>
          <country>USA</country>
        </postal>
        <email>tetsuya.murakami@ipinfusion.com</email>
      </address>
    </author>


    <author fullname="Simon Perreault" initials="S." surname="Perreault">
      <organization>Viagenie</organization>
      <address>
        <postal>
          <street>246 Aberdeen</street>
          <city>Quebec</city>
          <region>QC</region>
          <code>G1R 2E1</code>
          <country>Canada</country>
        </postal>
        <phone>+1 418 656 9254</phone>
        <email>simon.perreault@viagenie.ca</email>
        <uri>http://viagenie.ca</uri>
      </address>
    </author>

    <date year="2013" />


    <!-- Meta-data Declarations -->

    <area>INT</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
     If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->
    

    <abstract>
      <t>This memo analyzes some port set definition algorithms used for
      stateless IPv4 to IPv6 transition technologies. The transition
      technologies using port set algorithms can be divided into two categories:
      fully stateless approach and binding approach. Some algorithms can work
      for both approaches.</t> 
    </abstract>
  </front>

  <middle>
    <section anchor="Intro" title="Introduction">
      <t>IPv6 transition technologies with address sharing can be divided into three 
      categories as suggested in <xref target="I-D.softwire-unified-cpe"></xref>: 
        <list style="symbols">
          <t>Fully stateful approach, e.g. <xref target="RFC6333"></xref>.
          Stateful solutions do not make use of port sets, and are out of 
          scope for this memo.</t> 
          
          <t>Binding approach, with per-subscriber state, e.g., 
          <xref target="I-D.softwire-lw4over6"></xref>. This type of
          algorithm does not embed port set information and IPv4 address in the
          IPv6 address when doing translation or encapsulation, so a mapping
          entry is required in the border router. This type of solution gives
          flexibility in address planning because the IPv4 address is not
          statically bound to the IPv6 address. To some extent, the binding
          approach can also be called a partially stateless approach.</t> 
          
          <t>Fully stateless approach, e.g., 
          <xref target="I-D.softwire-map"></xref>. This type of
          algorithm embeds port set information and an IPv4 address in the IPv6
          address. For a given port number and IPv4 address, the corresponding
          IPv6 address can be calculated using a limited set of mapping rules
          rather than a mapping entry per subscriber.</t> 
        </list>
      </t>

      <t>Binding and stateless technologies can significantly simplify the
      implementation of the border router and reduce resource requirements. In
      these solutions, a port set is assigned to each CPE, and can be calculated
      from a port set identifier (PSID) in conjunction with some other
      parameters. For a given port number, the corresponding PSID can also be
      derived; that is, the mapping algorithm must be reversible. </t> 

      <t>Some port set definition algorithms have been proposed to support these
      technologies. It may be useful to analyze the characteristics of these
      algorithms for better understanding and to choose a proper algorithm for
      different needs.</t> 

      <t>A good port set definition algorithm must be reversible and easy to
      implement. It must be able to exclude the well-known ports (0-1023). It
      should be able to define non-continuous or random port sets for the modest
      gain in security against port-guessing attacks that these provide. For the
      fully stateless method, the restrictions imposed by the algorithm on the
      choice of IPv6 addresses for customer equipment should be minimized. To
      simplify administration, the total number of ports assigned should be
      roughly the same for each port set derived by the algorithm. Finally, the
      algorithm should be adaptable to a wide range of address sharing
      ratios.</t> 

      <t>This memo will analyze the following characteristics:
      <list style="symbols">
        <t>Implementation: implementation complexity, performance, etc.</t>
        <t>Can calculate the port set identifier (PSID) from the port number 
        at the Border Router (BR).</t>
        <t>Can exclude well known ports without excluding other ports.</t>
        <t>Port set type: continuous, non-continuous, random. Continuous port
        set provides common security, random port set provides good
        security.</t> 
        <t>Stateless: requires per-subscriber provisioning at the BR, yes or no.</t>
        <t>Friendliness for NAT44: comply with NAT44 <xref target="RFC5382"/>
        or not.</t>
        <t>Sharing ratio: maximum, minimum sharing ratio.</t>
      </list>
      </t>

    </section>

    <section title="Terminology">
      <t><list hangIndent="10" style="hanging">
        <t hangText="BR:">Border Router.</t>
        <t hangText="CPE:">Customer Premise Equipment.</t>      
        <t hangText="GMA:">Generalized Modulus Algorithm.</t>
        <t hangText="MAP:">Map Address and Port.</t>
        <t hangText="PSID:">Port Set Identifier, one of the key parameters
        used to derive the set of ports allocated to a given CPE.</t>
      </list></t>
    </section>

    <section anchor="algorithms" title="Various Types of Algorithms">
    
      <section anchor="bind" title="Binding Approach Algorithms">
      
        <section anchor="mskVal" title="Mask/Value Algorithm">
          
          <t><xref target="RFC6431"/> defines an option for the PPP
          Internet Protocol Control Protocol (IPCP) <xref target="RFC1332"/>
          to allocate port sets to CPEs, as shown in 
          <xref target="fig_IPCPopt"/>. The Port Range Value plays the
          role of a PSID. The example in <xref target="RFC6431"/> shows
          the case of a mask selecting a port number prefix, but the mask
          can be more general.</t> 
          
          <figure anchor="fig_IPCPopt" 
              title="IPCP Option Format For Port Set Identifier (PSID)"
              align="center">
            <artwork>
 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          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            </artwork>
          </figure>
  
          <t><xref target="I-D.softwire-lw4over6"></xref> also uses this type
          of port set definition algorithm, for which provisioning is defined
          in <xref target="I-D.sun-dhc-port-set-option"></xref>.
          <xref target="fig_DHCpsopt"/> illustrates the DHCP option.</t> 
          
          <figure anchor="fig_DHCpsopt" 
                title="DHCP Port Set Option Format"
                align="center">
            <artwork>
 0                             1
 0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|   OPTION_PORT_SET     |     option-length     |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                Port Set Index                 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                Port Set Mask                  |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
            </artwork>
          </figure>
  
          <t>The bit-wise AND of port set index and mask can be encoded in
          an IPv6 address, which will turn it into a fully stateless solution,
          similar to parameter PSID in other technologies, e.g., <xref
          target="I-D.softwire-map">MAP</xref>.</t> 
  
          <t>The Port Range Value corresponding to a given port can be derived
          by performing the bit-wise AND of the port number with the Port Range
          Mask.</t> 
                                                                                         
          <figure anchor="fig_examp" 
              title="Example of Port Range Mask and Port Range Value"
              align="center">
            <artwork>
 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)
            </artwork>
          </figure>
  
          <t>This algorithm can have some kind of randomization effect by
          setting different numbers of bits and bits at different locations in
          the Port Range Mask.</t> 
  
          <t>This algorithm may have a problem if the well known ports 
          (0-1023) need to be excluded; it is a bit difficult to achieve that.
          But if the operator does not have a specific usage for the well
          known ports, then it is safe to allocate those port to end users, just
          like other common ports. Some tests have been done to confirm this.</t> 
          
          <texttable anchor="tab_rngMask" title="Evaluation of Mask/Value Algorithm">
            <ttcol align="left">Criterion</ttcol>
            <ttcol align="left">Result</ttcol>
            
            <c>Implementation</c>
            <c>Easy</c>
            
            <c>PSID from port number</c>
            <c>Yes</c>
            
            <c>Port exclusion</c>
            <c>Difficult</c>
            
            <c>Port set type</c>
            <c>Continuous with prefix, non-continuous otherwise</c>
            
            <c>Stateless</c>
            <c>Requires BR to know mask, could be subscriber-independent.</c>
            
            <c>NAT compliance</c>
            <c>Care must be taken to avoid port overloading if mask varies
            between subscribers.</c>
            
            <c>Sharing ratio</c>
            <c>Can vary from 1 to 65536 subscribers per address.</c>
            
          </texttable>
            
        </section>  <!-- mskVal -->
  
        <section anchor="crypto" title="Cryptographic Algorithm">
        
          <t>The cryptographic port set definition algorithm introduced in <xref
          target="RFC6431"></xref> can provide very good protection against port
          guessing attacks, but it is very difficult to derive the port set
          information, e.g., the starting point, from a given port number. This
          algorithm can only be used in binding scenarios; the BR must operate
          in per-subscriber state mode.</t> 
  
          <figure anchor="fig_crypto" 
                  title="Format of the Cryptographically Random Port Range Option"
                  align="center">
            <artwork>
 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                           ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...                                                           ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...                                                           ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...                                                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            </artwork>
          </figure>
  
          <texttable anchor="tab_crypto" title="Evaluation of Cryptographic Algorithm">
            <ttcol align="left">Criterion</ttcol>
            <ttcol align="left">Result</ttcol>
            
            <c>Implementation</c>
            <c>Difficult</c>
            
            <c>PSID from port number</c>
            <c>No (note)</c>
            
            <c>Port exclusion</c>
            <c>Difficult</c>
            
            <c>Port set type</c>
            <c>Continuous or non-continuous</c>
            
            <c>Stateless</c>
            <c>Binding mode only.</c>
            
            <c>NAT compliance</c>
            <c>Care must be taken to avoid port overloading.</c>
            
            <c>Sharing ratio</c>
            <c>Can vary from 1 to 65536 subscribers per address.</c>
            
          </texttable>
  
          <t>Note: it may be possible to find a cryptographic algorithm which
          can be reversed, e.g. define a reversible one-to-one mapping
          algorithm. But that is out the scope of this memo. If strong
          security is required, it may be worth giving this topic further
          study.</t>
          
        </section>  <!-- crypto -->
      
      </section>  <!-- bind -->

      <section anchor="gma" title="Fully Stateless: the Generalized Modulus Algorithm (GMA)">

        <t>Currently there are three drafts supporting the GMA style 
        algorithm: <xref target="I-D.softwire-map">MAP-E</xref>, 
        <xref target="I-D.softwire-4rd">4rd-U</xref>, and
        <xref target="I-D.softwire-map-t">MAP-T</xref>, but they are not 
        exactly all the same. </t>

        <section anchor="map-e" title="MAP-E">
        
          <t>In <xref target="I-D.softwire-map">MAP</xref>, a port set can be
          defined by the following parameters: 
            <list>
              <t>R: sharing ratio;</t>
              <t>P: PSID;</t>
              <t>M: maximum number of contiguous ports.</t>
            </list>
          </t>
          
          <t>To derive the set of port numbers in the port set corresponding to
          a given PSID value, the following equation can be used:
          <list style="empty">
              <t>Port = (R * M) * i + M * PSID + j </t>
          </list>
          where i and j are indices which vary within limits to provide the 
          different port numbers belonging to the port set. The range of i 
          depends on the value (R * M) and the range of j is from 0 to (M - 1).
          </t>
          
          <t>If (R * M) is less than or equal to 2^15, ports (e.g, the well-
          known ports 0-1023) can be excluded from the lower end by putting a
          lower limit dependent on the value (R * M) on index i. In this case,
          each port set defined by the algorithm consists of a series of ranges
          of M consecutive port numbers at intervals of (R * M).</t> 
          
          <t>On the other hand, if (R * M) is greater than 2^15, the first term
          drops out of the above equation and a lower limit dependent on the
          value of M has to be imposed on the value of PSID to exclude the well-
          known ports. In this case, each PSID is associated with a single range
          of M consecutive port numbers.</t>
          
          <t>The GMA is easily reversible. For a given port number, the
          corresponding PSID is given by:
          <list style="empty">
            <t>PSID = floor( (Port modulo (R * M)) / M))</t>
          </list>
          If R and M are powers of 2, this becomes a mask operation. The mask
          consists of 'a' high-order zeroes, followed by 'k' ones, followed by 'm'
          low-order zeroes, where:
          <list style="empty">
            <t>2^a = 65536/(R * M);</t>
            <t>2^m = M;</t>
            <t>k = 16 - a - m.</t>
          </list>
          See <xref target="fig_portBits"/>.</t>
          
          <t>MAP-E defaults to a value of 'a' equal to 6. Thus by constraining
          the index i to be >= 1, exactly the well-known port range is
          excluded. Also, each port set consists of 63 equally-sized ranges of
          consecutive values spaced 1024 ports apart.</t> 

          <figure anchor="fig_portBits" 
              title="GMA Bit Representation Of a Port Number When R and M Are Powers Of 2"
              align="center">
            <artwork>
 0                          8                       15
+---------------+----------+------+-------------------+
|       i       |      PSID       |         j         |
+---------------+----------+------+-------------------+
|&lt;----a bits--->|&lt;-----k bits---->|&lt;------m bits----->|
            </artwork>
          </figure>
          
          <t>For a complete explanation of the GMA, see Appendix B of 
          <xref target="I-D.softwire-map"/>.</t>

          <t>MAP-E embeds the PSID in the End User IPv6 Address provisioned on
          the customer edge device. See <xref target="fig_v6Deriv"/>. The PSID's
          location within the address is determined from the Basic Mapping Rule
          applicable to the subscriber. A mask to extract the PSID from that
          address is described as follows: 
          <list style="symbols">
            <t>High-order zeroes in the amount of (n + 32 - r) bits, where n is
            the length of the IPv6 prefix in the Basic Mapping Rule and r is the
            length of the IPv4 prefix in that rule. </t>
            
            <t>Ones in the amount of (r + o - 32) bits, where o is the number
            of EA bits given by the rule.</t>
            
            <t>Zeroes for the remaining low-order portion of the address.</t>
          </list>
          This operation is valid only if (r + o) is greater than 32. If not,
          the IPv4 address or prefix assigned to the subscriber is unshared
          and the customer edge device can use every port.</t> 

          <figure anchor="fig_v6Deriv" 
                  title="Structure of the MAP-E End User IPv6 Address"
                  align="center">
            <artwork>
|        32 bits           |         |    16 bits        |
+--------------------------+         +-------------------+
|  IPv4 endpoint address   |         |  Port in port set |
+--------------------------+         +-------------------+
:               :          :           ___/       :
|    r bits     |32-r bits |          /  q bits   :  q = o - (32-r)
+---------------+----------+         +------------+
|  IPv4 prefix  |IPv4  sufx|         |Port Set ID |
+---------------+----------+         +------------+
                \          /    ____/    ________/
                  \       :  __/   _____/
                    \     : /     /
|     n bits         |  o bits   | s bits  |   128-n-o-s bits      |
+--------------------+-----------+---------+------------+----------+
|  Rule IPv6 prefix  |  EA bits  |subnet ID|     interface ID      |
+--------------------+-----------+---------+-----------------------+
|&lt;---  End-user IPv6 prefix  --->|
            </artwork>
          </figure>
          
        </section>  <!-- map-e -->

        <section title="4rd-U">
            
         <t>Everything that was described in the previous section for MAP-E also
         applies to <xref target="I-D.softwire-4rd">4rd-U</xref>, with two
         differences. First, the mapping rule applicable to a particular customer
         site includes an indication of whether the customer edge equipment is
         permitted to use the well-known ports or whether they must be excluded. </t> 
         
         <t>If the well-known ports are to be excluded, the default value of 'a'
         (recall <xref target="fig_portBits"/>) is 4 rather than 6. That means
         that the port set consists of 15 rather than 63 ranges, spaced 4096
         values apart. It also means that ports 0-4095 rather than ports 0-1023
         are excluded. At an earlier point in time MAP-E had the same default,
         for which the 4rd-U document provides arguments. However, it was
         decided that the waste of ports entailed (which implies a 6% reduction
         in the number of subscribers sharing the same IPv4 address) was a
         sufficient reason to change. However, see <xref target="concl"/> for
         new evidence on this point.</t>
         
         <t>If the well-known ports can be used, the default value of 'a' is
         zero. That is, the PSID is positioned at the beginning of the port
         number. As mentioned in the previous section, this implies that
         subscribers assigned this mapping rule are assigned a single range of
         consecutive ports. The subscribers assigned the lowest PSID values
         receive port sets consisting partly or completely of well-known port
         number values.</t> 
         
       </section>  <!-- 4rd-U -->

       <section anchor="map-t" title="MAP-T">

         <t><xref target="I-D.softwire-map-t">MAP-T</xref> uses the same
         algorithm to assign port sets to customer sites, this time with just
         one difference. The default value of the offset 'a' is always 4. The
         consequences in terms of wasted ports were spelled out in the previous
         section.</t> 

       </section>  <!-- map-t -->
       
       <section anchor="gmaeval" title="Evaluation">
       
         <t>This section provides an evaluation of the GMA against our 
         comparison criteria.</t>
         
                   <texttable anchor="tab_gma" title="Evaluation of Cryptographic Algorithm">
            <ttcol align="left">Criterion</ttcol>
            <ttcol align="left">Result</ttcol>
            
            <c>Implementation</c>
            <c>Easy</c>
            
            <c>PSID from port number</c>
            <c>Yes</c>
            
            <c>Port exclusion</c>
            <c>Easy, but using a value of the offset 'a' between 1 and 5 wastes
            ports and hence reduces the maximum practical sharing ratio.</c>
            
            <c>Port set type</c>
            <c>Continuous for 'a' = 0, non-continuous otherwise</c>
            
            <c>Stateless</c>
            <c>No subscriber-specific data required.</c>
            
            <c>NAT compliance</c>
            <c>Port sets are guaranteed to be non-overlapping.</c>
            
            <c>Sharing ratio</c>
            <c>Equal to 65536/(M * 2^a), where M is the range size for all 
            subscribers sharing the same address. See note. </c>
            
          </texttable>
          
          <t>Note: a practical value of the total number of ports in the port
          set is in the order of 400. Suppose one wants to guarantee each
          subscriber at least this number of ports. Recall that the number of
          equal ranges into which the port allocation is divided is equal to 1
          for a = 0, 15 for a = 4, and 63 for a = 6. Because of the assumption
          of equal range sizes, the number of ports M in each range has to be
          rounded up in the general case to give a total number of ports at
          least equal to 400. <xref target="tab_sharexamp"/> shows the consequent
          impact on sharing ratio. The rounding effect very much dominates the
          results. If the target were 305 ports instead, the sharing ratio would
          be the same for all three values of a, since 305 is a multiple of 15
          and 63.</t>
          
          <texttable anchor="tab_sharexamp" title="Port Allocations and Range Size For Different Values Of Offset a">
            <ttcol align="right">a</ttcol>
            <ttcol align="right">2^a</ttcol>
            <ttcol align="right"># Ranges</ttcol>
            <ttcol align="right">Range Size M</ttcol>
            <ttcol align="right">Tot. Ports</ttcol>
            <ttcol align="right">Ratio R</ttcol>
            
            <c>0</c>
            <c>1</c>
            <c>1</c>
            <c>400</c>
            <c>400</c>
            <c>163</c>
            
            <c>4</c>
            <c>16</c>
            <c>15</c>
            <c>27</c>
            <c>405</c>
            <c>151</c>
            
            <c>6</c>
            <c>64</c>
            <c>63</c>
            <c>7</c>
            <c>441</c>
            <c>146</c>
          </texttable>
          
          <t>In <xref target="tab_sharexamp"/>, the value M is rounded up from
          the ratio 400/N, where N is the number of separate ranges in the port
          set. The total number of ports in the port set is this result
          multiplied by the number of ranges. The sharing ratio is then the
          stated 65536/(M * 2^a), rounded down to ensure every subscriber
          sharing the address gets the same number of ports. For a = 0, this
          ratio would be reduced by 3 to exclude the three ranges containing
          well-known ports.</t> 
          
        </section>  <!-- gmaeval -->

      </section>  <!-- gma -->
        
    </section>  <!-- algorithms -->


    <section anchor="concl" title="Conclusion">
      
      <t>The Generalized Modulus Algorithm (GMA) clearly comes the closest to
      satisfying all of our criteria. As the example calculation in <xref
      target="tab_sharexamp"/> shows, the sharing ratio is sensitive to the
      rounding necessary to guarantee at least a certain total number of ports
      to each subscriber. In this regard, sensitivity will be higher for
      larger values of the offset parameter 'a', leading to the surprising
      result that for some ranges of values of the target total number of
      ports, the sharing ratio will be less for a = 6 than for a = 4 even
      though the latter wastefully excludes an extra 3072 ports. </t>
      
      <t>The sensitivity of this result to the target total number of ports
      per subscriber is shown if one assumes that that number is 441 ports.
      Then the sharing ratio for a = 6 remains at 146, but that for a = 4
      drops to 136.</t> 
      
      <t>The mask/value algorithm is really a generalization of the GMA. One has 
      the GMA if the one-bits of the mask are constrained to be consecutive. The 
      difference between the binding and fully stateless approaches lies not in 
      the algorithm itself, but in how the algorithm parameters are conveyed to 
      the border router. Binding uses per-subscriber rules. The fully stateless 
      approaches reviewed in this document use a combination of shared mapping 
      rules and information embedded in specially-constructed addresses.</t>

    </section>  <!-- concl -->

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The major security consideration related to the subject matter of this
      document is the vulnerability of port allocation to a port guessing
      attack. See <xref target="RFC6056"/> for details. The most important
      factor in countering such an attack is to allocate ports randomly from the
      assigned port set as they are required by different applications. However,
      allocating port sets as non-continuous or random entities requires the
      attacker to go to some extra effort in order to determine the complete
      port set allocated to a subscriber. Thus resistance to port guessing
      attacks is improved to a certain degree by allocating non-continuous port
      sets. For the GMA, this means that non-zero values of the offset value 'a'
      are to be preferred. </t> 
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Normative References">
      &RFC5382;
      &RFC6056;
      &RFC6431;
    </references>


    <references title="Informative References">
      &RFC1332;
      &RFC6333;

      <reference anchor="I-D.softwire-4rd">
        <front>
          <title>IPv4 Residual Deployment Via IPv6 - A Unified Stateless 
            Solution (4rd) (Work in progress)</title>

          <author initials="S." surname="Jiang" fullname="Sheng Jiang">
            <organization>Huawei Technologies Co., Ltd</organization>
          </author>

          <author initials="R." surname="Despres" fullname="Remi Despres">
            <organization>RD-IPtech</organization>
          </author>

          <author initials="R." surname="Penno" fullname="Reinaldo Penno">
            <organization>Cisco Systems, Inc.</organization>
          </author>

          <author initials="Y." surname="Lee" fullname="Yiu Lee">
            <organization>Comcast</organization>
          </author>

          <author initials="G." surname="Chen" fullname="Gang Chen">
            <organization>China Mobile</organization>
          </author>

          <author initials="M." surname="Chen" fullname="Maoke Chen">
            <organization>Freebit Co, Ltd.</organization>
          </author>

          <date month="April" year="2013" />
        </front>
      </reference>

      <reference anchor="I-D.softwire-map">
        <front>
          <title>Mapping of Address and Port (MAP) (Work in progress)</title>
          <author initials="O." surname="Troan" fullname="Ole Troan">
            <organization>Cisco Systems</organization>
          </author>

          <author initials="W." surname="Dec" fullname="Wojciech Dec">
            <organization>Cisco Systems</organization>
          </author>

          <author initials="X." surname="Li" fullname="Xing Li">
            <organization>CERNET Center/Tsinghua University</organization>
          </author>

          <author initials="C." surname="Bao" fullname="Congxiao Bao">
            <organization>CERNET Center/Tsinghua University</organization>
          </author>

          <author initials="S." surname="Matsushima" fullname="Satoru Matsushima">
            <organization>SoftBank Telecom</organization>
          </author>

          <author initials="T." surname="Murakami" fullname="Tetsuya Murakami">
            <organization>IP Infusion</organization>
          </author>
          
          <author initials="T." surname="Taylor" fullname="Tom Taylor">
            <organization>Huawei Technologies</organization>
          </author>

          <date month="May" year="2013" />
        </front>
      </reference>
      
  <reference anchor="I-D.softwire-map-t">
    <front>
      <title>Mapping of Address and Port using Translation (MAP-T)</title>
      <author initials="X." surname="Li">
        <organization>CERNET Center/Tsinghua University</organization>
      </author>
      <author initials="C." surname="Bao">
        <organization>CERNET Center/Tsinghua University</organization>
      </author>
      <author initials="W." surname="Dec">
        <organization>Cisco Systems</organization>
      </author>
      <author initials="O." surname="Troan">
        <organization>Cisco Systems</organization>
      </author>
      <author initials="S." surname="Matsushima">
        <organization>SoftBank Telecom</organization>
      </author>
      <author initials="T." surname="Murakami">
        <organization>IP Infusion</organization>
      </author>
      <date month="February" year="2013"/>
    </front>
  </reference>

      <reference anchor="I-D.sun-dhc-port-set-option">
        <front>
          <title>Dynamic Host Configuration Protocol (DHCP) Option for Port Set 
          Assignment (Work in progress)</title>
  
          <author initials="Q." surname="Sun" fullname="Qi Sun">
            <organization>Tsinghua University</organization>
          </author>

          <author initials="Y." surname="Li" fullname="Yiu Lee">
            <organization>Comcast</organization>
          </author>

          <author initials="Q." surname="Sun" fullname="Qiong Sun">
            <organization>China Telecom</organization>
          </author>

          <author initials="G." surname="Bajko" fullname="Gabor Bajko">
            <organization>Nokia</organization>
          </author>

          <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair">
            <organization>France Telecom</organization>
          </author>

          <date month="April" year="2013" />
        </front>
      </reference>

      <reference anchor="I-D.softwire-lw4over6">
        <front>
          <title>Lightweight 4over6: An Extension to the DS-Lite Architecture (Work in progress)</title>
          <author initials="Y." surname="Cui" fullname="Yong Cui">
            <organization>Tsinghua University</organization>
          </author>

          <author initials="Q." surname="Sun" fullname="Qiong Sun">
            <organization>China Telecom</organization>
          </author>

          <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair">
            <organization>France Telecom</organization>
          </author>

          <author initials="T." surname="Tsou" fullname="Tina Tsou">
            <organization>Huawei Technologies</organization>
          </author>

          <author initials="Y." surname="Li" fullname="Yiu L. Lee">
            <organization>Comcast</organization>
          </author>

          <author initials="I." surname="Farrer" fullname="Ian Farrer">
            <organization>Deutsche Telekom AG</organization>
          </author>

          <date month="April" year="2013" />
        </front>
      </reference>

      <reference anchor="I-D.softwire-unified-cpe">
        <front>
          <title>Unified IPv4-in-IPv6 Softwire CPE (Work in progress)</title>
          <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair">
            <organization>France Telecom</organization>
          </author>

          <author initials="I." surname="Farrer" fullname="Ian Farrer">
            <organization>Deutsche Telekom</organization>
          </author>

          <date month="March" year="2013" />
        </front>
      </reference>

      <reference anchor="I-D.bsd-softwire-stateless-port-index-analysis">
        <front>
          <title>Analysis of Port Indexing Algorithms</title>
          <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair">
            <organization>France Telecom</organization>
          </author>

          <author initials="N." surname="Skoberne" fullname="Nejc Skoberne">
            <organization>Viris</organization>
          </author>

          <author initials="W." surname="Dec" fullname="Wojciech Dec">
            <organization>Cisco Systems</organization>
          </author>
    
          <date month="September" year="2011" />
        </front>
      </reference>

    </references>

  </back>
</rfc>
