idnits 2.17.1 draft-boucadair-pcp-nat64-experiments-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 12 characters in excess of 72. == There are 26 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 12 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 24, 2012) is 4225 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-boucadair-mmusic-altc-05 == Outdated reference: A later version (-05) exists of draft-boucadair-pcp-rtp-rtcp-04 == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-27 == Outdated reference: A later version (-13) exists of draft-ietf-pcp-dhcp-05 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP Working Group M. Ait Abdesselam 3 Internet-Draft M. Boucadair 4 Intended status: Informational A. Hasnaoui 5 Expires: March 28, 2013 J. Queiroz 6 France Telecom 7 September 24, 2012 9 PCP NAT64 Experiments 10 draft-boucadair-pcp-nat64-experiments-00 12 Abstract 14 This memo documents a set of PCP experiments conducted in NAT64 15 environment. Two services are detailed in the document: access to a 16 video server behind NAT64 and SIP-based sessions. Both 3G and Wi-Fi 17 IPv6-only connectivity have been used. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 28, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Software Modules & Modifications . . . . . . . . . . . . . . . 3 55 2.1. PCP Server . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.3. PCP Packet Generator . . . . . . . . . . . . . . . . . . . 4 58 2.4. RA Daemon . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.5. DNS64 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.6. Wirshark PCP Dissector . . . . . . . . . . . . . . . . . . 5 61 2.7. SIP Proxy Server . . . . . . . . . . . . . . . . . . . . . 5 62 2.8. SIP UA . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.9. PCP Server Discovery . . . . . . . . . . . . . . . . . . . 6 64 2.9.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.9.2. RA-based approach . . . . . . . . . . . . . . . . . . 7 66 3. Testbed Setup & Configuration . . . . . . . . . . . . . . . . 7 67 3.1. Handsets . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.2. IPv6-only APN for 3G . . . . . . . . . . . . . . . . . . . 8 69 3.3. Wi-Fi Connectivity . . . . . . . . . . . . . . . . . . . . 8 70 3.4. Network Topology . . . . . . . . . . . . . . . . . . . . . 9 71 4. Tested Services . . . . . . . . . . . . . . . . . . . . . . . 10 72 4.1. HTTP Webcam Server Behind NAT64 . . . . . . . . . . . . . 11 73 4.2. SIP Use Case . . . . . . . . . . . . . . . . . . . . . . . 12 74 4.2.1. Media Sessions . . . . . . . . . . . . . . . . . . . . 15 75 4.2.2. IPv6-only to IPv4-only . . . . . . . . . . . . . . . . 15 76 4.2.3. IPv4-only to IPv6-only . . . . . . . . . . . . . . . . 19 77 4.2.4. IPv6-only to IPv6-only . . . . . . . . . . . . . . . . 20 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 81 8. Normative References . . . . . . . . . . . . . . . . . . . . . 22 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 84 1. Introduction 86 This document describes a set of PCP [I-D.ietf-pcp-base] experiments 87 conducted in the context of NAT64 [RFC6146]. Both Wi-Fi and 3G 88 configurations have been tested. 90 The main goals of these experiments are: 91 o Port a NAT64 implementation to be controlled using PCP. 92 o Integrate a PCP Client in an Android device. 93 o Validate the PCP chain in the NAT64 context. 94 o Assess the use of PCP for NAT64 traversal and delivery of services 95 behind NAT64. 96 o Evaluate the complexity to update applications to invoke PCP 97 service or embed a PCP Client. 99 Two services are detailed in the document: access to video server 100 behind NAT64 (Section 4.1) and SIP-based sessions (Section 4.2). 102 2. Software Modules & Modifications 104 The following sub-sections provide more details on the software 105 modules used for the experiments. 107 2.1. PCP Server 109 The PCP server used for NAT64 experiments is based on the DS-Lite 110 compliant daemon implementation from ISC. The base functionalities 111 of this PCP Server are listed below: 112 o Configurable port range to be used for the external port mapping 113 for both TCP and UDP. 114 o Support of MAP and PEER OpCodes. 115 o Support of THIRD_PARTY and PREFER_FAILURE Options. 117 The code has been updated as follows: 119 o Add an interactive shell interface with basic commands to: view 120 active mappings, list users, delete a specific user and reset a 121 user's epoch time, etc. 122 o Adapt the behavior to be compatible with a NAT64 environment. 123 o Support of DESCRIPTION PCP option 124 [I-D.boucadair-pcp-description-option]. 125 o Support of PREFIX64 option 126 [I-D.boucadair-pcp-nat64-prefix64-option]. 127 o Support of PORT_RESERVATION option [I-D.boucadair-pcp-rtp-rtcp]. 128 o Establish and maintain a communication channel to control the 129 NAT64 module. 131 The PCP Server software architecture is shown in Figure 1. 133 +----------------------------------------------------------------+ 134 | +---------------------------------+ +----------------+ | 135 | | _____Core module "main.c"______ | | "Com.c" | | 136 | | main_loop(), users_db, maps_db, | | Network | | 137 | | new_client(), new_mapping(), <=======> communication | | 138 | | new_dynamic(), check_expire(), | | ___module___ | | 139 | | check_client(), PCPD_flags, ... | | PCP net_socket <===> 140 | | | | Receive_PCP() | | 141 | +------------/\---||--------------+ | Send_PCP() | | 142 | cgn_init() || || | ... | | 143 | || || lib_init() | NAT64 net_sock <===> 144 | +------------||---\/--------------+ | Ask_nat64(), | | 145 | | __PCP Server library "pcpd.c"__ | | Ask_prefix(), | | 146 | | Receive_request(), | | Add_binding(), | | 147 | | Send_response(), | | Add_session(), | | 148 | | add_mapping(), del_mapping(), | | Ask_client(), | | 149 | | ... | | ... | | 150 | +---------------------------------+ +----------------+ | 151 +----------------------------------------------------------------+ 153 Figure 1: PCP server software architecture. 155 2.2. NAT64 157 The NAT64 module is based on the Viagenie's Ecdysis open source 158 implementation for Linux. 160 The compilation environment is Debian Squeeze 6.0 / Linux Kernel 161 2.6.32-5-686. 163 The main modifications we incorporated into Ecdysis module are listed 164 below: 165 o Add a management interface to: view mappings, delete mapping, add 166 a new mappings, etc. 167 o Add a listening TCP interface for the PCP server. 168 o Instantiate/delete mappings when a command is received from the 169 PCP Server module. 170 o Packets matching the explicit mapping are handled appropriately. 172 2.3. PCP Packet Generator 174 A basic Android software, denoted as "PCP Packet Generator", has been 175 developed to generate customized PCP requests to be sent to a PCP 176 Server. 178 This tool allows to set any values for the PCP fields and Options to 179 be used. Received responses are handled, parsed and validated. The 180 content of received PCP requests are shown in a human readable 181 format. 183 2.4. RA Daemon 185 The radvd v1.8.6 (Router Advertisement Daemon) is used to send RA 186 messages for a stateless configuration of IPv6 mobile devices. 188 2.5. DNS64 190 Bind9 v9.9.0 is used as DNS64 server. This PREFIX64 is configured to 191 NAT64 and DNS64: 2001:688:1f94:300a::/96. 193 A DNS record is created for "mysip.fr", which is used to contact the 194 SIP Proxy Server. DNS64 returns IPv4-embedded IPv6 addresses when 195 resolving "mysip.fr" is: [PREIFX64+sip_serv_ipv4]. 197 AAAA DNS record is created for "mypcp.fr" used to contact the PCP 198 Server. DNS64 reruns the IPv6 address of the NAT64 [2001:688:1f94: 199 3000::2]. 201 2.6. Wirshark PCP Dissector 203 The used wireshark version is 1.8.0 running on Linux 2.6.32-5-686. 205 For PCP, an extension "pcp dissector" has been used to parse PCP 206 packets (with the port 5351 as destination or source port). The 207 recognized opcodes are MAP and PEER. Recognized options are all 208 those conforming to version 18 of [I-D.ietf-pcp-base]. 210 2.7. SIP Proxy Server 212 The used SIP server is Asterisk v1.2 running on a Debian Squeeze 6.0 213 with Kernel image: 2.6.32-5-686. 215 The default configuration is used. No extra feature to assist NAT 216 traversal nor IPv6 support were activated. 218 2.8. SIP UA 220 The selected SIP UA for mobile devices is Linphone 1.3.2 for Android. 221 Linphone is based on the eXosip2 C library. 223 For our experiments, Linphone module has been updated with the main 224 modifications listed below: 226 o Add to the GUI a configuration option to set the domain name of 227 the PCP server to be used. Leaving the option field blank 228 disables PCP. 229 o If PCP is enabled, a PCP request is sent to instantiate a mapping 230 for the port used for SIP signaling messages (random port is 231 used). The retrieved external IP and port number will be used in 232 the CONTACT and VIA fields of all SIP messages headers. The same 233 request is used to retrieve the PREFIX64 used by the NAT64. The 234 returned PREFIX64 is stored by the UA. 235 o If PCP is enabled, for any incoming or outgoing session, two PCP 236 requests are sent to create four bindings for the audio and video 237 RTP and RTCP flows. The allocated external IP and ports are 238 returned in the session description offer/answer. 239 o For an incoming call (from IPv4-only network), the IP address 240 included in the INVITE headers and SDP offer is the IPv4 address 241 representing the (IPv6) calling host. The PREFIX64 of the NAT64, 242 returned in PCP, is used to synthesize an IPv6 address based on 243 the IPv4 address contained in the SDP offer [RFC6052]. 244 o For an outgoing call, the same problem occurs to send the "200 OK" 245 message. The same PREFIX64 is used to construct the IPv4- 246 converted IPv6 address representing the IPv4-only UA. 247 o Other minor GUI modifications. 249 Linphone has been also patched to support ALTC attribute 250 [I-D.boucadair-mmusic-altc] (see Section 4.2.4). 252 2.9. PCP Server Discovery 254 PCP Client needs to implement a method to discover a PCP server no 255 located in the first hop. PCP_SERVER is added automatically to 256 "host" file owing to two methods detailed below: 258 1. [I-D.ietf-pcp-dhcp]: DHCPv6 PCP option is used to discover a PCP 259 server name. The DHCPv6 server, when configured to do so, 260 provides the requested PCP server information by including one or 261 more PCP server names option in its response. 262 2. I-D.boucadair-pcp-nodhcp-discovery specifies Router Advertisement 263 option to learn the PCP Server. 265 Note these discovery methods are not integrated in Android but are 266 tested using Linux Fedora 15. 268 2.9.1. DHCP 269 2.9.1.1. DHCP Server 271 DHCPv6 server from ISC is used to integrate the PCP DHCPv6 option. 272 We modified the configuration file: "inetc/dhcp/dhcpd6.conf" to 273 provision a PCP server name to clients. 275 2.9.1.2. DHCP Client 277 Setting up the clients is relatively easy. There are several 278 implementations available but we used the DHCPv6 client embedded in 279 Fedora 15. 281 We modified the configuration file: "etc/dhcp/dhclient6.conf" to 282 request a specific option (PCP OPTION). The same code is used in the 283 client and server sides: 285 #pcp server option option dhcp6.OPTION_PCPSERVER code 156 = string; 287 The client is updated with a script for analyzing, extracting and 288 storing the content of received PCP option. 290 2.9.2. RA-based approach 292 As an alternative to DHCP, we also implemented an RA-based approach 293 to learn the PCP Name of PCP Server(s). This option (called PCPS) 294 contains one or more PCP domain names sharing the Lifetime value. 296 The router advertisement daemon (radvd-1.8.6) is run by Linux systems 297 acting as IPv6 routers. 299 An IPv6 host can configure the PCP server of one or more PCPSERVER 300 via RA messages periodically sent by a router or solicited by a 301 Router Solicitation (RS). 303 3. Testbed Setup & Configuration 305 3.1. Handsets 307 The used handsets model is: 308 Samsung Galaxy SII GT-I9100. 310 The mobile devices have been upgraded to Android ICS 4.0.3 with: 312 o ROM version: IML74K.XXLPQ. 313 o Kernel version: 3.0.15-9100XXLPQ-CL223505. 314 o Base band version: I9100XXLPQ. 316 The latest Android version is used to avoid some well known IPv6 317 issues. 319 ICS 4 version does not support DHCPv6, and the IPv6 addresses are 320 autoconfigured using RA. 322 For advanced network utilities, the smartphones have been rooted to 323 unlock access functionalities as setting of DNS server, IP 324 addressing, easiest development/debugging, custom application 325 install, etc. 327 Busybox is also installed to add more configuration tools. 329 The "IP WebCam" is a software that turns a mobile Android device into 330 a wireless webcam with multiple viewing options such as a VideoPlayer 331 or web browser by creating an HTTP server that broadcasts video and 332 audio flows by converting it to JavaScript. 334 URL: https://play.google.com/store/apps/details?id=com.pas.webcam 336 3.2. IPv6-only APN for 3G 338 An IPv6-only APN from Orange France has been used to assess the PCP 339 behavior over a 3G network. 341 3.3. Wi-Fi Connectivity 343 The Wi-Fi IPv6-only environment is set using a 45 Mbps Wireless 344 Access Point Netgear-WG602-v4. 346 +-----------------------------ISSUE---------------------------------+ 347 |The Android handsets can access to a Wi-Fi IPv6-only network by | 348 |configuring at first a static IPv4 address to be used with SSID | 349 |network in the Android Wi-Fi configuration menus. Once the device | 350 |connected to the network and the wlan0 interface got an IPv6 global| 351 |address (by RA), the IPv4 address can be deleted. This avoids the | 352 |device to ask automatically for a DHCPv4 server, and allows to | 353 |connect to IPv6-only networks. This is a problem due to lack of | 354 |global support of IPv6 in Android. | 355 +-------------------------------------------------------------------+ 357 DHCPv6 is also not supported. The DNS server must be set manually 358 using the shell command: 360 #setprop net.dns1 dns_serv_address 362 3.4. Network Topology 364 Two network topologies are used for the tests. For both 365 configurations, the same NAT64, DNS64 and PCP server are used. 366 NAT64/PCP Server is configured with 367 o An IPv4 address pool 368 o An IPv6 prefix (/64) 369 o Only the handsets change location from 3G network to Wi-Fi local 370 IPv6-only network. /64 is allocated to the handset. 371 o A route to the IPv4 default gateway. 372 o A route to the IPv6 default gateway. 374 The network topology is shown in Figure 2. 376 +-------------------------------------------------------------------+ 377 | +--------+ +---------------+ ************| 378 | | Remote |--------------| Internet | * IPv4 *| 379 | | host | | v4 | * Network *| 380 | +--------+ +---------------+ ************| 381 | /_________/ | | 382 | | | 383 | | | 384 | +------------------------+ +---------------+ | 385 | | 161.105.194.14/29 |-----------| Gateway v4 | | 386 | | ________________ | | 161.105.194.9 | | 387 | | | +---------------+ | 388 +-| NAT64+DNS64 |----------------------------------------+ 389 | + | 390 +-| PCP Server |----------------------------------------+ 391 | | ________________ | +------------------------+ | 392 | |2001:688:1f94:3000::2/64|--+--| Gateway v6 | | 393 | +------------------------+ | |2001:688:1f94:3000::1/64| | 394 | | +------------------------+ | 395 | +---------+ | | | 396 | | WiFi |---------+ +-----------------------+ | 397 | | access | | Internet v6 | | 398 | | point | +-----------------------+ | 399 | +---------+ | | 400 | ^ +------------------------+ | 401 | ^ | IPv6 only 3G APN | | 402 | ^ +------------------------+ | 403 | ||__ ^ | 404 | | | Handset on WiFi ^ | 405 | | | Global assigned IPv6: ^ | 406 | |___| 2001:688:1f94:3000::XXXX/64 ^ | 407 | ^ | 408 | ^ | 409 | ****************** ||__ | 410 | * IPv6 Network * | | Handset on 3G | 411 | ****************** | | Global assigned IPv6| 412 | |___| 2a01:cd01:XXXX/128 | 413 +-------------------------------------------------------------------+ 415 Figure 2: Global testbed topology. 417 4. Tested Services 418 4.1. HTTP Webcam Server Behind NAT64 420 The first tested service is an HTTP server running on a mobile device 421 connected to a IPv6-enabled 3G network, that shows the video flows of 422 the device cam. 424 The PCP Packet Generator is used to send a MAP request to the PCP 425 server containing the following fields: 427 Client IP: [2a01:cd01:XXXX] 428 Request Opcode: MAP 429 Requested internal port: 8080 430 Suggested external address: [::ffff:0] 431 Suggested external port: 8080 432 Lifetime: 3000 sec 433 Transport protocol: TCP 434 Description: "HTTP Webcam server service" 436 The PCP response returns the external IPv4 address and the external 437 assigned port to be used to access the HTTP Webcam server. 439 This example is shown in Figure 3. 441 +-------------------------------------------------------------------+ 442 | +--------+src port:XXXX +---------------+ ************| 443 | | Remote |================>| Internet | * IPv4 *| 444 | | host | HTTP request | v4 | * Network *| 445 | +--------+ to +---------------+ ************| 446 | /_________/ 161.105.194.14:8080 | | 447 | | | 448 | | | 449 | +------------------------+ +---------------+ | 450 | | 161.105.194.14/29 |<==========| Gateway v4 | | 451 | | ________________ |port: | 161.105.194.9 | | 452 | | NAT64+DNS64+PCP server | 8080 +---------------+ | 453 +-| |----------------------------------------+ 454 | [161.105.194.14:YY] | 455 +-| <>[2a01:cd01::.8080] |----------------------------------------+ 456 | | ________________ | +------------------------+ | 457 | |2001:688:1f94:3000::2/64|====>| Gateway v6 | | 458 | +------------------------+ src |2001:688:1f94:3000::1/64| | 459 | port:YY +------------------------+ | 460 | | | 461 | | | 462 | | | 463 | ||__ +------------------------+ | 464 | Handset on 3G | |~~~~~| | | 465 | Global assigned IPv6| | | IPv6 only 3G APN | | 466 | 2a01:cd01:XXXX/128|___| | | | 467 | HTTP Webcam server running +------------------------+ | 468 | on port 8080 | 469 | ******************| 470 | * IPv6 Network *| 471 | ******************| 472 +-------------------------------------------------------------------+ 474 Figure 3: Access to IPv4 server behind NAT64 476 4.2. SIP Use Case 478 The registration call flow for the IPv6-only SIP UA is depicted in 479 Figure 4. 481 In the following examples, port 5070 is used instead of the default 482 SIP port (5060). 484 At bootstrapping of the SIP UA, it retrieves the PREFIX64 used by the 485 NAT64 and installs a mapping used for SIP registration. 487 +---------+ +-------+ +------------+ 488 | Client4 | | NAT64 | | IPv4 SIP | 489 |IPv6_only| |+ PCP | |Proxy Server| 490 | SIP UA | |Server | | "Mysip.fr" | 491 +---------+ +-------+ +------------+ 492 | (a) PCP MAP REQUEST | | 493 | Request SIP port MAP | | 494 | PREFIX64_OPTION | | 495 |======================>| | 496 | (b) PCP MAP RESPONSE | | 497 | Assigned external: | | 498 | X.X.X.X:X| | 499 | PREFIX64_OPTION | | 500 |<======================| | 501 | (1)SIP REGISTER |(2)SIP REGISTER | 502 |======================>|===============>| 503 | (4) SIP 200 OK | (3) SIP 200 OK | 504 |<======================|<===============| 505 | | | 507 Figure 4: SIP REGISTER 509 (a) Below is shown the content of the PCP MAP Request issued by 510 Client4 towards the PCP Server: 512 Source: 2001:688:1f94:3000:289f:db7:e8ae:2988 port: 12345 513 Destination: 2001:688:1f94:3000::2.5351 515 PCP Request: 516 Version: 1 517 R bit: Request (0) 518 Opcode: MAP (0x01) 519 Requested Lifetime: 36000 sec 520 PCP Client's IP Address: 2001:688:1f94:3000:289f:db7:e8ae:2988 521 (2001:688:1f94:3000:289f:db7:e8ae:2988) 522 MAP Request: Protocol: UDP (17) 523 Internal Port: 3938 524 Suggested External Port: 3938 525 Suggested External IP Address: ::ffff:0.0.0.0 526 Option Code: Unknown (0x7f) Option Length: 12 bytes Data: 527 000000000000000000000000 529 (b) The PCP MAP Response received from the PCP Server is shown below: 531 Source: 2001:688:1f94:3000::2.5153 532 Destination: 2001:688:1f94:3000:289f:db7:e8ae:2988.12345 534 PCP Response: 535 Version: 1 536 R bit: Response (1) 537 Opcode: Unknown (0x81) 538 Result Code: 0 539 Lifetime: 36000 sec 540 Epoch Time: 1 541 MAP Response Protocol: UDP (17) 542 Internal Port: 3938 543 Assigned External Port: 3938 544 Assigned External IP Address: ::ffff:161.105.194.14 (::ffff: 545 161.105.194.14) 546 Option Code: PREFIX64 (0x7f) Reserved: 0 Option Length: 12 bytes 547 Data: 200106881f94300a00000000 549 (1) Then, the UA uses the retrieved external IP address and port to 550 generate the following SIP REGISTER message: 552 Source: 2001:688:1f94:3000:289f:db7:e8ae:2988 port: 3938 553 Destination: 2001:688:1f94:3000::a169:c20d port:5070 555 SIP Message: 556 REGISTER sip:mysip.fr SIP/2.0 557 Via: SIP/2.0/UDP 161.105.194.14:3938;branch=z9hG4bK1572043597 558 From: ;tag=893886783 559 To: 560 Call-ID: 1271173454 561 CSeq: 2 REGISTER 562 Contact: 563 Authorization: Digest username="client4", realm="asterisk", 564 nonce="09f75e47", uri="sip:mysip.fr", 565 response="826fcff4c6e84ee45fbfa52c351e6316", algorithm=MD5 566 Max-Forwards: 70 567 User-Agent: Linphone/3.4.0 (eXosip2/unknown) 568 Expires: 3600 570 (2) SIP REGISTER is translated by the NAT64 using the PCP- 571 instantiated mapping. This message is then forwarded to the SIP 572 Proxy Server: 574 Source: 161.105.194.14:3938 (NAT64) 575 Destination: 161.105.194.13:5070 (SIP Proxy) 576 Same SIP Message as (1). 578 (3) A positive response is generated by the SIP Proxy Server as shown 579 below: 581 Source: 161.105.194.13:5070 (SIP Proxy) 582 Source: 161.105.194.14:3938 (NAT64) 584 SIP/2.0 200 OK 585 Via: SIP/2.0/UDP 161.105.194.14: 586 3938;branch=z9hG4bK1572043597;received=161.105.194.14 587 From: ;tag=893886783 588 To: ;tag=as0b92321f 589 Call-ID: 1271173454 590 CSeq: 2 REGISTER 591 Server: Asterisk PBX 1.6.2.9-2+squeeze6 592 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, 593 NOTIFY, INFO 594 Supported: replaces, timer 595 Expires: 3600 596 Contact: ;expires=3600 599 (4) 200 OK message is translated by the NAT64 using the PCP- 600 instantiated mapping: 601 Source: 2001:688:1f94:3000::a169:c20d.5070 602 Destination: 2001:688:1f94:3000:289f:db7:e8ae:2988.3938 603 Same SIP message as (3). 605 At the end of this procedure, IPv6-only SIP UA is able to place and 606 receive session requests. 608 PREFIX64 retrieved during this phase is used to build IPv4-embedded 609 IPv6 addresses when receiving an IPv4 address in an SDP offer/answer. 611 4.2.1. Media Sessions 613 Both audio and video sessions are supported. The audio codecs used 614 for these experiments are: speex 16 KHz, speex 8Khz, and gsm. The 615 used video codecs are H264 and MPEG4. 617 4.2.2. IPv6-only to IPv4-only 619 Figure 5 and Figure 6 illustrate the exchanges which occur when 620 initiating a SIP session from an IPv6-only UA to an IPv4-only SIP UA. 622 PCP exchanges take place at the bootstrapping of the SIP UA to 623 reserve one or two pair of ports (one for audio and another one for 624 video). 626 +---------+ +-------+ +------------+ +---------+ 627 | Client4 | | NAT64 | | IPv4 SIP | |IPv4-only| 628 |IPv6_only| |+ PCP | |Proxy Server| | SIP UA | 629 | SIP UA | |Server | | "Mysip.fr" | | Client1 | 630 +---------+ +-------+ +------------+ +---------+ 631 | (a) PCP MAP REQUEST | | | 632 |Requested port: | | | 633 | port_A | | | 634 |PORT_RESERVATION_OPTION| | | 635 |======================>| | | 636 | (b) PCP MAP RESPONSE | | | 637 |Assigned port: | | | 638 | port_X | | | 639 |PORT_RESERVATION_OPTION| | | 641 Figure 5: Use PCP to reserve a pair of ports 643 (a) The following PCP MAP Request is issued from Client4 towards the 644 PCP Server: 646 Source: 2001:688:1f94:3000:289f:db7:e8ae:2988.12345 647 Destination: 2001:688:1f94:3000::2.5351 649 PCP Request: 650 Version: 1 651 R bit: Request (0) 652 Opcode: MAP (0x01) 653 Requested Lifetime: 36000 sec 654 PCP Client's IP Address: 2001:688:1f94:3000:289f:db7:e8ae:2988 655 (2001:688:1f94:3000:289f:db7:e8ae:2988) 656 MAP Request: Protocol: UDP (17) 657 Internal Port: 7076 658 Suggested External Port: 7076 659 Suggested External IP Address: ::ffff:0.0.0.0 660 Option Code: RTP (0x84) Option Length: 0 bytes Data: (NULL) 662 This request aims to reserve a pair or ports preserving parity and 663 contiguity. 665 (b) PCP MAP Response from PCP Server to Client4: 667 Destination: 2001:688:1f94:3000:289f:db7:e8ae:2988.12345 668 Source: 2001:688:1f94:3000::2.5153 669 PCP Response: 670 Version: 1 671 R bit: Response (1) 672 Opcode: Unknown (0x81) 673 Result Code: 0 674 Lifetime: 36000 sec 675 Epoch Time: 1 676 MAP Response Protocol: UDP (17) 677 Internal Port: 7076 678 Assigned External Port: 7076 679 Assigned External IP Address: ::ffff:161.105.194.14 (::ffff: 680 161.105.194.14) 681 Option Code: RTP (0x84) Option Length: 0 bytes Data: (NULL) 683 At the end of this procedure, two external ports are reserved in the 684 NAT64: 7076 and 7077. 686 In this example, the PCP Server honors the requested external port. 687 If the requested port was in use, an alternative pair of ports would 688 be assigned. 690 Figure 6 illustrates the messages exchanged to establish a session 691 between an IPv6-only UA and a remote IPv4-only UA. 693 +---------+ +-------+ +------------+ +---------+ 694 | Client4 | | NAT64 | | IPv4 SIP | |IPv4-only| 695 |IPv6_only| |+ PCP | |Proxy Server| | SIP UA | 696 | SIP UA | |Server | | "Mysip.fr" | | Client1 | 697 +---------+ +-------+ +------------+ +---------+ 698 | (1) SIP INVITE | (2) SIP INVITE | (3) SIP INVITE | 699 |======================>|===============>|================>| 700 | (6) SIP 200 OK | (5) SIP 200 OK | (4) SIP 200 OK | 701 |<======================|<===============|<================| 702 | (7) SIP ACK | (8) SIP ACK | (9) SIP ACK | 703 |======================>|===============>|================>| 704 | | | | 705 |port_A port_B|port_X port_B| 706 |<======IPv6 RTP=======>|<============IPv4 RTP============>| 707 |<===== IPv6 RTCP======>|<============IPv4 RTCP===========>| 708 |port_A+1 port_B+1|port_X+1 port_B+1| 710 Figure 6: IPv6 to IPv4 SIP Session 712 (1, 2, 3) Below is shown the content of the SIP INVITE message sent 713 by Client4. This message uses the external IP address and port in 714 SIP headers and SDP lines. This message is translated by the NAT64 715 without altering the SIP/SDP content. 717 INVITE sip:13@mysip.fr:5070 SIP/2.0 718 Via: SIP/2.0/UDP 161.105.194.14:56252;branch=z9hG4bK1876803184 719 From: ;tag=631384602 720 To: Call-ID: 1377792765 CSeq: 21 INVITE 721 Contact: 722 Authorization: Digest username="client4", realm="asterisk", 723 nonce="3358d80b", uri="sip:13@mysip.fr:5070", 724 response="41442e94f6610e6f383a355a1bdf3e48", algorithm=MD5 725 Content-Type: application/sdp Allow: INVITE, ACK, CANCEL, OPTIONS, 726 BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO 727 Max-Forwards: 70 728 User-Agent: Linphone/3.4.0 (eXosip2/unknown) 729 Subject: Phone call Content-Length: 443 731 v=0 732 o=client4 2487 2487 IN IP4 161.105.194.14 733 s=Talk c=IN IP4 161.105.194.14 734 b=AS:256 735 t=0 0 736 m=audio 7076 RTP/AVP 111 110 3 101 737 a=rtpmap:111 speex/16000 738 a=fmtp:111 vbr=on a=rtpmap:110 speex/8000 739 a=fmtp:110 vbr=on a=rtpmap:3 GSM/8000 740 a=rtpmap:101 telephone-event/8000 741 a=fmtp:101 0-11 742 m=video 9076 RTP/AVP 102 99 743 a=rtpmap:102 H264/90000 744 a=fmtp:102 profile-level-id=428014 745 a=rtpmap:99 MP4V-ES/90000 746 a=fmtp:99 747 profile-level-id=3 749 (4, 5, 6) The content of the 200 OK message is shown below: 751 SIP/2.0 200 OK 752 Via: SIP/2.0/UDP 161.105.194.14: 753 56252;branch=z9hG4bK1876803184;received=161.105.194.14 754 From: ;tag=631384602 755 To: ;tag=as3d61114e 756 Call-ID: 1377792765 CSeq: 21 INVITE 757 Server: Asterisk PBX 1.6.2.9-2+squeeze6 Allow: INVITE, ACK, CANCEL, 758 OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces, 759 timer 760 Contact: 761 Content-Type: application/sdp Content-Length: 414 763 v=0 764 o=root 1210300728 1210300728 IN IP4 161.105.194.13 765 c=IN IP4 161.105.194.13 b=CT:384 766 t=0 0 767 m=audio 13238 RTP/AVP 3 110 111 101 768 a=rtpmap:3 GSM/8000 769 a=rtpmap:110 speex/8000 770 a=rtpmap:111 G726-32/8000 771 a=rtpmap:101 telephone-event/8000 772 a=fmtp:101 0-16 a=ptime:20 773 a=sendrecv 774 m=video 14466 RTP/AVP 102 99 775 a=rtpmap:102 H264/90000 776 a=rtpmap:99 MP4V-ES/90000 777 a=sendrecv 779 When this message is received by the IPv6-only UA, the IPv6-only UA 780 uses PREFIX64 to build the IPv4-embedded IPv6 address corresponding 781 to the IPv4 address included in the SDP response. RTP/RTCP flows are 782 sent to that IPv6 address. 784 4.2.3. IPv4-only to IPv6-only 786 Figure 7 shows the messages exchanged to establish a SIP session 787 initiated from an IPv4-only UA. 789 In this scenario, PREFIX64 is used to handle the SDP offer received 790 by the IPv6-only UA from the IPv4-only UA. The IPv6-only UA uses 791 PREFIX64 to build the IPv4-embedded IPv6 address corresponding to the 792 IPv4 address included in the SDP offer. RTP/RTCP flows are sent to 793 that IPv6 address. 795 +---------+ +-------+ +------------+ +---------+ 796 | Client4 | | NAT64 | | IPv4 SIP | |IPv4-only| 797 |IPv6_only| |+ PCP | |Proxy Server| | SIP UA | 798 | SIP UA | |Server | | "Mysip.fr" | | Client1 | 799 +---------+ +-------+ +------------+ +---------+ 800 | (1) SIP INVITE | (2) SIP INVITE | (3) SIP INVITE | 801 |<======================|<===============|<================| 802 | (6) SIP 200 OK | (5) SIP 200 OK | (4) SIP 200 OK | 803 |======================>|===============>|================>| 804 | (7) SIP ACK | (8) SIP ACK | (9) SIP ACK | 805 |<======================|<===============|<================| 806 | | | | 807 |port_A port_B|port_X port_B| 808 |<======IPv6 RTP=======>|<============IPv4 RTP============>| 809 |<===== IPv6 RTCP======>|<============IPv4 RTCP===========>| 810 |port_A+1 port_B+1|port_X+1 port_B+1| 812 Figure 7: IPv4 to IPv6 SIP Session 814 4.2.4. IPv6-only to IPv6-only 816 Two scenarios have been tested: 818 1. The behavior of the IPv6-only UA is similar to the one described 819 in Section 4.2.2: in this scenario, NAT64 is involved in the RTP 820 exchanges between IPv6-only UAs. 822 2. In order to remove the NAT64 from the path, the Linphone module 823 was patched to support ALTC attribute 824 [I-D.boucadair-mmusic-altc]. Figure 8 shows an example of INVITE 825 message generated by the IPv6-only SIP UA. The remote IPv6-only 826 UA will use the IPv6 altc line to generate its response. As a 827 consequence, IPv6 will be used to exchange RTP flows. 829 INVITE sip:13@mysip.fr:5070 SIP/2.0 830 Via: SIP/2.0/UDP 161.105.194.14:35011;branch=z9hG4bK702695557 831 From: ;tag=641336337 832 To: 833 Call-ID: 1532307201 834 CSeq: 20 INVITE 835 Contact: 836 Content-Type: application/sdp 837 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO 838 Max-Forwards: 70 839 User-Agent: Linphone/3.4.0 (eXosip2/unknown) 840 Subject: Phone call 841 Content-Length: 538 843 v=0 844 o=client4 3867 3867 IN IP4 161.105.194.14 845 s=Talk 846 c=IN IP4 161.105.194.14 847 b=AS:256 848 t=0 0 849 m=audio 7056 RTP/AVP 111 110 3 101 850 a=rtpmap:111 speex/16000 851 a=fmtp:111 vbr=on 852 a=rtpmap:110 speex/8000 853 a=fmtp:110 vbr=on 854 a=rtpmap:3 GSM/8000 855 a=rtpmap:101 telephone-event/8000 856 a=fmtp:101 0-11 857 m=video 9056 RTP/AVP 102 99 858 a=rtpmap:102 H264/90000 859 a=fmtp:102 profile-level-id=428014 860 a=rtpmap:99 MP4V-ES/90000 861 a=fmtp:99 profile-level-id=3 862 a=altc: IP6 2001:688:1f94:3000:6c73:ea54:cef:2730 45678 863 a=altc: IP4 161.105.194.14 7056 865 Figure 8: PCP+ALTC Attribute 867 5. IANA Considerations 869 No request is made to IANA. 871 6. Security Considerations 873 This document does not introduce any security issue in addition to 874 what is discussed in [I-D.ietf-pcp-base]. 876 7. Acknowledgements 878 Special thanks to X. Deng for porting Linphone to support ALTC 879 attribute. 881 Many thanks to the authors of PCP Server (ISC) and NAT64 (Viagenie) 882 modules. 884 8. Normative References 886 [I-D.boucadair-mmusic-altc] 887 Boucadair, M., Kaplan, H., Gilman, R., and S. 888 Veikkolainen, "Session Description Protocol (SDP) 889 Alternate Connectivity (ALTC) Attribute", 890 draft-boucadair-mmusic-altc-05 (work in progress), 891 April 2012. 893 [I-D.boucadair-pcp-description-option] 894 Boucadair, M., Penno, R., and D. Wing, "PCP Description 895 Option", draft-boucadair-pcp-description-option-01 (work 896 in progress), September 2012. 898 [I-D.boucadair-pcp-nat64-prefix64-option] 899 Boucadair, M., "Learn NAT64 PREFIX64s using PCP", 900 draft-boucadair-pcp-nat64-prefix64-option-02 (work in 901 progress), September 2012. 903 [I-D.boucadair-pcp-rtp-rtcp] 904 Boucadair, M. and S. Sivakumar, "Reserving N and N+1 Ports 905 with PCP", draft-boucadair-pcp-rtp-rtcp-04 (work in 906 progress), April 2012. 908 [I-D.ietf-pcp-base] 909 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 910 Selkirk, "Port Control Protocol (PCP)", 911 draft-ietf-pcp-base-27 (work in progress), September 2012. 913 [I-D.ietf-pcp-dhcp] 914 Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 915 the Port Control Protocol (PCP)", draft-ietf-pcp-dhcp-05 916 (work in progress), September 2012. 918 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 919 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 920 October 2010. 922 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 923 NAT64: Network Address and Protocol Translation from IPv6 924 Clients to IPv4 Servers", RFC 6146, April 2011. 926 Authors' Addresses 928 Mehdi Ait Abdesselam 929 France Telecom 930 Issy Les Moulineaux 931 France 933 Email: mehdi.aitabdesselam@orange.com 935 Mohamed Boucadair 936 France Telecom 937 Rennes, 35000 938 France 940 Email: mohamed.boucadair@orange.com 942 Amina Hasnaoui 943 France Telecom 944 Issy Les Moulineaux, 945 France 947 Email: amina.hasnaoui@orange.com 949 Jaqueline Queiroz 950 France Telecom 951 Issy Les Moulineaux 952 France 954 Phone: 955 Email: jaqueline.queiroz@orange.com