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]