[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

PCP Working Group                                      M. Ait Abdesselam
Internet-Draft                                              M. Boucadair
Intended status: Informational                               A. Hasnaoui
Expires: March 28, 2013                                       J. Queiroz
                                                          France Telecom
                                                      September 24, 2012


                         PCP NAT64 Experiments
                draft-boucadair-pcp-nat64-experiments-00

Abstract

   This memo documents a set of PCP experiments conducted in NAT64
   environment.  Two services are detailed in the document: access to a
   video server behind NAT64 and SIP-based sessions.  Both 3G and Wi-Fi
   IPv6-only connectivity have been used.

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

Copyright Notice

   Copyright (c) 2012 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



Ait Abdesselam, et al.   Expires March 28, 2013                 [Page 1]

Internet-Draft            PCP NAT64 Experiments           September 2012


   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Software Modules & Modifications . . . . . . . . . . . . . . .  3
     2.1.  PCP Server . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.2.  NAT64  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.3.  PCP Packet Generator . . . . . . . . . . . . . . . . . . .  4
     2.4.  RA Daemon  . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.5.  DNS64  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.6.  Wirshark PCP Dissector . . . . . . . . . . . . . . . . . .  5
     2.7.  SIP Proxy Server . . . . . . . . . . . . . . . . . . . . .  5
     2.8.  SIP UA . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.9.  PCP Server Discovery . . . . . . . . . . . . . . . . . . .  6
       2.9.1.  DHCP . . . . . . . . . . . . . . . . . . . . . . . . .  6
       2.9.2.  RA-based approach  . . . . . . . . . . . . . . . . . .  7
   3.  Testbed Setup & Configuration  . . . . . . . . . . . . . . . .  7
     3.1.  Handsets . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.2.  IPv6-only APN for 3G . . . . . . . . . . . . . . . . . . .  8
     3.3.  Wi-Fi Connectivity . . . . . . . . . . . . . . . . . . . .  8
     3.4.  Network Topology . . . . . . . . . . . . . . . . . . . . .  9
   4.  Tested Services  . . . . . . . . . . . . . . . . . . . . . . . 10
     4.1.  HTTP Webcam Server Behind NAT64  . . . . . . . . . . . . . 11
     4.2.  SIP Use Case . . . . . . . . . . . . . . . . . . . . . . . 12
       4.2.1.  Media Sessions . . . . . . . . . . . . . . . . . . . . 15
       4.2.2.  IPv6-only to IPv4-only . . . . . . . . . . . . . . . . 15
       4.2.3.  IPv4-only to IPv6-only . . . . . . . . . . . . . . . . 19
       4.2.4.  IPv6-only to IPv6-only . . . . . . . . . . . . . . . . 20
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
















Ait Abdesselam, et al.   Expires March 28, 2013                 [Page 2]

Internet-Draft            PCP NAT64 Experiments           September 2012


1.  Introduction

   This document describes a set of PCP [I-D.ietf-pcp-base] experiments
   conducted in the context of NAT64 [RFC6146].  Both Wi-Fi and 3G
   configurations have been tested.

   The main goals of these experiments are:
   o  Port a NAT64 implementation to be controlled using PCP.
   o  Integrate a PCP Client in an Android device.
   o  Validate the PCP chain in the NAT64 context.
   o  Assess the use of PCP for NAT64 traversal and delivery of services
      behind NAT64.
   o  Evaluate the complexity to update applications to invoke PCP
      service or embed a PCP Client.

   Two services are detailed in the document: access to video server
   behind NAT64 (Section 4.1) and SIP-based sessions (Section 4.2).


2.  Software Modules & Modifications

   The following sub-sections provide more details on the software
   modules used for the experiments.

2.1.  PCP Server

   The PCP server used for NAT64 experiments is based on the DS-Lite
   compliant daemon implementation from ISC.  The base functionalities
   of this PCP Server are listed below:
   o  Configurable port range to be used for the external port mapping
      for both TCP and UDP.
   o  Support of MAP and PEER OpCodes.
   o  Support of THIRD_PARTY and PREFER_FAILURE Options.

   The code has been updated as follows:

   o  Add an interactive shell interface with basic commands to: view
      active mappings, list users, delete a specific user and reset a
      user's epoch time, etc.
   o  Adapt the behavior to be compatible with a NAT64 environment.
   o  Support of DESCRIPTION PCP option
      [I-D.boucadair-pcp-description-option].
   o  Support of PREFIX64 option
      [I-D.boucadair-pcp-nat64-prefix64-option].
   o  Support of PORT_RESERVATION option [I-D.boucadair-pcp-rtp-rtcp].
   o  Establish and maintain a communication channel to control the
      NAT64 module.




Ait Abdesselam, et al.   Expires March 28, 2013                 [Page 3]

Internet-Draft            PCP NAT64 Experiments           September 2012


   The PCP Server software architecture is shown in Figure 1.


    +----------------------------------------------------------------+
    |  +---------------------------------+       +----------------+  |
    |  | _____Core module "main.c"______ |       |    "Com.c"     |  |
    |  | main_loop(), users_db, maps_db, |       |    Network     |  |
    |  | new_client(), new_mapping(),    <=======> communication  |  |
    |  | new_dynamic(), check_expire(),  |       |  ___module___  |  |
    |  | check_client(), PCPD_flags, ... |       | PCP net_socket <===>
    |  |                                 |       | Receive_PCP()  |  |
    |  +------------/\---||--------------+       | Send_PCP()     |  |
    |    cgn_init() ||   ||                      | ...            |  |
    |               ||   || lib_init()           | NAT64 net_sock <===>
    |  +------------||---\/--------------+       | Ask_nat64(),   |  |
    |  | __PCP Server library "pcpd.c"__ |       | Ask_prefix(),  |  |
    |  |  Receive_request(),             |       | Add_binding(), |  |
    |  |  Send_response(),               |       | Add_session(), |  |
    |  |  add_mapping(), del_mapping(),  |       | Ask_client(),  |  |
    |  |  ...                            |       | ...            |  |
    |  +---------------------------------+       +----------------+  |
    +----------------------------------------------------------------+

                Figure 1: PCP server software architecture.

2.2.  NAT64

   The NAT64 module is based on the Viagenie's Ecdysis open source
   implementation for Linux.

   The compilation environment is Debian Squeeze 6.0 / Linux Kernel
   2.6.32-5-686.

   The main modifications we incorporated into Ecdysis module are listed
   below:
   o  Add a management interface to: view mappings, delete mapping, add
      a new mappings, etc.
   o  Add a listening TCP interface for the PCP server.
   o  Instantiate/delete mappings when a command is received from the
      PCP Server module.
   o  Packets matching the explicit mapping are handled appropriately.

2.3.  PCP Packet Generator

   A basic Android software, denoted as "PCP Packet Generator", has been
   developed to generate customized PCP requests to be sent to a PCP
   Server.




Ait Abdesselam, et al.   Expires March 28, 2013                 [Page 4]

Internet-Draft            PCP NAT64 Experiments           September 2012


   This tool allows to set any values for the PCP fields and Options to
   be used.  Received responses are handled, parsed and validated.  The
   content of received PCP requests are shown in a human readable
   format.

2.4.  RA Daemon

   The radvd v1.8.6 (Router Advertisement Daemon) is used to send RA
   messages for a stateless configuration of IPv6 mobile devices.

2.5.  DNS64

   Bind9 v9.9.0 is used as DNS64 server.  This PREFIX64 is configured to
   NAT64 and DNS64: 2001:688:1f94:300a::/96.

   A DNS record is created for "mysip.fr", which is used to contact the
   SIP Proxy Server.  DNS64 returns IPv4-embedded IPv6 addresses when
   resolving "mysip.fr" is: [PREIFX64+sip_serv_ipv4].

   AAAA DNS record is created for "mypcp.fr" used to contact the PCP
   Server.  DNS64 reruns the IPv6 address of the NAT64 [2001:688:1f94:
   3000::2].

2.6.  Wirshark PCP Dissector

   The used wireshark version is 1.8.0 running on Linux 2.6.32-5-686.

   For PCP, an extension "pcp dissector" has been used to parse PCP
   packets (with the port 5351 as destination or source port).  The
   recognized opcodes are MAP and PEER.  Recognized options are all
   those conforming to version 18 of [I-D.ietf-pcp-base].

2.7.  SIP Proxy Server

   The used SIP server is Asterisk v1.2 running on a Debian Squeeze 6.0
   with Kernel image: 2.6.32-5-686.

   The default configuration is used.  No extra feature to assist NAT
   traversal nor IPv6 support were activated.

2.8.  SIP UA

   The selected SIP UA for mobile devices is Linphone 1.3.2 for Android.
   Linphone is based on the eXosip2 C library.

   For our experiments, Linphone module has been updated with the main
   modifications listed below:




Ait Abdesselam, et al.   Expires March 28, 2013                 [Page 5]

Internet-Draft            PCP NAT64 Experiments           September 2012


   o  Add to the GUI a configuration option to set the domain name of
      the PCP server to be used.  Leaving the option field blank
      disables PCP.
   o  If PCP is enabled, a PCP request is sent to instantiate a mapping
      for the port used for SIP signaling messages (random port is
      used).  The retrieved external IP and port number will be used in
      the CONTACT and VIA fields of all SIP messages headers.  The same
      request is used to retrieve the PREFIX64 used by the NAT64.  The
      returned PREFIX64 is stored by the UA.
   o  If PCP is enabled, for any incoming or outgoing session, two PCP
      requests are sent to create four bindings for the audio and video
      RTP and RTCP flows.  The allocated external IP and ports are
      returned in the session description offer/answer.
   o  For an incoming call (from IPv4-only network), the IP address
      included in the INVITE headers and SDP offer is the IPv4 address
      representing the (IPv6) calling host.  The PREFIX64 of the NAT64,
      returned in PCP, is used to synthesize an IPv6 address based on
      the IPv4 address contained in the SDP offer [RFC6052].
   o  For an outgoing call, the same problem occurs to send the "200 OK"
      message.  The same PREFIX64 is used to construct the IPv4-
      converted IPv6 address representing the IPv4-only UA.
   o  Other minor GUI modifications.

   Linphone has been also patched to support ALTC attribute
   [I-D.boucadair-mmusic-altc] (see Section 4.2.4).

2.9.   PCP Server Discovery

   PCP Client needs to implement a method to discover a PCP server no
   located in the first hop.  PCP_SERVER is added automatically to
   "host" file owing to two methods detailed below:

   1.  [I-D.ietf-pcp-dhcp]: DHCPv6 PCP option is used to discover a PCP
       server name.  The DHCPv6 server, when configured to do so,
       provides the requested PCP server information by including one or
       more PCP server names option in its response.
   2.  I-D.boucadair-pcp-nodhcp-discovery specifies Router Advertisement
       option to learn the PCP Server.

   Note these discovery methods are not integrated in Android but are
   tested using Linux Fedora 15.

2.9.1.  DHCP








Ait Abdesselam, et al.   Expires March 28, 2013                 [Page 6]

Internet-Draft            PCP NAT64 Experiments           September 2012


2.9.1.1.  DHCP Server

   DHCPv6 server from ISC is used to integrate the PCP DHCPv6 option.
   We modified the configuration file: "inetc/dhcp/dhcpd6.conf" to
   provision a PCP server name to clients.

2.9.1.2.  DHCP Client

   Setting up the clients is relatively easy.  There are several
   implementations available but we used the DHCPv6 client embedded in
   Fedora 15.

   We modified the configuration file: "etc/dhcp/dhclient6.conf" to
   request a specific option (PCP OPTION).  The same code is used in the
   client and server sides:


   #pcp server option option dhcp6.OPTION_PCPSERVER code 156 = string;


   The client is updated with a script for analyzing, extracting and
   storing the content of received PCP option.

2.9.2.  RA-based approach

   As an alternative to DHCP, we also implemented an RA-based approach
   to learn the PCP Name of PCP Server(s).  This option (called PCPS)
   contains one or more PCP domain names sharing the Lifetime value.

   The router advertisement daemon (radvd-1.8.6) is run by Linux systems
   acting as IPv6 routers.

   An IPv6 host can configure the PCP server of one or more PCPSERVER
   via RA messages periodically sent by a router or solicited by a
   Router Solicitation (RS).


3.  Testbed Setup & Configuration

3.1.  Handsets

   The used handsets model is:
                        Samsung Galaxy SII GT-I9100.


   The mobile devices have been upgraded to Android ICS 4.0.3 with:





Ait Abdesselam, et al.   Expires March 28, 2013                 [Page 7]

Internet-Draft            PCP NAT64 Experiments           September 2012


      o  ROM version: IML74K.XXLPQ.
      o  Kernel version: 3.0.15-9100XXLPQ-CL223505.
      o  Base band version: I9100XXLPQ.

   The latest Android version is used to avoid some well known IPv6
   issues.

   ICS 4 version does not support DHCPv6, and the IPv6 addresses are
   autoconfigured using RA.

   For advanced network utilities, the smartphones have been rooted to
   unlock access functionalities as setting of DNS server, IP
   addressing, easiest development/debugging, custom application
   install, etc.

   Busybox is also installed to add more configuration tools.

   The "IP WebCam" is a software that turns a mobile Android device into
   a wireless webcam with multiple viewing options such as a VideoPlayer
   or web browser by creating an HTTP server that broadcasts video and
   audio flows by converting it to JavaScript.

     URL: https://play.google.com/store/apps/details?id=com.pas.webcam


3.2.  IPv6-only APN for 3G

   An IPv6-only APN from Orange France has been used to assess the PCP
   behavior over a 3G network.

3.3.  Wi-Fi Connectivity

   The Wi-Fi IPv6-only environment is set using a 45 Mbps Wireless
   Access Point Netgear-WG602-v4.

   +-----------------------------ISSUE---------------------------------+
   |The Android handsets can access to a Wi-Fi IPv6-only network by    |
   |configuring at first a static IPv4 address to be used with SSID    |
   |network in the Android Wi-Fi configuration menus.  Once the device |
   |connected to the network and the wlan0 interface got an IPv6 global|
   |address (by RA), the IPv4 address can be deleted.  This avoids the |
   |device to ask automatically for a DHCPv4 server, and allows to     |
   |connect to IPv6-only networks.  This is a problem due to lack of   |
   |global support of IPv6 in Android.                                 |
   +-------------------------------------------------------------------+


   DHCPv6 is also not supported.  The DNS server must be set manually



Ait Abdesselam, et al.   Expires March 28, 2013                 [Page 8]

Internet-Draft            PCP NAT64 Experiments           September 2012


   using the shell command:

                     #setprop net.dns1 dns_serv_address


3.4.  Network Topology

   Two network topologies are used for the tests.  For both
   configurations, the same NAT64, DNS64 and PCP server are used.
   NAT64/PCP Server is configured with
   o  An IPv4 address pool
   o  An IPv6 prefix (/64)
   o  Only the handsets change location from 3G network to Wi-Fi local
      IPv6-only network. /64 is allocated to the handset.
   o  A route to the IPv4 default gateway.
   o  A route to the IPv6 default gateway.

   The network topology is shown in Figure 2.

































Ait Abdesselam, et al.   Expires March 28, 2013                 [Page 9]

Internet-Draft            PCP NAT64 Experiments           September 2012


   +-------------------------------------------------------------------+
   |     +--------+              +---------------+         ************|
   |     | Remote |--------------|    Internet   |         *   IPv4   *|
   |     |  host  |              |       v4      |         *  Network *|
   |     +--------+              +---------------+         ************|
   |    /_________/                         |                          |
   |                                        |                          |
   |                                        |                          |
   | +------------------------+           +---------------+            |
   | |   161.105.194.14/29    |-----------|   Gateway v4  |            |
   | |   ________________     |           | 161.105.194.9 |            |
   | |                        |           +---------------+            |
   +-|      NAT64+DNS64       |----------------------------------------+
     |           +            |
   +-|      PCP Server        |----------------------------------------+
   | |   ________________     |     +------------------------+         |
   | |2001:688:1f94:3000::2/64|--+--|       Gateway v6       |         |
   | +------------------------+  |  |2001:688:1f94:3000::1/64|         |
   |                             |  +------------------------+         |
   |         +---------+         |              |                      |
   |         |  WiFi   |---------+   +-----------------------+         |
   |         |  access |             |      Internet v6      |         |
   |         |  point  |             +-----------------------+         |
   |         +---------+                        |                      |
   |            ^                  +------------------------+          |
   |            ^                  |    IPv6 only 3G APN    |          |
   |            ^                  +------------------------+          |
   |          ||__                              ^                      |
   |          |   | Handset on WiFi             ^                      |
   |          |   | Global assigned IPv6:       ^                      |
   |          |___| 2001:688:1f94:3000::XXXX/64 ^                      |
   |                                            ^                      |
   |                                            ^                      |
   |   ******************                    ||__                      |
   |   *  IPv6 Network  *                    |   | Handset on 3G       |
   |   ******************                    |   | Global assigned IPv6|
   |                                         |___| 2a01:cd01:XXXX/128  |
   +-------------------------------------------------------------------+

                    Figure 2: Global testbed topology.


4.  Tested Services








Ait Abdesselam, et al.   Expires March 28, 2013                [Page 10]

Internet-Draft            PCP NAT64 Experiments           September 2012


4.1.  HTTP Webcam Server Behind NAT64

   The first tested service is an HTTP server running on a mobile device
   connected to a IPv6-enabled 3G network, that shows the video flows of
   the device cam.

   The PCP Packet Generator is used to send a MAP request to the PCP
   server containing the following fields:

    Client IP: [2a01:cd01:XXXX]
    Request Opcode: MAP
    Requested internal port: 8080
    Suggested external address: [::ffff:0]
    Suggested external port: 8080
    Lifetime: 3000 sec
    Transport protocol: TCP
    Description: "HTTP Webcam server service"

   The PCP response returns the external IPv4 address and the external
   assigned port to be used to access the HTTP Webcam server.

   This example is shown in Figure 3.





























Ait Abdesselam, et al.   Expires March 28, 2013                [Page 11]

Internet-Draft            PCP NAT64 Experiments           September 2012


   +-------------------------------------------------------------------+
   |   +--------+src port:XXXX    +---------------+        ************|
   |   | Remote |================>|    Internet   |        *   IPv4   *|
   |   |  host  | HTTP request    |       v4      |        *  Network *|
   |   +--------+ to              +---------------+        ************|
   |  /_________/ 161.105.194.14:8080       |                          |
   |                                        |                          |
   |                                        |                          |
   | +------------------------+           +---------------+            |
   | |   161.105.194.14/29    |<==========|   Gateway v4  |            |
   | |   ________________     |port:      | 161.105.194.9 |            |
   | | NAT64+DNS64+PCP server |  8080     +---------------+            |
   +-|   <BINDING CREATED>    |----------------------------------------+
     | [161.105.194.14:YY]    |
   +-|  <>[2a01:cd01::.8080]  |----------------------------------------+
   | |   ________________     |     +------------------------+         |
   | |2001:688:1f94:3000::2/64|====>|       Gateway v6       |         |
   | +------------------------+ src |2001:688:1f94:3000::1/64|         |
   |                        port:YY +------------------------+         |
   |                                            |                      |
   |                                            |                      |
   |                                            |                      |
   |                     ||__      +------------------------+          |
   |       Handset on 3G |   |~~~~~|                        |          |
   | Global assigned IPv6|   |     |    IPv6 only 3G APN    |          |
   |   2a01:cd01:XXXX/128|___|     |                        |          |
   |  HTTP Webcam server running   +------------------------+          |
   |           on port 8080                                            |
   |                                                 ******************|
   |                                                 *  IPv6 Network  *|
   |                                                 ******************|
   +-------------------------------------------------------------------+

               Figure 3: Access to IPv4 server behind NAT64

4.2.  SIP Use Case

   The registration call flow for the IPv6-only SIP UA is depicted in
   Figure 4.

   In the following examples, port 5070 is used instead of the default
   SIP port (5060).

   At bootstrapping of the SIP UA, it retrieves the PREFIX64 used by the
   NAT64 and installs a mapping used for SIP registration.






Ait Abdesselam, et al.   Expires March 28, 2013                [Page 12]

Internet-Draft            PCP NAT64 Experiments           September 2012


          +---------+              +-------+       +------------+
          | Client4 |              | NAT64 |       |  IPv4 SIP  |
          |IPv6_only|              |+ PCP  |       |Proxy Server|
          | SIP UA  |              |Server |       | "Mysip.fr" |
          +---------+              +-------+       +------------+
               | (a) PCP MAP REQUEST   |                |
               |  Request SIP port MAP |                |
               |     PREFIX64_OPTION   |                |
               |======================>|                |
               | (b) PCP MAP RESPONSE  |                |
               | Assigned external:    |                |
               |              X.X.X.X:X|                |
               |   PREFIX64_OPTION     |                |
               |<======================|                |
               |   (1)SIP REGISTER     |(2)SIP REGISTER |
               |======================>|===============>|
               |  (4) SIP 200 OK       | (3) SIP 200 OK |
               |<======================|<===============|
               |                       |                |

                          Figure 4: SIP REGISTER

   (a) Below is shown the content of the PCP MAP Request issued by
   Client4 towards the PCP Server:

      Source: 2001:688:1f94:3000:289f:db7:e8ae:2988 port: 12345
      Destination: 2001:688:1f94:3000::2.5351

       PCP Request:
        Version: 1
        R bit: Request (0)
        Opcode: MAP (0x01)
        Requested Lifetime: 36000 sec
        PCP Client's IP Address: 2001:688:1f94:3000:289f:db7:e8ae:2988
            (2001:688:1f94:3000:289f:db7:e8ae:2988)
        MAP Request: Protocol: UDP (17)
        Internal Port: 3938
        Suggested External Port: 3938
        Suggested External IP Address: ::ffff:0.0.0.0
        Option Code: Unknown (0x7f) Option Length: 12 bytes Data:
            000000000000000000000000

   (b) The PCP MAP Response received from the PCP Server is shown below:








Ait Abdesselam, et al.   Expires March 28, 2013                [Page 13]

Internet-Draft            PCP NAT64 Experiments           September 2012


     Source: 2001:688:1f94:3000::2.5153
     Destination: 2001:688:1f94:3000:289f:db7:e8ae:2988.12345

      PCP Response:
       Version: 1
       R bit: Response (1)
       Opcode: Unknown (0x81)
       Result Code: 0
       Lifetime: 36000 sec
       Epoch Time: 1
       MAP Response Protocol: UDP (17)
       Internal Port: 3938
       Assigned External Port: 3938
       Assigned External IP Address: ::ffff:161.105.194.14 (::ffff:
           161.105.194.14)
       Option Code: PREFIX64 (0x7f) Reserved: 0 Option Length: 12 bytes
           Data: 200106881f94300a00000000

   (1) Then, the UA uses the retrieved external IP address and port to
   generate the following SIP REGISTER message:

     Source: 2001:688:1f94:3000:289f:db7:e8ae:2988 port: 3938
     Destination: 2001:688:1f94:3000::a169:c20d port:5070

      SIP Message:
       REGISTER sip:mysip.fr SIP/2.0
       Via: SIP/2.0/UDP 161.105.194.14:3938;branch=z9hG4bK1572043597
       From: <sip:client4@mysip.fr:5070>;tag=893886783
       To: <sip:client4@mysip.fr:5070>
       Call-ID: 1271173454
       CSeq: 2 REGISTER
       Contact: <sip:client4@161.105.194.14:3938;line=b3433a7df33282d>
           Authorization: Digest username="client4", realm="asterisk",
           nonce="09f75e47", uri="sip:mysip.fr",
           response="826fcff4c6e84ee45fbfa52c351e6316", algorithm=MD5
       Max-Forwards: 70
       User-Agent: Linphone/3.4.0 (eXosip2/unknown)
       Expires: 3600

   (2) SIP REGISTER is translated by the NAT64 using the PCP-
   instantiated mapping.  This message is then forwarded to the SIP
   Proxy Server:

   Source: 161.105.194.14:3938 (NAT64)
   Destination: 161.105.194.13:5070 (SIP Proxy)
    Same SIP Message as (1).

   (3) A positive response is generated by the SIP Proxy Server as shown



Ait Abdesselam, et al.   Expires March 28, 2013                [Page 14]

Internet-Draft            PCP NAT64 Experiments           September 2012


   below:

        Source: 161.105.194.13:5070 (SIP Proxy)
        Source: 161.105.194.14:3938 (NAT64)

         SIP/2.0 200 OK
         Via: SIP/2.0/UDP 161.105.194.14:
              3938;branch=z9hG4bK1572043597;received=161.105.194.14
         From: <sip:client4@mysip.fr:5070>;tag=893886783
         To: <sip:client4@mysip.fr:5070>;tag=as0b92321f
         Call-ID: 1271173454
         CSeq: 2 REGISTER
         Server: Asterisk PBX 1.6.2.9-2+squeeze6
         Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
              NOTIFY, INFO
         Supported: replaces, timer
         Expires: 3600
         Contact: <sip:client4@
              161.105.194.14:3938;line=b3433a7df33282d>;expires=3600

   (4) 200 OK message is translated by the NAT64 using the PCP-
   instantiated mapping:
          Source: 2001:688:1f94:3000::a169:c20d.5070
          Destination: 2001:688:1f94:3000:289f:db7:e8ae:2988.3938
           Same SIP message as (3).

   At the end of this procedure, IPv6-only SIP UA is able to place and
   receive session requests.

   PREFIX64 retrieved during this phase is used to build IPv4-embedded
   IPv6 addresses when receiving an IPv4 address in an SDP offer/answer.

4.2.1.  Media Sessions

   Both audio and video sessions are supported.  The audio codecs used
   for these experiments are: speex 16 KHz, speex 8Khz, and gsm.  The
   used video codecs are H264 and MPEG4.

4.2.2.  IPv6-only to IPv4-only

   Figure 5 and Figure 6 illustrate the exchanges which occur when
   initiating a SIP session from an IPv6-only UA to an IPv4-only SIP UA.

   PCP exchanges take place at the bootstrapping of the SIP UA to
   reserve one or two pair of ports (one for audio and another one for
   video).





Ait Abdesselam, et al.   Expires March 28, 2013                [Page 15]

Internet-Draft            PCP NAT64 Experiments           September 2012


   +---------+             +-------+      +------------+     +---------+
   | Client4 |             | NAT64 |      |  IPv4 SIP  |     |IPv4-only|
   |IPv6_only|             |+ PCP  |      |Proxy Server|     | SIP UA  |
   | SIP UA  |             |Server |      | "Mysip.fr" |     | Client1 |
   +---------+             +-------+      +------------+     +---------+
        | (a) PCP MAP REQUEST   |                |                 |
        |Requested port:        |                |                 |
        |              port_A   |                |                 |
        |PORT_RESERVATION_OPTION|                |                 |
        |======================>|                |                 |
        | (b) PCP MAP RESPONSE  |                |                 |
        |Assigned port:         |                |                 |
        |               port_X  |                |                 |
        |PORT_RESERVATION_OPTION|                |                 |

               Figure 5: Use PCP to reserve a pair of ports

   (a) The following PCP MAP Request is issued from Client4 towards the
   PCP Server:

      Source: 2001:688:1f94:3000:289f:db7:e8ae:2988.12345
      Destination: 2001:688:1f94:3000::2.5351

       PCP Request:
        Version: 1
        R bit: Request (0)
        Opcode: MAP (0x01)
        Requested Lifetime: 36000 sec
        PCP Client's IP Address: 2001:688:1f94:3000:289f:db7:e8ae:2988
            (2001:688:1f94:3000:289f:db7:e8ae:2988)
        MAP Request: Protocol: UDP (17)
        Internal Port: 7076
        Suggested External Port: 7076
        Suggested External IP Address: ::ffff:0.0.0.0
        Option Code: RTP (0x84) Option Length: 0 bytes Data: (NULL)

   This request aims to reserve a pair or ports preserving parity and
   contiguity.

   (b) PCP MAP Response from PCP Server to Client4:











Ait Abdesselam, et al.   Expires March 28, 2013                [Page 16]

Internet-Draft            PCP NAT64 Experiments           September 2012


       Destination: 2001:688:1f94:3000:289f:db7:e8ae:2988.12345
       Source: 2001:688:1f94:3000::2.5153
        PCP Response:
         Version: 1
         R bit: Response (1)
         Opcode: Unknown (0x81)
         Result Code: 0
         Lifetime: 36000 sec
         Epoch Time: 1
         MAP Response Protocol: UDP (17)
         Internal Port: 7076
         Assigned External Port: 7076
         Assigned External IP Address: ::ffff:161.105.194.14 (::ffff:
             161.105.194.14)
         Option Code: RTP (0x84) Option Length: 0 bytes Data: (NULL)

   At the end of this procedure, two external ports are reserved in the
   NAT64: 7076 and 7077.

   In this example, the PCP Server honors the requested external port.
   If the requested port was in use, an alternative pair of ports would
   be assigned.

   Figure 6 illustrates the messages exchanged to establish a session
   between an IPv6-only UA and a remote IPv4-only UA.

   +---------+             +-------+      +------------+     +---------+
   | Client4 |             | NAT64 |      |  IPv4 SIP  |     |IPv4-only|
   |IPv6_only|             |+ PCP  |      |Proxy Server|     | SIP UA  |
   | SIP UA  |             |Server |      | "Mysip.fr" |     | Client1 |
   +---------+             +-------+      +------------+     +---------+
        |  (1) SIP INVITE       | (2) SIP INVITE | (3) SIP INVITE  |
        |======================>|===============>|================>|
        |  (6) SIP 200 OK       | (5) SIP 200 OK |  (4) SIP 200 OK |
        |<======================|<===============|<================|
        |     (7) SIP ACK       |  (8) SIP ACK   |    (9) SIP ACK  |
        |======================>|===============>|================>|
        |                       |                |                 |
        |port_A           port_B|port_X                      port_B|
        |<======IPv6 RTP=======>|<============IPv4 RTP============>|
        |<===== IPv6 RTCP======>|<============IPv4 RTCP===========>|
        |port_A+1       port_B+1|port_X+1                  port_B+1|

                    Figure 6: IPv6 to IPv4 SIP Session

   (1, 2, 3) Below is shown the content of the SIP INVITE message sent
   by Client4.  This message uses the external IP address and port in
   SIP headers and SDP lines.  This message is translated by the NAT64



Ait Abdesselam, et al.   Expires March 28, 2013                [Page 17]

Internet-Draft            PCP NAT64 Experiments           September 2012


   without altering the SIP/SDP content.

      INVITE sip:13@mysip.fr:5070 SIP/2.0
      Via: SIP/2.0/UDP 161.105.194.14:56252;branch=z9hG4bK1876803184
      From: <sip:client4@mysip.fr:5070>;tag=631384602
      To: <sip:13@mysip.fr:5070> Call-ID: 1377792765 CSeq: 21 INVITE
      Contact: <sip:client4@161.105.194.14:56252>
      Authorization: Digest username="client4", realm="asterisk",
       nonce="3358d80b", uri="sip:13@mysip.fr:5070",
       response="41442e94f6610e6f383a355a1bdf3e48", algorithm=MD5
      Content-Type: application/sdp Allow: INVITE, ACK, CANCEL, OPTIONS,
       BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
      Max-Forwards: 70
      User-Agent: Linphone/3.4.0 (eXosip2/unknown)
      Subject: Phone call Content-Length: 443

      v=0
      o=client4 2487 2487 IN IP4 161.105.194.14
      s=Talk c=IN IP4 161.105.194.14
      b=AS:256
      t=0 0
      m=audio 7076 RTP/AVP 111 110 3 101
      a=rtpmap:111 speex/16000
      a=fmtp:111 vbr=on a=rtpmap:110 speex/8000
      a=fmtp:110 vbr=on a=rtpmap:3 GSM/8000
      a=rtpmap:101 telephone-event/8000
      a=fmtp:101 0-11
      m=video 9076 RTP/AVP 102 99
      a=rtpmap:102 H264/90000
      a=fmtp:102 profile-level-id=428014
      a=rtpmap:99 MP4V-ES/90000
      a=fmtp:99
      profile-level-id=3

   (4, 5, 6) The content of the 200 OK message is shown below:
















Ait Abdesselam, et al.   Expires March 28, 2013                [Page 18]

Internet-Draft            PCP NAT64 Experiments           September 2012


     SIP/2.0 200 OK
     Via: SIP/2.0/UDP 161.105.194.14:
        56252;branch=z9hG4bK1876803184;received=161.105.194.14
     From: <sip:client4@mysip.fr:5070>;tag=631384602
     To: <sip:13@mysip.fr:5070>;tag=as3d61114e
     Call-ID: 1377792765 CSeq: 21 INVITE
     Server: Asterisk PBX 1.6.2.9-2+squeeze6 Allow: INVITE, ACK, CANCEL,
       OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces,
       timer
     Contact: <sip:13@161.105.194.13>
     Content-Type: application/sdp Content-Length: 414

     v=0
     o=root 1210300728 1210300728 IN IP4 161.105.194.13
     c=IN IP4 161.105.194.13 b=CT:384
     t=0 0
     m=audio 13238 RTP/AVP 3 110 111 101
     a=rtpmap:3 GSM/8000
     a=rtpmap:110 speex/8000
     a=rtpmap:111 G726-32/8000
     a=rtpmap:101 telephone-event/8000
     a=fmtp:101 0-16 a=ptime:20
     a=sendrecv
     m=video 14466 RTP/AVP 102 99
     a=rtpmap:102 H264/90000
     a=rtpmap:99 MP4V-ES/90000
     a=sendrecv

   When this message is received by the IPv6-only UA, the IPv6-only UA
   uses PREFIX64 to build the IPv4-embedded IPv6 address corresponding
   to the IPv4 address included in the SDP response.  RTP/RTCP flows are
   sent to that IPv6 address.

4.2.3.  IPv4-only to IPv6-only

   Figure 7 shows the messages exchanged to establish a SIP session
   initiated from an IPv4-only UA.

   In this scenario, PREFIX64 is used to handle the SDP offer received
   by the IPv6-only UA from the IPv4-only UA.  The IPv6-only UA uses
   PREFIX64 to build the IPv4-embedded IPv6 address corresponding to the
   IPv4 address included in the SDP offer.  RTP/RTCP flows are sent to
   that IPv6 address.








Ait Abdesselam, et al.   Expires March 28, 2013                [Page 19]

Internet-Draft            PCP NAT64 Experiments           September 2012


   +---------+             +-------+      +------------+     +---------+
   | Client4 |             | NAT64 |      |  IPv4 SIP  |     |IPv4-only|
   |IPv6_only|             |+ PCP  |      |Proxy Server|     | SIP UA  |
   | SIP UA  |             |Server |      | "Mysip.fr" |     | Client1 |
   +---------+             +-------+      +------------+     +---------+
        |  (1) SIP INVITE       | (2) SIP INVITE | (3) SIP INVITE  |
        |<======================|<===============|<================|
        |  (6) SIP 200 OK       | (5) SIP 200 OK |  (4) SIP 200 OK |
        |======================>|===============>|================>|
        |     (7) SIP ACK       |  (8) SIP ACK   |    (9) SIP ACK  |
        |<======================|<===============|<================|
        |                       |                |                 |
        |port_A           port_B|port_X                      port_B|
        |<======IPv6 RTP=======>|<============IPv4 RTP============>|
        |<===== IPv6 RTCP======>|<============IPv4 RTCP===========>|
        |port_A+1       port_B+1|port_X+1                  port_B+1|

                    Figure 7: IPv4 to IPv6 SIP Session

4.2.4.  IPv6-only to IPv6-only

   Two scenarios have been tested:

   1.  The behavior of the IPv6-only UA is similar to the one described
       in Section 4.2.2: in this scenario, NAT64 is involved in the RTP
       exchanges between IPv6-only UAs.

   2.  In order to remove the NAT64 from the path, the Linphone module
       was patched to support ALTC attribute
       [I-D.boucadair-mmusic-altc].  Figure 8 shows an example of INVITE
       message generated by the IPv6-only SIP UA.  The remote IPv6-only
       UA will use the IPv6 altc line to generate its response.  As a
       consequence, IPv6 will be used to exchange RTP flows.


















Ait Abdesselam, et al.   Expires March 28, 2013                [Page 20]

Internet-Draft            PCP NAT64 Experiments           September 2012


   INVITE sip:13@mysip.fr:5070 SIP/2.0
   Via: SIP/2.0/UDP 161.105.194.14:35011;branch=z9hG4bK702695557
   From: <sip:client4@mysip.fr:5070>;tag=641336337
   To: <sip:13@mysip.fr:5070>
   Call-ID: 1532307201
   CSeq: 20 INVITE
   Contact: <sip:client4@161.105.194.14:35011>
   Content-Type: application/sdp
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
   Max-Forwards: 70
   User-Agent: Linphone/3.4.0 (eXosip2/unknown)
   Subject: Phone call
   Content-Length:   538

   v=0
   o=client4 3867 3867 IN IP4 161.105.194.14
   s=Talk
   c=IN IP4 161.105.194.14
   b=AS:256
   t=0 0
   m=audio 7056 RTP/AVP 111 110 3 101
   a=rtpmap:111 speex/16000
   a=fmtp:111 vbr=on
   a=rtpmap:110 speex/8000
   a=fmtp:110 vbr=on
   a=rtpmap:3 GSM/8000
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-11
   m=video 9056 RTP/AVP 102 99
   a=rtpmap:102 H264/90000
   a=fmtp:102 profile-level-id=428014
   a=rtpmap:99 MP4V-ES/90000
   a=fmtp:99 profile-level-id=3
   a=altc: IP6 2001:688:1f94:3000:6c73:ea54:cef:2730 45678
   a=altc: IP4 161.105.194.14 7056


                       Figure 8: PCP+ALTC Attribute


5.  IANA Considerations

   No request is made to IANA.


6.  Security Considerations

   This document does not introduce any security issue in addition to



Ait Abdesselam, et al.   Expires March 28, 2013                [Page 21]

Internet-Draft            PCP NAT64 Experiments           September 2012


   what is discussed in [I-D.ietf-pcp-base].


7.  Acknowledgements

   Special thanks to X. Deng for porting Linphone to support ALTC
   attribute.

   Many thanks to the authors of PCP Server (ISC) and NAT64 (Viagenie)
   modules.


8.  Normative References

   [I-D.boucadair-mmusic-altc]
              Boucadair, M., Kaplan, H., Gilman, R., and S.
              Veikkolainen, "Session Description Protocol (SDP)
              Alternate Connectivity (ALTC) Attribute",
              draft-boucadair-mmusic-altc-05 (work in progress),
              April 2012.

   [I-D.boucadair-pcp-description-option]
              Boucadair, M., Penno, R., and D. Wing, "PCP Description
              Option", draft-boucadair-pcp-description-option-01 (work
              in progress), September 2012.

   [I-D.boucadair-pcp-nat64-prefix64-option]
              Boucadair, M., "Learn NAT64 PREFIX64s using PCP",
              draft-boucadair-pcp-nat64-prefix64-option-02 (work in
              progress), September 2012.

   [I-D.boucadair-pcp-rtp-rtcp]
              Boucadair, M. and S. Sivakumar, "Reserving N and N+1 Ports
              with PCP", draft-boucadair-pcp-rtp-rtcp-04 (work in
              progress), April 2012.

   [I-D.ietf-pcp-base]
              Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
              Selkirk, "Port Control Protocol (PCP)",
              draft-ietf-pcp-base-27 (work in progress), September 2012.

   [I-D.ietf-pcp-dhcp]
              Boucadair, M., Penno, R., and D. Wing, "DHCP Options for
              the Port Control Protocol (PCP)", draft-ietf-pcp-dhcp-05
              (work in progress), September 2012.

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,



Ait Abdesselam, et al.   Expires March 28, 2013                [Page 22]

Internet-Draft            PCP NAT64 Experiments           September 2012


              October 2010.

   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, April 2011.


Authors' Addresses

   Mehdi Ait Abdesselam
   France Telecom
   Issy Les Moulineaux
   France

   Email: mehdi.aitabdesselam@orange.com


   Mohamed Boucadair
   France Telecom
   Rennes,   35000
   France

   Email: mohamed.boucadair@orange.com


   Amina Hasnaoui
   France Telecom
   Issy Les Moulineaux,
   France

   Email: amina.hasnaoui@orange.com


   Jaqueline Queiroz
   France Telecom
   Issy Les Moulineaux
   France

   Phone:
   Email: jaqueline.queiroz@orange.com











Ait Abdesselam, et al.   Expires March 28, 2013                [Page 23]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/