idnits 2.17.1 draft-boucadair-dispatch-ipv6-atypes-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 9 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 4 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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 27, 2009) is 5386 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 4091 (Obsoleted by RFC 5245) -- Obsolete informational reference (is this intentional?): RFC 4092 (Obsoleted by RFC 5245) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft Y. Noisette 4 Intended status: Standards Track France Telecom 5 Expires: January 28, 2010 A. Allen 6 Research in Motion (RIM) 7 July 27, 2009 9 The atypes media feature tag for Session Initiation Protocol (SIP) 10 draft-boucadair-dispatch-ipv6-atypes-00 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on January 28, 2010. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 This specification defines a new media feature tag called atypes. 59 This new media feature tag indicates the IP address type capabilities 60 of the UA (User Agent) and can aid the routing process and ease the 61 invocation of required functions when heterogeneous (i.e. IPv4 and 62 IPv6) parties are involved in a given SIP session. 64 Requirements Language 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC 2119 [RFC2119]. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Justification for atypes . . . . . . . . . . . . . . . . . . . 5 74 3. Relationship of atypes to ANAT/ICE . . . . . . . . . . . . . . 5 75 4. sip.atypes Media Feature Tag . . . . . . . . . . . . . . . . . 7 76 5. Session Routing Considerations . . . . . . . . . . . . . . . . 9 77 6. Examples of atypes tag usages . . . . . . . . . . . . . . . . 9 78 6.1. IPv4-only UA . . . . . . . . . . . . . . . . . . . . . . . 9 79 6.2. IPv6-only UA . . . . . . . . . . . . . . . . . . . . . . . 10 80 6.3. Dual Stack REGISTER with one IP address in Contact 81 header field . . . . . . . . . . . . . . . . . . . . . . . 11 82 6.4. Dual Stack REGISTER with two IP addresses in Contact 83 header field . . . . . . . . . . . . . . . . . . . . . . . 12 84 6.5. Dual Stack REGISTER with one IPv4-mapped IPv6 address 85 in the Contact header field . . . . . . . . . . . . . . . 13 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 91 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 94 1. Introduction 96 Due to IPv4 address exhaustion problem, IPv6 deployment should be 97 accelerated. In this context and especially from a SIP perspective, 98 the IPv4-IPv6 co-existence introduces heterogeneous scenarios with 99 combinations of IPv4 and IPv6 nodes some of which are capable of 100 supporting both IPv4 and IPv6 dual stack (DS) and some of which are 101 capable of supporting only IPv4 or only IPv6. Additionally, some UAs 102 that are dual stack capable are unable to use both interfaces 103 natively at the same time which can mean for example that if a UA has 104 to use IPv6 for signaling it cannot use IPv4 for media even though 105 the UA supports an IPv4 stack. This mainly motivated by restrictions 106 due to available resources such the need to maintain one PDP (packet 107 data protocol) context in case of mobile networks. 109 Draft-ietf-sipping-ipv6-transition [I-D.ietf-sipping-v6-transition] 110 provides recommendations to solve this issue including recommending 111 Dual Stack (DS) nodes in the core service platform having the 112 signalling and media path traverse these DS elements. While this is 113 viable for big service providers it not viable for smaller ones 114 especially at the earlier stages of IPv6 deployment. Upgrading 115 existing networks to follow all these recommendations requires a 116 large investment. 118 An interim alternative is to use a SIP Application Level Gateway 119 (ALG) and a Network Address Translation - Protocol 120 Translation(NAT-PT) node to convert between IPv4 and IPv6 addressing. 121 However an ALG and a NAT-PT/NAT64 introduce additional nodes into the 122 signaling and media paths and can result in the so called "trombone" 123 effect with signaling and even more importantly media being 124 unnecessarily routed via an ALG/NAT-PT/NAT64 in a network located at 125 a significant distance from both of the UAs involved in the session. 126 This is particularly significant in mobile networks in roaming 127 scenarios where potentially media then has be routed via multiple 128 hops over international links when a roaming user establishes a 129 session with a user located in the roamed to country. This situation 130 is potentially unavoidable when an ALG/NAT-PT/NAT64 is needed to be 131 inserted in the signaling and the media path because of incompatible 132 IP versions between UAs that require IP address translation. It is 133 highly undesirable to redundantly include ALG/NAT-PT/NAT64 nodes in 134 the path when the UAs can establish sessions without requiring ALG/ 135 NAT-PT nodes in the path. 137 In order to avoid redundant inclusion of ALG/ NAT-PT/NAT64 nodes in 138 the path, it is necessary for network nodes to be able to determine 139 the connectivity types supported by UAs prior to forwarding session 140 establishment requests. Without such a capability, SIP Proxy Servers 141 have no way to predict a session failure without a ALG/NAT-PT/NAT64 142 being included in the path even when the ANAT [RFC4091] [RFC4092] or 143 ICE [I-D.ietf-mmusic-ice] mechanisms are also used. 145 Additionally, when multiple UAs are registered with the same Address 146 of Record (AoR) it is useful to be able to have a UA indicate a 147 preference to contact a UA using the mechanism defined in RFC 3841 148 [RFC3841] that supports the same IP version in order to avoid the 149 need for NAT-PT/NAT64. 151 This specification also addresses call routing and optimization 152 mechanisms using the atypes Media Feature Tag to avoid as much as 153 possible invoking SIP ALGs and NAT-PT/NAT64 when establishing a 154 multimedia session between UAs. 156 2. Justification for atypes 158 SIP service platforms should be aware of the type of the involved 159 peers before forwarding session establishment requests. If these 160 means are not supported, SIP Proxy Servers have no way to predict a 161 session failure, even if ANAT [RFC4091] or ICE [I-D.ietf-mmusic-ice] 162 procedures are adopted, and also to optimise the invocation of 163 adaptation functions. 165 The first alternative to notify the service platform about the type 166 of the UA is to send SIP REGISTER message which encloses all 167 available IP addresses. For IPv4-only and IPv6-only UAs, only one 168 single IP address is carried in SIP REGISTER messages. For DS UAs, 169 two IP addresses are enclosed. Upon receipt, of this message, the 170 registrar stores these addresses. Two registration databases may be 171 maintained, one for IPv4 and another one for IPv6. A second 172 alternative is to send several REGISTER request using available 173 connectivity types. In this case, a DS UA sends two REGISTER 174 messages. The first one is sent using its IPv4 connectivity and the 175 second one using its IPv6 ones. Two databases are maintained by the 176 conversational service platform. Consequently, upon receipt of an 177 INVITE, the SIP Proxy Server may question its databases to retrieve 178 the types of the involved parties. SIP ALG is invoked accordingly. 180 The drawback of this procedure is that it depends on the behaviour of 181 the terminal. A standardised behaviour should be encouraged. To 182 that aim, a new Media Feature Tag is introduced in this document. 183 More details are provided hereafter. 185 3. Relationship of atypes to ANAT/ICE 187 ICE [I-D.ietf-mmusic-ice] specification deprecates 189 [RFC4091][RFC4092]. Like ANAT, ICE can be used to enclose both IPv4 190 and IPv6 information in a given SDP offer. In the remaining part, 191 ANAT and ICE are used interchangeably since, from IPv4-IPv6 192 interworking perspective, both provide the same solution. 194 ANAT/ICE makes it possible for Dual Stack UAs to provide both IPv4 195 and IPv6 addresses for a single logical media stream. This 196 singularly helps interworking as, whatever the distant UA version is 197 (IPv4/IPv6-only or Dual-Stack), this latter should be able to 198 understand at least one of the offers. In this way the ANAT/ICE 199 semantic provides a first approach to interworking problem, when 200 heterogeneous UAs are involved in the SIP communication. It indeed 201 improves SIP exchanges, in so far as it allows all sessions arising/ 202 coming from Dual Stack UA to lead to successful calls. 204 This interesting feature needs however to be nuanced, as it 205 unfortunately does not fit all cases. [RFC4091] already lists some 206 cases where, depending on the implementation, recipients of an offer 207 using ANAT might have different behaviours, thus requiring the 208 introduction of the sdp-anat option-tag. ANAT also requires the UA 209 to be Dual Stack, which means it does not cover the case where UAs 210 belong to different and restrictive IP version realms. In other 211 words, the ANAT proposition does not help solving scenarios where 212 mono-stack (i.e. IPv4 or IPv6) UAs are involved. In this latter 213 case, SIP exchanges can only succeed if intermediary nodes or 214 functions (Proxy Servers, ALG, Session Border Controllers (SBCs), 215 etc.) intervene in the signalling path. This intervention, denoted 216 as adaptation function in the rest of this document, is necessary to 217 ensure a successful SIP exchange between these mono-satck UAs. 218 Unfortunately, in these situations, ANAT/ICE does not help SIP 219 servers situated all along the signalling path to take the right 220 decision when IPv4-IPv6 interconnection needs (or should need) to be 221 tackled. 223 The atypes Media Feature Tag helps to provide a global answer to the 224 interconnection problem, when heterogeneous SIP UAs are involved. 225 Moreover, it aids SIP nodes situated all along the signalling path, 226 to determine when to invoke the adaptation function helping the 227 routing of the call. 229 The atypes Media Feature Tag makes it possible for SIP Proxy Servers 230 to determine the IP versions supported by the distant and the 231 originating UA, when they process the initial SIP request. This 232 means that, the earlier possible in the exchange, a SIP node becomes 233 aware of the potential interconnection problem due to IP version 234 incompatibility. This also means that this particular node can 235 trigger the invocation of the adaptation function, which will modify 236 the initial SDP offer in order to make this SIP exchange successful. 238 The atypes Media Feature Tag can therefore aid treatment of all 239 exchange types intervening between mono-stack (IPv4 or IPv6) or Dual 240 Stack UAs (whether they use ANAT or not). Anytime a potential 241 interconnection problem is suspected using the atypes Media Feature 242 Tag, the SIP Proxy will be able to drive the adaptation function 243 invocation and route the SIP exchange accordingly. 245 The atypes Media Feature Tag can also provide interesting 246 optimisation characteristics. For instance, a service provider might 247 force adaptation function like SIP ALGs to be invoked each time the 248 SIP message leave an IPv4 realm for an IPv6 realm (and vice-versa), 249 in order to modify the SDP offer accordingly. This kind of 250 modifications could happen more than once during the SIP signalling 251 exchanges (and even more than once in a single direction!). In the 252 end, both UAs intervening in the SIP exchange might be of the same 253 type, thus not requiring any change of the SDP offer! Using the 254 atypes Media Feature Tag such situation could be avoided, as the SIP 255 Proxy Server would determine UAs are compatible, thus no modification 256 should be make to SDP offers, even if layer 3 information are 257 modified during the routing of the SIP message. 259 The atypes Media Feature Tag can also help in the case where 260 different SIP realms are crossed, where the information from the 261 atypes Media Feature Tag for the distant UA is not available at the 262 originating Proxy Server. In this case, the atypes Media Feature Tag 263 can be included in the SIP request thus enabling the distant SIP 264 Proxy Server, which has the atypes Media Feature Tag information for 265 the remote UA, to determine whether to route the SIP request via its 266 adaptation function. 268 The atypes Media Feature Tag is not limited to the single IPv4-IPv6 269 interconnection problem, though this first version of the 270 specification is dedicated to this usage. 272 Further values of atypes can be defined in future specifications. 273 The atypes Media Feature Tag is also compatible with the parallel 274 usage of ICE or CCAP [I-D.boucadair-mmusic-ccap].. 276 4. sip.atypes Media Feature Tag 278 The 'sip.app-subtype' media feature tag is of type token with a case- 279 sensitive equality relationship. It indicates whether a 280 (communications) device supports IPv4 for both signaling and media, 281 IPv6 for both signaling and media, IPv6 for signaling and IPv4 for 282 media simultaneously, IPv4 for signaling and IPv6 for media 283 simultaneously. A plurality of tokens is included for all the 284 supported combinations. Its values include: 286 - ipv4: The device can support IPv4 addresses for both signaling 287 and media. 289 - ipv6: The device can support IPv6 addresses for both signaling 290 and media. 292 - ipv4s-ipv6m: The device can support both IPv4 and IPv6 addresses 293 and use the IPv4 address for signaling and the IPv6 address for 294 media. 296 - ipv6s-ipv4m: The device can support both IPv4 and IPv6 addresses 297 and use the IPv6 address for signaling and the IPv4 address for 298 media. 300 Other values of atypes can be defined such as: 302 - ipv4_via_nat46: When enclosed in a SIP message, a given SIP UA 303 indicates "here is my IPv4 address, it goes through a translator 304 so avoid using it if you can utilize my IPv6 address" 306 - ipv6_via_nat64: When enclosed in a SIP message, a given SIP UA 307 indicates "here is my IPv6 address, it goes through a translator 308 so avoid using it if you can utilize my IPv4 address" 310 - ipv4_via_cgn: When enclosed in a SIP message, a given SIP UA 311 indicates "here is my IPv4 address, it goes through a CGN device 312 so avoid using it if you can utilize a public IPv4 or IPv6 313 address" 315 When included in the Contact header field of a REGISTER request or an 316 INVITE request, a UAC SHOULD include all atypes values that represent 317 the address type combinations it can currently support. When 318 included in the Contact header field of a response a UAS SHOULD 319 include all atypes values that represent the address type 320 combinations it can currently support. 322 A UAS that receives an OPTIONS request SHOULD include in the Contact 323 header field an atypes Media Feature Tag containing all atypes values 324 that represent the address type combinations it can currently 325 support. 327 A given UA MAY restrict its SIP communications to its IPv4-only 328 interface or IPv6-only ones or MAY use all available ones. The 329 selected local restriction is conveyed in the atypes Media Feature 330 Tag. Within this context, an IPv6 interface is judged available only 331 if the scope of this interface is global and not local to the link. 333 When included in the Accept-Contact or Reject-Contact header field, 334 it indicates a desire on the part of a UAC to be connected to a UAS 335 which can support, or cannot support respectively, the address types 336 and address type combinations specified. 338 5. Session Routing Considerations 340 Based on atypes tag value, the Registrar classifies the UA IP address 341 capabilities for signaling and media. 343 In order to route calls and to decide the need to invoke a SIP ALG or 344 to alter SIP messages, which leads to a successful call between 345 heterogeneous parties, a SIP Proxy Server MAY act as follows: 347 a. A first alternative is to interrogate the registration database 348 maintained by the Registrar Server: In this alternative, the SIP 349 Proxy Server asks the Registrar Server about the type of the 350 Called and the Caller parties. The SIP Proxy Server decides to 351 invoke an ALG in case the two involved parties are either IPv4- 352 only or IPv6-only. 354 b. The second alternative is to examine the atypes Media Feature Tag 355 conveyed in the Contact header field of the INVITE request and 356 the atypes Media Feature Tag values stored by the Registrar 357 Server for the address type of the Called party. In this 358 scenario, the SIP Proxy Server routes the call by comparing the 359 compatibility of the two retrieved atypes values (types of Called 360 and Caller parties). 362 6. Examples of atypes tag usages 364 These sections provide a set of examples of SIP messages when atypes 365 media feature tag is used. 367 6.1. IPv4-only UA 369 Let consider an IPv4-only UA denoted A. Its IP address is 370 192.165.25.2. This UA has been provisioned with required contact 371 information to contact its Registrar (RS). In this example, a FQDN 372 is provided: rs.test.com. Means that have been used to provision the 373 UA are out of scope of this document. 375 (1) A sends this REGISTER message to its Registrar Server RS: 377 REGISTER sip:rs.test.com SIP/2.0 378 Via: SIP/2.0/UDP 192.165.25.2:5062;branch=z9hG4bK00e31d6ed 379 Max-Forwards: 70 380 Content-Length: 0 381 To: A 382 From: A ;tag=ed3833bd7363e68 383 Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@test.com 384 CSeq: 1830746364 REGISTER 385 Contact: A 386 ;atypes="ipv4";expires=900 388 (2) RS answers to A with a 200 OK message as follows: 390 SIP/2.0 200 OK 391 Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@test.com 392 CSeq: 1830746365 REGISTER 393 From: A ;tag=ed3833bd7363e68 394 To: A ;tag=3ab7fe89d998709 395 Via:SIP/2.0/UDP 192.165.25.2:5062;branch=z9hG4bK00e31d6ed 396 Content-Length: 0 397 Contact: A 398 ;atypes="ipv4";expires=900 400 6.2. IPv6-only UA 402 Let consider an IPv6-only UA called B which IP address is 2001:688: 403 1ffb:ff80::2. Its attached Registrar Server is identified by this 404 FQDN: r6.test.com. 406 (1) B sends to its Registrar Server the following message: 408 REGISTER sip:r6.test.com SIP/2.0 409 Via: SIP/2.0/UDP 410 [2001:688:1ffb:ff80::2]:5060;branch=z9hG4bK00e31d6ed 411 Max-Forwards: 70 412 Content-Length: 0 413 To: B 414 From: B ;tag=ed3833bd7363e68 415 Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@test.com 416 CSeq: 1830746364 REGISTER 417 Contact: B 418 ;atypes="ipv6";expires=900 420 (2) The Registrar Server answers with the following 200 OK message: 422 SIP/2.0 200 OK 423 Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@test.com 424 CSeq: 1830746365 REGISTER 425 From: B ;tag=ed3833bd7363e68 426 To: B ;tag=3ab7fe89d998709 427 Via:SIP/2.0/UDP[2001:688:1ffb:ff80::2]:5060;branch=z9hG4bK00e31d6ed 428 Content-Length: 0 429 Contact: B 430 ;atypes="ipv6";expires=900 432 One IP address MAY be enclosed in the Contact header field of a dual 433 stack registration message. The type of the contact address MAY be 434 distinct from the value of atypes. For instance: 436 o an IPv4 address may be enclosed in the Contact header field even 437 if the assigned atypes value is equal to "ipv6", 439 o or only one IP address may be carried in the Contact header field 440 even if the atypes value is set to "ipv6,ipv4". 442 The IP address in the Contact header field MAY be used by 443 intermediary proxies when contacting the UA. 445 6.3. Dual Stack REGISTER with one IP address in Contact header field 447 Let consider a dual-stack UA (DS) which IP addresses are 2001:688: 448 1ffb:ff80::2 and 192.168.25.5 which does not support IPv4 and IPv6 449 simultaneously. The FQDN of the Register Server is rs.test.com. 451 (1) DS sends a REGISTER message to its Registrar Server as follows: 453 REGISTER sip:rs.test.com SIP/2.0 454 Via: SIP/2.0/UDP 192.168.25.5:5060;branch=z9hG4bK00e31d6ed 455 Max-Forwards: 70 456 Content-Length: 0 457 To: DS 458 From: DS ;tag=ed3833bd7363e68 459 Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@test.com 460 CSeq: 1830746364 REGISTER 461 Contact: DS 462 ;atypes="ipv4,ipv6";expires=900 464 (2) The Registrar Server answers with a 200 OK message as shown 465 below: 467 SIP/2.0 200 OK 468 Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@test.com 469 CSeq: 1830746365 REGISTER 470 From: DS ;tag=ed3833bd7363e68 471 To: DS ;tag=3ab7fe89d998709 472 Via:SIP/2.0/UDP 192.168.25.5:5060;branch=z9hG4bK00e31d6ed 473 Content-Length: 0 474 Contact: DS 475 ;atypes="ipv4,ipv6";expires=900 477 6.4. Dual Stack REGISTER with two IP addresses in Contact header field 479 Let consider a dual-stack UA (DS) which IP addresses are 2001:688: 480 1ffb:ff80::2 and 192.168.25.5 which does not support IPv4 and IPv6 481 simultaneously on each interface. The FQDN of the Register Server is 482 rs.test.com. 484 (1) DS sends a REGISTER message to its Registrar Server as follows: 486 REGISTER sip:rs.test.com SIP/2.0 487 Via: SIP/2.0/UDP 192.168.25.5:5060;branch=z9hG4bK00e31d6ed 488 Max-Forwards: 70 489 Content-Length: 0 490 To: DS 491 From: DS ;tag=ed3833bd7363e68 492 Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@test.com 493 CSeq: 1830746364 REGISTER 494 Contact: DS1 495 ;atypes="ipv4";expires=900 496 Contact: DS2 497 ;atypes="ipv6";expires=900 499 (2) The Registrar Server answers with a 200 OK message as shown 500 below: 501 SIP/2.0 200 OK 502 Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@test.com 503 CSeq: 1830746365 REGISTER 504 From: DS ;tag=ed3833bd7363e68 505 To: DS ;tag=3ab7fe89d998709 506 Via:SIP/2.0/UDP 192.168.25.5:5060;branch=z9hG4bK00e31d6ed 507 Content-Length: 0 508 Contact: DS1 509 ;atypes="ipv4,ipv6";expires=900 510 Contact: DS2 511 ;atypes="ipv4,ipv6";expires=900 513 6.5. Dual Stack REGISTER with one IPv4-mapped IPv6 address in the 514 Contact header field 516 Let consider a dual-stack UA (DS) which the IPv4 address 192.168.25.5 517 is mapped to the IPV6 address ::ffff:192.168.25.5 and which does 518 support simultaneous use of IPv4 and IPv6. The FQDN of the Register 519 Server is rs.test.com. 521 (1) DS sends a REGISTER message to its Registrar Server as follows: 523 REGISTER sip:rs.test.com SIP/2.0 524 Via: SIP/2.0/UDP 192.168.25.5:5062;branch=z9hG4bK00e31d6ed 525 Max-Forwards: 70 526 Content-Length: 0 527 To: DS 528 From: DS ;tag=ed3833bd7363e68 529 Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@test.com 530 CSeq: 1830746364 REGISTER 531 Contact: DS 532 ;atypes="ipv6,ipv6s-ipv4m";expires=900 534 (2) The Registrar Server answers with a 200 OK message as shown 535 below: 537 SIP/2.0 200 OK 538 Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@test.com 539 CSeq: 1830746365 REGISTER 540 From: DS ;tag=ed3833bd7363e68 541 To: DS ;tag=3ab7fe89d998709 542 Via:SIP/2.0/UDP 192.168.25.5:5062;branch=z9hG4bK00e31d6ed 543 Content-Length: 0 544 Contact: DS 545 ;atypes="ipv6,ipv6s-ipv4m";expires=900 547 7. IANA Considerations 549 This specification adds a new media feature tag to the SIP Media 550 Feature Tag Registration Tree defined in RFC 3840 [RFC3840]. 552 Media feature tag name: sip.atypes 554 ASN.1 Identifier: TBD 556 Summary of the media feature indicated by this tag: The sip.atypes 557 media feature tag indicates whether a communications device supports 558 IPv4 for both signaling and media, IPv6 for both signaling and media, 559 IPv6 for signaling and IPv4 for media simultaneously, IPv4 for 560 signaling and IPv6 for media simultaneously. A plurality of tokens 561 is included for all the supported combinations. 563 Values appropriate for use with this feature tag: Token with an 564 equality relationship. 566 Typical values include: 568 ipv4: The device can support IPv4 addresses for both signaling and 569 media. 571 ipv6: The device can support IPv6 addresses for both signaling and 572 media. 574 ipv4s-ipv6m: The device can support both IPv4 and IPv6 addresses and 575 use the IPv4 address for signaling and the IPv6 address for media. 577 ipv6s-ipv4m: The device can support both IPv4 and IPv6 addresses and 578 use the IPv6 address for signaling and the IPv4 address for media. 580 The feature tag is intended primarily for use in the following 581 applications, protocols, services, or negotiation mechanisms: This 582 feature tag is most useful in a communications application, for 583 describing the capabilities of a device, such as a phone or PDA. 585 Examples of typical use: Optimally routing a session and ensuring 586 compatibility between IP versions to successfully establish sessions. 588 Related standards or documents: RFC XXXX [[Note to IANA: Please 589 replace XXXX with the RFC number of this specification.]]. 591 Security Considerations: Security considerations for this media 592 feature tag are discussed in Section 7 of RFC XXXX . [[Note to IANA: 593 Please replace XXXX with the RFC number of this specification.]] 595 8. Security Considerations 597 When present in a SIP request or response, this media feature tag may 598 be used to determine whether a session is routed via a ALG/NAT-PT/ 599 NAT64 in order to successfully establish a session. If the values of 600 the atypes Media Feature Tags are modified by an intermediary then it 601 is possible that a session would fail to be established if the 602 modified values caused the network proxies to not insert a ALG/ 603 NAT-PT/NAT64 when they are needed. However if the contact address 604 itself is also modified this could also prevent a session being 605 established. Integrity protection for the Contact header field 606 should be provided. 608 9. Acknowledgements 610 TBC. 612 10. References 614 10.1. Normative References 616 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 617 Requirement Levels", BCP 14, RFC 2119, March 1997. 619 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 620 "Indicating User Agent Capabilities in the Session 621 Initiation Protocol (SIP)", RFC 3840, August 2004. 623 10.2. Informative References 625 [I-D.boucadair-mmusic-ccap] 626 Boucadair, M. and H. Kaplan, "Session Description Protocol 627 (SDP) Connectivity Capability (CCAP) Attribute", 628 draft-boucadair-mmusic-ccap-00 (work in progress), 629 July 2009. 631 [I-D.ietf-mmusic-ice] 632 Rosenberg, J., "Interactive Connectivity Establishment 633 (ICE): A Protocol for Network Address Translator (NAT) 634 Traversal for Offer/Answer Protocols", 635 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 637 [I-D.ietf-sipping-v6-transition] 638 Camarillo, G., "IPv6 Transition in the Session Initiation 639 Protocol (SIP)", draft-ietf-sipping-v6-transition-07 (work 640 in progress), August 2007. 642 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 643 Preferences for the Session Initiation Protocol (SIP)", 644 RFC 3841, August 2004. 646 [RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network 647 Address Types (ANAT) Semantics for the Session Description 648 Protocol (SDP) Grouping Framework", RFC 4091, June 2005. 650 [RFC4092] Camarillo, G. and J. Rosenberg, "Usage of the Session 651 Description Protocol (SDP) Alternative Network Address 652 Types (ANAT) Semantics in the Session Initiation Protocol 653 (SIP)", RFC 4092, June 2005. 655 Authors' Addresses 657 Mohamed Boucadair 658 France Telecom 659 3, av Francois Chateau 660 Rennes 35000 661 France 663 Email: mohamed.boucadair@orange-ftgroup.com 665 Yoann Noisette 666 France Telecom 668 Email: yoann.noisette@orange-ftgroup.com 670 Andrew Allen 671 Research in Motion (RIM) 672 300 Knightsbridge Parkway, Suite 360 673 Lincolnshire, Illinois 60069 674 USA 676 Email: aallen@rim.com