Internet Engineering Task Force                                   X.Deng
Internet Draft                                               M.Boucadair
Intended status: Informational                            France Telecom
Expires: March 28, 2012                                            Y.Lee
                                                                 Comcast
                                                                 T.Zheng
                                                                  L.Wang
                                                          France Telecom
                                                                 X.Huang
                                                                  Q.Zhao
                                                                    Y.Ma
                                                                    BUPT
                                                      September 25, 2011



           Implementing A+P in the provider's IPv6-only network
            draft-deng-softwire-aplusp-experiment-results-00.txt


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 28, 2012.




Deng, et al.           Expires January 1, 2012                [Page 1]


Internet-Draft           A+P implementation             September 2011


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
   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.

Abstract

  This memo describes an implementation of A+P in a provider's IPv6-
  only network. It provides details of the implementation, network
  elements, configurations and test results as well. Besides
  traditional port range A+P, a scattered port sets flavor of A+P is
  also implemented to verify feasibility of offering non-continuous
  port sets with A+P approach, and to investigate possibility and efforts
  of making UPnP 1.0 work with A+P.

  The test results consist of the application compatibility test, UPnP
  1.0 extensions and UPnP 1.0 friendly port allocation for A+P, port
  usage and BitTorrent behaviors with A+P.

  This memo focuses on the IPv6 flavor of A+P.

Table of Contents


  1. Introduction.................................................3
  2. Terminology..................................................4
  3. Implementation environment...................................4
     3.1. Environment Overview....................................4
     3.2. Implementation and Configuration of A+P.................5
        3.2.1. IPv4-Embedded IPv6 Address Format For A+P CPE......6
        3.2.2. DHCPv6 Configurations..............................6
        3.2.3. Avoiding Fragmentation.............................6
     3.3. Implementing scattered Port Sets for A+P................7
        3.3.1. Scattered Port Sets allocation mechanism...........7
        3.3.2. IPv4-Embedded IPv6 Address Format for Scattered Port
        Sets A+P CPE.............................................10
        3.3.3. Customize a scattered Ports Set A+P NAT on Linux..11
  4. Application Tests and Experiments in A+P Environment........12
     4.1. A+P Impacts on Applications............................12
     4.2. UPnP extension experiment..............................13



Deng, et al.           Expires January 1, 2012                [Page 2]


Internet-Draft           A+P implementation             September 2011


        4.2.1. UPnP 1.0 extenstion...............................13
        4.2.2. Evaluation of scattered port allocation taking UPnP
               1.0 friendliness into account.....................15
     4.3. Port Usage of Applications.............................17
     4.4. BitTorrent Behaviour in A+P............................19
  5. Security Considerations.....................................19
  6. IANA Considerations.........................................20
  7. Conclusion..................................................20
  8. References..................................................20
     8.1. Normative References...................................20
     8.2. Informative References.................................20
  9. Acknowledgments.............................................21

1. Introduction

  A+P [RFC6346] is a technique to share IPv4 addresses during the IPv6
  transition period without requiring a NAT function in the provider's
  network. The main idea of A+P is treating some bits from the port
  number in the TCP/UDP header as additional end point identifiers to
  extend the address field, thereby leaving a range of ports available
  to applications. This feature facilitates migration of networks to
  IPv6-only while offering the IPv4 connectivity services to customers,
  because the IPv4 address and the significant bits from the port range
  can be encoded in an IPv6 address and therefore transporting IPv4
  traffic over IPv6 network by stateless IPv6 routing.

  We have implemented A+P in a residential ADSL access network, where
  IPv6-only access network is provided over PPPoE. In this document, we
  describe the implementation environment including A+P IPv6 prefix
  format and network elements configurations, and results of
  application tests as well. The document focuses on the implementation
  of the SMAP function specified in [RFC6346]:

  o Implement DHCPv6 options to retrieve an IPv4-embedded IPv6 address
     and a port range.

  o Support of those DHCPv6 options in both the DHCPv6 server side and
     the DHCPv6 client side.

  o Support of those DHCPv6 options in both the DHCPv6 server side and
     the DHCPv6 client side.

  For extensive application tests results in A+P environment, please
  refer to [draft-boucadair-behave-bittorrent-portrange-02] and [draft-
  boucadair-port-range-01].





Deng, et al.           Expires January 1, 2012                [Page 3]


Internet-Draft           A+P implementation             September 2011


2. Terminology

  This document makes use of the following terms:

  o PRR: Port Range Router

  o A+P CPE: A+P aware Customer Premise Equipment



3. Implementation environment

3.1. Environment Overview

                           public
                           addresses        +----------+
                           realm            |  PRR     |
                                            |          |
                            ===             +----------+
                        IPv4 ^                  ^ ^
                             |                  | |
                             |                  v v
                             |            +--------------+
                             |            | PPPoE/DHCPv6 |
                        over |            |    Server    |
                             |            +--------------+
                             |       ===        ^ ^
                             |  IPv6  ^         | |
                             |  over  |         | |
                        IPv6 |  PPPoE |         | |
                             V        v         | |
                            ===      ===        v v
                                      ^     +----------+
                                      |     |  A+P     |
                                      |     |  CPE     |
                                      |     +----------+
                              Private |         ^ ^
                              RFC1918 |         | |
                              realm   |         v v
                                      |     +----------+
                                      |     |   Host   |
                                      |     |          |
                                      V     +----------+


                  Figure 1 : Implementation Environment




Deng, et al.           Expires January 1, 2012                [Page 4]


Internet-Draft           A+P implementation             September 2011


  We had developed both A+P home gate way function and Port Range
  Router (PRR) function on Linux platform and ported the home gate way
  function to a Linksys wrt 54G CPE, on which an openwrt 2.6.32 (based
  on Linux kernel) is running.

  Figure 2 shows the Parameters of A+P CPE. IPv6 is provisioning over
  PPPoE to CPE while DHCPv6 server offers IPv6 prefix and A+P
  parameters by extended options defined in [draft-boucadair-dhcpv6-
  shared-address-option].



  +--------+------------+-------+-----+------------+-----------+------+
  | Model  | CPU Speed  | Flash | RAM |  Wireless  | Wireless  | Wired|
  |        |      (MHz) |  (MB) | (MB)|    NIC     | Standard  | Ports|
  +--------+---------- -+-------+-----+------------+-----------+------+
  | Linksys|    200     |   8   |  32 | Broadcom   |    11g    |   5  |
  | WRT54GS|            |       |     |(integrated)|           |      |
  +--------+------------+-------+-----+------------+-----------+------+


                     Figure 2 :Parameters of A+P CPE

3.2. Implementation and Configuration of A+P

  A+P CPE, using Netfilter framework, the IPv4 port restricted NAT
  operation performed by CPE has been implemented by simply rules
  through iptables tool on Linux. After the port restriceted NAT
  operation, the IPv4 packets are sent to a TUN interface which is
  described as a virtual network interface in Linux. Using the IPv4-
  Embedded IPv6 address format defined in section 3.2.1, an IPv4-in-
  IPv6 encapsulation/decapsulation is performed by the TUN interface
  handler.

  PRR, located in the interconnection point of the IPv6 network and
  IPv4 network, has been implemented with two main functions: 1) IPv4-
  in-IPv6 encapsulation/decapsulation; Like CPE, TUN driver is also
  used in PRR to achieve function IPv4-in-IPv6
  encapsulation/decapsulation. 2) Destination port based routing
  function, which is responsible for routing the IPv4 traffic
  originated from the IPv4 Internet to the Port Range restricted A+P
  CPE. Destination port based routing is implemented by generating IPv6
  destination address, pre-assigned from IPv4 address and port range to
  each CPE, according to IPv4-Embedded IPv6 address format defined in
  Section 3.2.1.





Deng, et al.           Expires January 1, 2012                [Page 5]


Internet-Draft           A+P implementation             September 2011


  3.2.1. IPv4-Embedded IPv6 Address Format For A+P CPE



  |31bits|1bit| 32bits|8 bits|16bits|4bits|1bit|1bit|1bit|1bit|32 bits|
  +------+----+-------+------+------+-----+----+----+----+----+-------+
  |A+P   |flag|Public | EUI64| port |Port |flag|flag|flag|flag|Public |
  |Prefix| 0  |IPv4   |      | Range|Range|  1 |  2 |  3 |  4 |IPv4   |
  |      |    |Address|      |      |Size |    |    |    |    |Address|
  +------+----+-------+------+------+-----+----+----+----+----+-------+


               Figure 3 :IPv4-Embedded IPv6 address format

  flag0: Is this address used by CPE or PRR?

  flag1: Is address shared?

  flag2: Is length of invariable present?

  flag3: Is port range identifying sub network?

  flag4: Reserved?



  To facilitate test and experiment on A+P solution, recently, we are
  considering release this A+P implementation under open source
  license. For more implementation details, please refer to
  [Implementing A+P]

  3.2.2. DHCPv6 Configurations



  DHCPv6 options defined in [draft-boucadair-dhcpv6-shared-address-
  option] have been implemented. These options allow to configure a
  shared address together with a port range using DHCPv6.

  3.2.3. Avoiding Fragmentation



  Normally the TCP protocol stack will employ Maximum Segment Size
  (MSS) negotiation and/or Path Maximum Transmission Unit Discovery
  (PMTUD) to determine




Deng, et al.           Expires January 1, 2012                [Page 6]


Internet-Draft           A+P implementation             September 2011


  the maximum packet size, and then try to send as large as possible
  datagram to achieve better throughput. However the IPv4-in-IPv6
  encapsulation and the PPPoE header is very likly to cause a larger
  packet that exceeds the maximum MTU of the wire, and result in
  undesired fragmentation processing and decrease transmission
  efficiency.

  A simple solution is to enable iptables on A+P CPE to modify the MSS
  value of TCP session, using the command like "iptables -t mangle -A
  FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss
  DESIRED_MSS_VALUE". Here the DESIRED_MSS_VALUE is taken into account
  of common size of IPv4 header without options, common size of TCP
  header and size of basic IPv6 header and PPPoE header as well.

3.3. Implementing scattered Port Sets for A+P

  3.3.1. Scattered Port Sets allocation mechanism

  As described in [I-D.ietf-intarea-shared-addressing-issues], a bulk
  of incoming ports can be reserved as a centralized resource shared by
  all subscribers using a given restricted IPv4 address. In order to
  distribute incoming ports as scattered as possible among subscribers
  sharing the same restricted IPv4 address, other than allocating a
  continuous range of ports to per subscriber, a solution to distribute
  bulks of non-continuous ports among subscribers, which also takes
  port randomization of CPE NAT into account, because port
  randomization is one protection among others against blind attacks,
  is elaborated thereby.

  Note that the scattered port sets allocation mechanism implemented
  here is just one possible solution among others to offer non-
  continuous port provisioning. The implementation itself is to address
  two targets: 1) proving feasibility of non-continuous ports with A+P
  approach; 2) Evaluate efforts and investigate possibility of making
  UPnP 1.0 applications still work with this approach, with which
  experiments results will be described in Section 4.2.2.

  On every restricted IPv4 address, according to port set size N,
  log2(N)bits are randomly chose as subscribers identification bits(s
  bit) among 1st and 16th bits.  Take a sharing ration 1:32 for
  example, Figure 4 shows an example of 5bits (2nd, 5th, 7th, 9th,
  11th) being chose as s bit.



                   |1st |2nd |3rd |4th |5th |6th |7th | 8th|




Deng, et al.           Expires January 1, 2012                [Page 7]


Internet-Draft           A+P implementation             September 2011


                   +----+----+----+----+----+----+----+----+

                   | 0  |  s | 0  | 0  | s  | 0  | s  |  0 |

                   +----+----+----+----+----+----+----+----+

                   |9th |10th|11th|12th|13th|14th|15th|16th|

                   +----+----+----+----+----+----+----+----+

                   | s  | 0  |  s | 0  | 0  | 0  | 0  | 0  |

                   +----+----+----+----+----+----+----+----+

     Figure 4 : An s bit selection example (on a sharing ration 1:32
                                address).



  Subscriber ID pattern is then formed by setting all the s bits to 1
  and other trivial bits to 0.  Figure 5 illustrates an example of
  subscriber ID pattern which follows the s bit selection of figure 4.
  Note that the subscriber ID pattern can be different, ensured by the
  random s bit selection, per restricted IP address no matter whether
  the sharing ratio varies.

                   |1st |2nd |3rd |4th |5th |6th |7th | 8th|

                   +----+----+----+----+----+----+----+----+

                   | 0  | 1  | 0  | 0  | 1  | 0  | 1  |  0 |

                   +----+----+----+----+----+----+----+----+

                   |9th |10th|11th|12th|13th|14th|15th|16th|

                   +----+----+----+----+----+----+----+----+

                   | 1  | 0  | 1  | 0  | 0  | 0  | 0  | 0  |

                   +----+----+----+----+----+----+----+----+



   Figure 5 : A subscriber ID pattern example (on a sharing ration 1:32
                                address).




Deng, et al.           Expires January 1, 2012                [Page 8]


Internet-Draft           A+P implementation             September 2011




  Subscribers ID value is then assigned by setting subscriber ID
  pattern bits (s bits shown in figure 4) to a unique customer value
  and setting other trivial bits to 1. An example of subscriber ID
  value, having a subscriber ID pattern shown in the figure 5 and a
  customer value 0, is shown in the figure 6.



                   |1st |2nd |3rd |4th |5th |6th |7th | 8th|

                   +----+----+----+----+----+----+----+----+

                   | 1  | 0  | 1  | 1  | 0  | 1  | 0  | 1  |

                   +----+----+----+----+----+----+----+----+

                   |9th |10th|11th|12th|13th|14th|15th|16th|

                   +----+----+----+----+----+----+----+----+

                   | 0  | 1  |  0 | 1  | 1  | 1  | 1  | 1  |

                   +----+----+----+----+----+----+----+----+



       Figure 6 : A subscriber ID value example (customer value: 0)



  Subscriber ID pattern and subscriber ID value together uniquely
  defines a restricted port set (Non-contiguous port sets or a
  contiguous port range, depends on Subscriber ID pattern and
  subscriber ID value) on a restricted IP address.

  Pseudo-code shown in the figure 7 describes how to use subscriber ID
  pattern and subscriber ID value to implement a random ephemeral port
  selection function within the defined restricted port sets on a
  customer NAT.

        do{

            restricted_next_ephemeral = (random()|subscriber_ID_pattern)

                                        & subscriber_ID_value;



Deng, et al.           Expires January 1, 2012                [Page 9]


Internet-Draft           A+P implementation             September 2011


            if(five-tuple is unique)

            return restricted_next_ephemeral;

        }



  Figure 7 : Random ephemeral port selection within the restricted port
                                   set

  3.3.2. IPv4-Embedded IPv6 Address Format for Scattered Port Sets A+P
     CPE



  |31bits|1bit| 32bits|8bits|16bits |4bits|1bit|1bit|1bit|1bit|32bits|
  +------+----+-------+------+------+-----+----+----+----+----+-------+
  |A+P   |flag|Public | EUI64|SID_  |Reser|flag|flag|flag|flag|Public |
  |Prefix| 0  |IPv4   |      |Value |-ved |  1 |  2 |  3 |  4 | IPv4  |
  |      |    |Address|      |      |     |    |    |    |    |Address|
  +------+----+-------+------+------+-----+----+----+----+----+-------+

               Figure 8 :IPv4-Embedded IPv6 address format

  SID Value: Subscriber_ID_Value, which is unique for per subscriber
  sharing a given restricted IPv4 address. and has been allocated to
  each subscriber.

  flag0: Is this address used by CPE or PRR?

  flag1: Is address shared?

  flag2: Is length of invariable present?

  flag3: Is port range identifying sub network?

  flag4: Reserved?

  PRR maintains a mapping table, which consists of restricted IPv4
  address and it's Subscriber ID Pattern. To form an IPv6 destination
  address for incoming packet, PRR could find the right SID Pattern
  according to a destination IPv4 address, and then apply a simple
  operation shown in the figure 9.

                  SID_Value = Destination_Port | (~SID_Pattern);




Deng, et al.           Expires January 1, 2012               [Page 10]


Internet-Draft           A+P implementation             September 2011


                   Figure 9 :PRR calculates SID Value





  3.3.3. Customize a scattered Ports Set A+P NAT on Linux

  With a linux kernel 2.6.32.36, only one line of linux kernel code is
  changed, as shown in the figure5, and the same IPtables command line
  interface is used with the only one change of semantic that the
  original staring of port range becomes SID_Value and the ending port
  of a port range becomes SID_Pattern. The command line with iptables
  to configure a scattered Ports Set A+P is illustrated in the figure
  11.

           bool nf_nat_proto_unique_tuple(...)

             ...

        //The Original code:

         //*portptr = htons(min + off % range_size);

         // was changed to:

           *portptr = htons((ntohs(off) | min ) & max );

            ...

   Figure 10:Function of finding a unique 5-tuple for a scattered port
                              sets A+P NAT





  iptables -t nat -A POSTROUTING -o eth0 -p tcp -j SNAT --to-source
  a.b.c.d: SID_Value-SID_Pattern --random

  iptables -t nat -A POSTROUTING -o eth0 -p udp -j SNAT --to-source
  a.b.c.d: SID_Value-SID_Pattern --random



      Figure 11: IPtables commands for a scattered ports set A+P NAT




Deng, et al.           Expires January 1, 2012               [Page 11]


Internet-Draft           A+P implementation             September 2011








4. Application Tests and Experiments in A+P Environment



  A set of well-known applications have been tested in this IPv6 flavor
  of A+P environment to access A+P impacts on them. The test results
  show that IPv6 flavor of A+P has the same impacts on applications as
  IPv4 flavor A+P does [draft-boucadair-port-range-01]. Web browsing
  (IE and Firefox), Email (Outlook), Instant message(MSN),Skype, Google
  Earth work normally with A+P. For more details, please refer to
  [draft-boucadair-port-range-01].

4.1. A+P Impacts on Applications






























Deng, et al.           Expires January 1, 2012               [Page 12]


Internet-Draft           A+P implementation             September 2011


  +------------------+--------------------------------------+
  | Application      |     A+P impacts                      |
  +------------------+--------------------------------------+
  | IE               |     None                             |
  +------------------+--------------------------------------+
  | Firefox          |     None                             |
  +------------------+--------------------------------------+
  | FTP(Passive mode)|     None                             |
  +------------------+--------------------------------------+
  | FTP(Active mode) | require opening port forwarding      |
  |                  |                                      |
  +------------------+--------------------------------------+
  | Skype            |     None                             |
  +------------------+--------------------------------------+
  | Outlook          |     None                             |
  +------------------+--------------------------------------+
  | Google Earth     |     None                             |
  +------------------+--------------------------------------+
  | BitComet         | UPnP extensions may be required, when|
  |                  | listening port is out of A+P range;  |
  |                  | other minor effects(see Section 4.4) |
  +------------------+--------------------------------------+
  | uTorrent         | UPnP extensions may be required, when|
  |                  | listening port is out of A+P range;  |
  |                  | other minor effects(see Section 4.4) |
  +------------------+--------------------------------------+
  | Live Messenger   |     None                             |
  +------------------+--------------------------------------+


                 Figure 12: A+P impacts on applications



  For P2P (Peer-to-Peer) applications, when some of them listening on
  specific port to expect inbounding connection, it is likely to fail
  due to the listening port is out of A+P port range. Some UPnP
  extensions may be required to make P2P applications work properly
  with A+P. Other minor effects of A+P are discussed in Section 4.4.

4.2. UPnP extension experiment

  4.2.1. UPnP 1.0 extenstion

  To make P2P application work properly with port restricted NAT , we
  have designed extensions including new variables, new errorcodes as
  well as new actions to UPnP 1.0, and have them implemented with



Deng, et al.           Expires January 1, 2012               [Page 13]


Internet-Draft           A+P implementation             September 2011


  [Emule], [open source UPnP SDK 1.0.4 for Linux] and [Linux UPnP IGD
  0.92].



  In figure 5, a new error code is proposed for the existing
  "AddPortMapping" action to explicitly indicate the situation that the
  requested external port is out of range.



  +----------+-----------------------+-----------------------------+
  | ErrorCode| errorDescription      |  Description                |
  +----------+-----------------------+-----------------------------+
  | 728      |ExternalPortOutOfRange |  The external port is out   |
  |          |                       |  of the port range assigned |
  |          |                       |  to this external interface |
  +----------+-----------------------+-----------------------------+


           Figure 13:New ErrorCode for "AddPortMapping" action



  New state variables have been introduced to reflect the valid port
  range. The definitions of these state variables are shown in figure
  6.



  +-------------+-------+------+----------+---------+-------+
  |Variable     |Req. or| Data |  Allowed | Default | Eng.  |
  | Name        |   Opt.| Type |   Value  |  Value  | Units |
  +-------------+-------+------+----------+---------+-------+
  |PortRangeLow |   O   | ui2  |   >=0    |    0    |  N/A  |
  +-------------+-------+------+----------+---------+-------+
  |PortRangeHigh|   O   | ui2  |  <=65535 |  65535  |  N/A  |
  +-------------+-------+------+----------+---------+-------+


              Figure 14: New state variables for port range



  Correspondingly, new actions, GetPortRangeLow and GetPortRangeHigh,
  defined to retrieve port range information are illustrated in figure




Deng, et al.           Expires January 1, 2012               [Page 14]


Internet-Draft           A+P implementation             September 2011


  7. An IP address should be provided as argument to invoke the new
  actions, for the port range is associated with a specific IP address.



  +----------------+-----------------------+----+--------------------+
  |  Action Name   |   Argument            |Dir.|  Related           |
  |                |                       |    |  StateVariable     |
  +----------------+-----------------------+----+--------------------+
  |GetPortRangeLow | NewExternal IPAddress | IN |  ExternalIPAddress |
  |                +-----------------------+----+--------------------+
  |                | NewPortRange Low      | OUT|  PortRangeLow      |
  +----------------+-----------------------+----+--------------------+
  |GetPortRangeHigh| NewExternal IPAddress | IN |  ExternalIPAddress |
  |                +-----------------------+----+--------------------+
  |                | NewPortRange High     | OUT|  PortRangeHigh     |
  +----------------+-----------------------+----+--------------------+


                  Figure 15: New actions for port range



  Please refer to [UPnP Extension] for more details of UPnP extension
  experiment in A+P.

  4.2.2. Evaluation of scattered port allocation taking UPnP 1.0
     friendliness into account



  UPnP 1.0 applications behaviors of asking for an external port

















Deng, et al.           Expires January 1, 2012               [Page 15]


Internet-Draft           A+P implementation             September 2011


  +-------------------+----------------------------------------------+
  |  Action Name      |   Argument                      Related      |
  |                   |                                              |
  +-------------------+----------------------------------------------+
  | Microtorrent v2.2 | call GetSpecificPortMapping by incremental by|
  |                   |  1 each time,                                |
  | (also known as    |  until find an external port available, and  |
  |  uTorrent)        |  then call AddPortMapping,or return error    |
  |                   |  after five failures                         |
  +-------------------+----------------------------------------------+
  | Emule v0.50a      | call AddPortMapping, after finding the       |
  |                   | external port not available return error     |
  |                   |                                              |
  +-------------------+----------------------------------------------+
  | Azureus v4.6.0.2  | call AddPortMapping, after finding the       |
  |                   | external port not available, try the same    |
  |                   | port 5 more times by call AddPortMapping,    |
  |                   | then return error                            |
  |-------------------+----------------------------------------------+
  | Shareazav2.2.5.7  | call GetSpecificPortMapping, after finding   |
  |                   | the external port not available, return error|
  |                   | without issuing AddPortMapping               |
  +-------------------+----------------------------------------------+


  As per above typical behaviours of UPnP 1.0 applications' asking for
  external port, to instance a scattered port allocation making port
  sets interval less than 5 so that some UPnP applications would
  probably succeed in 5 times retrying, A scattered port allocation
  example would be: Subscriber ID Pattern 0x02 and 2 customers share
  the same IP address, where 4 times retrying would succeed.


















Deng, et al.           Expires January 1, 2012               [Page 16]


Internet-Draft           A+P implementation             September 2011


  +-------------------+----------------------------------------------+
  |  Action Name      |  Does it work with UPnP 1.0 friendly port    |
  |                   |  provisioning method?                        |
  |                   |                                              |
  |                   |                                              |
  +-------------------+----------------------------------------------+
  | Microtorrent v2.2 |  Yes                                         |
  |                   |                                              |
  | (also known as    |                                              |
  |  uTorrent)        |                                              |
  |                   |                                              |
  +-------------------+----------------------------------------------+
  | Emule v0.50a      |  1/5 chance of working                       |
  |                   |                                              |
  |                   |                                              |
  +-------------------+----------------------------------------------+
  | Azureus v4.6.0.2  |  1/5 chance of working                       |
  |                   |                                              |
  |                   |                                              |
  |                   |                                              |
  |-------------------+----------------------------------------------+
  | Shareazav2.2.5.7  |   1/5 chance of working                      |
  |                   |                                              |
  |                   |                                              |
  +-------------------+----------------------------------------------+


  The test results show that even with restricted UPnP 1.0 friendly
  port allocation, where however the sharing ratio 2 may not be
  applicable to most of use cases ,only one application among others
  would be granted working, while with others only the chances of
  success have been increased.

  IGD:1 is known to be broken in shared address environment [RFC6269];
  IGD:2 mitigates the issues encountered in IGD:1. The efforts,
  documented above, to solve the encountered issues in IGD:1 thereby
  aiming only at evaluate the amount of requirement modifications and
  assess the validity of the approach.

4.3. Port Usage of Applications



  Port consumptions of applications not only impact the deployment
  factor (i.e., port range size) for A+P solution but also play an
  important role in determining the port limitation of per customer on
  AFTR for Dual-Stack Lite.



Deng, et al.           Expires January 1, 2012               [Page 17]


Internet-Draft           A+P implementation             September 2011


  Therefore we have also developed and deployed a Service Probe in our
  IPv6 network, which use IPv6 TCP socket to ask A+P CPE for NAT
  session usage, and store A+P NAT statistics in a Mysql database for
  further analysis of application behaviors in terms of port and
  session consumptions.

  In figure 8, the maximum port usage of each application is the peak
  number of port consumption per second during the whole communication
  process. The duration time represents the total time from the first
  NAT binding entry being established to the last one being destroyed.

  +-----------+--------------------------+--------------+----------+
  |Application|    Test case             | Maximum      | Duration |
  |           |                          | port usage   | (seconds)|
  +-----------+--------------------------+--------------+----------+
  |           | browsing a news website  |  20-25       |    200   |
  | IE        +--------------------------+--------------+----------+
  |           | browsing a video website |  40-50       |    337   |
  +-----------+--- ----------------------+--------------+----------+
  |           | browsing a news website  |  25-30       |    240   |
  | Firefox   +--------------------------+--------------+----------+
  |           | browsing a video website |  80-90       |    230   |
  +-----------+--------------------------+--------------+----------+
  |           | browsing a news website  |  50-60       |    340   |
  | Chrome    +--------------------------+--------------+----------+
  |           | browsing a video website |  80-90       |    360   |
  +-----------+--------------------------+--------------+----------+
  | Android   | browsing a news website  |  40-50       |    300   |
  | Chrome    +--------------------------+--------------+----------+
  |           | browsing a video website |  under 10    |    160   |
  +-----------+--------------------------+--------------+----------+
  | Google    | locating a place         |  30-35       |    240   |
  | Earth     |                          |              |          |
  +-----------+--------------------------+--------------+----------+
  | Android   |                          |              |          |
  | Google    | locating a place         |  10-15       |    240   |
  | Earth     |                          |              |          |
  +-----------+--------------------------+--------------+----------+
  | Skype     | make a call              |  under 10    |    N/A   |
  +-----------+--------------------------+--------------+----------+
  | BitTorrent| downloading a file       |  200         |    N/A   |
  +-----------+--------------------------+--------------+----------+


                  Figure 16: Port usage of applications





Deng, et al.           Expires January 1, 2012               [Page 18]


Internet-Draft           A+P implementation             September 2011


4.4. BitTorrent Behaviour in A+P



  [draft-boucadair-behave-bittorrent-portrange] provides an exhaustive
  testing report about the behaviour of BiTtorrent in an A+P
  architecture. [draft-boucadair-behave-bittorrent-portrange] describes
  the main behavior of BitTorrent service in an IP shared address
  environment.  Particularly, the tests have been carried out on a
  testbed implementing [ID.boucadair-port-range] solution.  The results
  are, however, valid for all IP shared address based solutions.

  Two limitations were experienced.  The first limitation occurs when
  two clients sharing the same IP address want to simultaneously
  retrieve the SAME file located in a SINGLE remote peer.  This
  limitation is due to the default BitTorrent configuration on the
  remote peer which does not permit sending the same file to multiple
  ports of the same IP address.  This limitation is mitigated by the
  fact that clients sharing the same IP address can exchange portions
  with each other, provided the clients can find each other through a
  common tracker, DHT, or Peer Exchange.  Even if they can not, we
  observed that the remote peer would begin serving portions of the
  file automatically as soon as the other client (sharing the same IP
  address) finished downloading.  This limitation is eliminated if the
  remote peer is configured with bt.allow_same_ip == TRUE.

  The second limitation occurs when a client tries to download a file
  located on several seeders, when those seeders share the same IP
  address.  This is because the clients are enforcing bt.allow_same_ip
  parameter to FALSE.  The client will only be able to connect to one
  sender, among those having the same IP address, to download the file
  (note that the client can retrieve the file from other seeders having
  distinct IP addresses).  This limitation is eliminated if the local
  client is configured with bt.allow_same_ip == TRUE, which is somewhat
  likely as those clients will directly experience better throughput by
  changing their own configuration.

  Mutual file sharing between hosts having the same IP address has been
  checked.  Indeed, machines having the same IP address can share
  files with no alteration compared to current IP architectures.

5. Security Considerations

  TBD






Deng, et al.           Expires January 1, 2012               [Page 19]


Internet-Draft           A+P implementation             September 2011


6. IANA Considerations

  This document includes no request to IANA.

7. Conclusion

  Despite A+P introduces some impacts on existence applications, issues
  of P2P applications due to the port restricted NAT have been resolved
  by UPnP extension experiment in our test bed, and other issues are
  shared by other IP address sharing solutions. Therefore, from our
  work, it has been proved that deploying A+P in the Service Provider's
  IPv6 network during IPv6 transition period is feasible.

8. References

8.1. Normative References

  [Implementing A+P]

            Xiaoyu ZHAO.,"Implementing Public IPv4 Sharing in IPv6
            Environment", ICCGI 2010

  [UPnP Extension]

            Xiaoyu ZHAO., "UPnP Extensions for Public IPv4 Sharing in
            IPv6 Environment", ICNS 2010

8.2. Informative References

  [RFC6346]

            R. Bush., " The Address plus Port (A+P) Approach to the
            IPv4 Address Shortage", August,2011.

  [draft-boucadair-dhcpv6-shared-address-option]

            M. Boucadair., "Dynamic Host Configuration Protocol (DHCPv6)
            Options for Shared IP Addresses Solutions", draft-
            boucadair-dhcpv6-shared-address-option-01 (work in
            progress), December 21, 2009

  [draft-boucadair-port-range-01]

            "IPv4 Connectivity Access in the Context of IPv4 Address
            Exhaustion",  draft-boucadair-port-range-01(work in
            progress), January 30, 2009




Deng, et al.           Expires January 1, 2012               [Page 20]


Internet-Draft           A+P implementation             September 2011


  [Emule]

            http://www.emule-project.net/. [Accessed October 26, 2009]

  [UPnP SDK 1.0.4 for Linux]

            http://upnp.sourceforge.net/. [Accessed October 26, 2009].

  [Linux UPnP IGD 0.92].

            http://linuxigd.sourceforge.net/. [Accessed October 26,
            2009].

  [draft-boucadair-behave-bittorrent-portrange]

            M. Boucadair.,"Behaviour of BitTorrent service in an IP
            Shared Address Environment", draft-boucadair-behave-
            bittorrent-portrange-02.txt

9. Acknowledgments

  The experiments and tests described in this document have been
  explored, developed and implemented with help from Zhao Xiaoyu, Eric
  Burgey and JACQUENET Christian.

  Appreciation to Randy Bush's intitial idea of documenting this
  experience results to share the knowledge of what we have learnt
  with the community.

  Thanks to Jan Zorz for comments.



















Deng, et al.           Expires January 1, 2012               [Page 21]


Internet-Draft           A+P implementation             September 2011



Authors' Addresses

   Xiaohong Deng
   France Telecom
   Haidian district, 100190, Beijing,
   China

   Email: xiaohong.deng@orange.com

   Mohamed BOUCADAIR
   France Telecom
   Rennes,35000 France

   Email: mohamed.boucadair@orange.com

   Yiu L. Lee
   Comcast
   One Comcast Center
   Philadelphia, PA  19103
   U.S.A.

   Email: Yiu_Lee@Cable.Comcast.com

   Lan Wang
   France Telecom
   Hai dian district, 100190, Beijing, China

   Email: lan.wang@orange.com

   Tao Zheng
   France Telecom
   Hai dian district, 100190, Beijing, China

   Email: tao.zheng@orange.com

   Xiaohong Huang
   Beijing University of Post and Telecommunication
   Email: huangxh@bupt.edu.cn


   Qin Zhao
   Beijing University of Post and Telecommunication
   Email: zhaoqin.bupt@gmail.com

   Yan MA
   Beijing University of Post and Telecommunication
   Email: mayan@bupt.edu.cn



Deng, et al.           Expires January 1, 2012               [Page 22]


Internet-Draft           A+P implementation             September 2011



















































Deng, et al.           Expires January 1, 2012               [Page 23]