idnits 2.17.1 draft-boucadair-dispatch-ipv6-atypes-01.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 : ---------------------------------------------------------------------------- No issues found here. 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 (June 11, 2013) is 3972 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) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft France Telecom 4 Intended status: Standards Track A. Allen 5 Expires: December 13, 2013 Blackberry 6 June 11, 2013 8 The atypes media feature tag for Session Initiation Protocol (SIP) 9 draft-boucadair-dispatch-ipv6-atypes-01 11 Abstract 13 This specification defines a new media feature tag called atypes. 14 This new media feature tag indicates the IP address type capabilities 15 of the UA (User Agent) and can aid the routing process and ease the 16 invocation of required functions when heterogeneous (i.e., IPv4 and 17 IPv6) parties are involved in a given SIP session. 19 This specification solves a problem raised in 3GPP TS 24.229 20 [TS.24229]. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 13, 2013. 45 Copyright Notice 47 Copyright (c) 2013 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 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 75 2. Justification for atypes . . . . . . . . . . . . . . . . . . 4 76 3. Relationship of atypes to ICE/ALTC . . . . . . . . . . . . . 5 77 4. Specification of sip.atypes Media Feature Tag . . . . . . . . 7 78 4.1. sip.atypes Media Feature Tag . . . . . . . . . . . . . . 7 79 4.2. Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7 80 4.3. Session Routing Considerations . . . . . . . . . . . . . 8 81 5. Examples of atypes tag usages . . . . . . . . . . . . . . . . 8 82 5.1. IPv4-only UA . . . . . . . . . . . . . . . . . . . . . . 8 83 5.2. IPv6-only UA . . . . . . . . . . . . . . . . . . . . . . 9 84 5.3. Dual Stack UA . . . . . . . . . . . . . . . . . . . . . . 10 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 89 8.2. Informative References . . . . . . . . . . . . . . . . . 12 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 92 1. Introduction 94 Due to IPv4 address exhaustion problem, IPv6 deployment should be 95 accelerated. In this context and especially from a SIP perspective 96 [RFC3261], the IPv4-IPv6 co-existence introduces heterogeneous 97 scenarios with combinations of IPv4 and IPv6 nodes some of which are 98 capable of supporting both IPv4 and IPv6 (i.e., dual-stack (DS)) and 99 some of which are capable of supporting only IPv4 or only IPv6. 100 Additionally, some UAs that are dual-stack capable are unable to use 101 both interfaces natively at the same time which can mean for example 102 that if a UA has to use IPv6 for signaling it cannot use IPv4 for 103 media even though the UA supports an IPv4 stack. This mainly 104 motivated by restrictions due to available resources such the need to 105 maintain one PDP (Packet Data Protocol) context in case of mobile 106 networks. 108 [RFC6157] provides recommendations to solve this issue including 109 recommending dual-stack nodes in the core service platform having the 110 signalling and media path traverse these DS elements. While this is 111 viable for big service providers it not viable for smaller ones 112 especially at the earlier stages of IPv6 deployment. Upgrading 113 existing networks to follow all these recommendations requires a 114 large investment. 116 An interim alternative is to use a SIP Application Level Gateway 117 (ALG) and a IPv4-IPv6 Interworking Function to convert between IPv4 118 and IPv6 addressing. However an ALG and a IPv4-IPv6 Interworking 119 Function introduce additional nodes into the signaling and media 120 paths and can result in the so called "trombone" effect with 121 signaling and even more importantly media being unnecessarily routed 122 via an ALG/IPv4-IPv6 Interworking Function in a network located at a 123 significant distance from both of the UAs involved in the session. 124 This is particularly significant in mobile networks in roaming 125 scenarios where potentially media then has be routed via multiple 126 hops over international links when a roaming user establishes a 127 session with a user located in the roamed to country. This situation 128 is potentially unavoidable when an ALG/IPv4-IPv6 Interworking 129 Function is needed to be inserted in the signaling and the media path 130 because of incompatible IP versions between UAs that require IP 131 address translation. It is highly undesirable to redundantly include 132 ALG/IPv4-IPv6 Interworking nodes in the path when the UAs can 133 establish sessions without requiring ALG/IPv4-IPv6 Interworking nodes 134 in the path. 136 In order to avoid redundant inclusion of ALG/IPv4-IPv6 Interworking 137 nodes in the path, it is necessary for network nodes to be able to 138 determine the connectivity types supported by UAs prior to forwarding 139 session establishment requests. Without such a capability, SIP Proxy 140 Servers have no way to predict a session failure without a ALG/ 141 IPv4-IPv6 Interworking being included in the path even when ICE 142 [RFC5245] or ALTC [RFC6947] are also used. 144 Additionally, when multiple UAs are registered with the same Address 145 of Record (AoR) it is useful to be able to have a UA indicate a 146 preference to contact a UA using the mechanism defined in RFC 3841 147 [RFC3841] that supports the same IP version in order to avoid the 148 need for ALG/IPv4-IPv6 Interworking node. 150 This specification also addresses call routing and optimization 151 mechanisms using the atypes Media Feature Tag to avoid as much as 152 possible invoking SIP ALGs and IPv4-IPv6 Interworking Function when 153 establishing a multimedia session between UAs. 155 2. Justification for atypes 157 SIP service platforms should be aware of the type of the involved 158 peers before forwarding session establishment requests. If these 159 means are not supported, SIP Proxy Servers have no way to predict a 160 session failure, even if ICE or ALTC procedures are adopted, and also 161 to optimise the invocation of adaptation functions. 163 The first alternative to notify the service platform about the type 164 of the UA is to send SIP REGISTER message which encloses all 165 available IP addresses. For IPv4-only and IPv6-only UAs, only one 166 single IP address is carried in SIP REGISTER messages. For DS UAs, 167 two IP addresses are enclosed. Upon receipt, of this message, the 168 registrar stores these addresses. Two registration databases may be 169 maintained, one for IPv4 and another one for IPv6. A second 170 alternative is to send several REGISTER request using available 171 connectivity types. In this case, a DS UA sends two REGISTER 172 messages. The first one is sent using its IPv4 connectivity and the 173 second one using its IPv6 one. Two databases are maintained by the 174 conversational service platform. Consequently, upon receipt of an 175 INVITE, the SIP Proxy Server may question its databases to retrieve 176 the types of the involved parties. SIP ALG is invoked accordingly. 178 The drawback of this procedure is that it depends on the behavior of 179 the terminal. A standardised behavior should be encouraged. To that 180 aim, a new Media Feature Tag is introduced in this document. More 181 details are provided hereafter. 183 According to Section 5.4.4.1 of [TS.24229], if the S-CSCF knows that 184 the UE supports both versions simultaneously, it forwards the initial 185 INVITE request to the UE without examining the SDP Offer. 186 Section 5.4.3.1 of [TS.24229] indicates also if the S-CSCF knows that 187 the originating UE supports both IPv6 and IPv4 addresses 188 simultaneously, the S-CSCF will forward the error response to the UE 189 using the Via header field. However, [TS.24229] does not currently 190 specify any solution to enable the S-CSCF to get this knowledge. 191 atypes is intended to be a solution for that problem. 193 3. Relationship of atypes to ICE/ALTC 195 ICE [RFC5245] specification deprecates [RFC4091][RFC4092]. Like 196 ANAT, ICE can be used to enclose both IPv4 and IPv6 information in a 197 given SDP offer. In the remaining part, ANAT and ICE are used 198 interchangeably since, from IPv4-IPv6 Interworking perspective, both 199 provide the same solution. ALTC [RFC6947] is solution that allows to 200 convey both an IPv4 address and IPv6 address in the same SDP offer. 202 Both ICE and ALTC make it possible for DS UAs to provide both IPv4 203 and IPv6 addresses for a single logical media stream. This 204 singularly helps interworking as, whatever the distant UA version is 205 (IPv4/IPv6-only or dual-stack), this latter should be able to 206 understand at least one of the offers. In this way the ICE/ALTC 207 semantic provides a first approach to interworking problem, when 208 heterogeneous UAs are involved in the SIP communication. It indeed 209 improves SIP exchanges, in so far as it allows all sessions arising/ 210 coming from dual-stack UA to lead to successful calls. 212 This interesting feature needs however to be nuanced, as it 213 unfortunately does not fit all cases. [RFC4091] already lists some 214 cases where, depending on the implementation, recipients of an offer 215 using ANAT might have different behaviours, thus requiring the 216 introduction of the sdp-anat option-tag. ANAT also requires the UA 217 to be dual-stack, which means it does not cover the case where UAs 218 belong to different and restrictive IP version realms. In other 219 words, the ANAT solution does not help solving scenarios where mono- 220 stack (i.e., IPv4 or IPv6) UAs are involved. In this latter case, 221 SIP exchanges can only succeed if intermediary nodes or functions 222 (Proxy Servers, ALG, Session Border Controllers (SBCs), etc.) 223 intervene in the signalling path. This intervention, denoted as 224 IPv4-IPv6 adaptation function in the rest of this document, is 225 necessary to ensure a successful SIP exchange between these mono- 226 satck UAs. Unfortunately, in these situations, ANAT/ICE does not 227 help SIP servers situated all along the signalling path to take the 228 right decision when IPv4-IPv6 interconnection needs (or should need) 229 to be tackled. 231 The atypes Media Feature Tag helps to provide a global answer to the 232 interconnection problem, when heterogeneous SIP UAs are involved. 233 Moreover, it aids SIP nodes situated all along the signalling path, 234 to determine when to invoke the adaptation function helping the 235 routing of the call. 237 The atypes Media Feature Tag makes it possible for SIP Proxy Servers 238 to determine the IP versions supported by the distant and the 239 originating UA, when they process the initial SIP request. This 240 means that, the earlier possible in the exchange, a SIP node becomes 241 aware of the potential interconnection problem due to IP version 242 incompatibility. This also means that this particular node can 243 trigger the invocation of the adaptation function, which will modify 244 the initial SDP offer in order to make this SIP exchange successful. 246 The atypes Media Feature Tag can therefore aid treatment of all 247 exchange types intervening between mono-stack (IPv4 or IPv6) or dual- 248 stack UAs (whether they use ICE or not). Anytime a potential 249 interconnection problem is suspected using the atypes Media Feature 250 Tag, the SIP Proxy will be able to drive the adaptation function 251 invocation and route the SIP exchange accordingly. 253 The atypes Media Feature Tag can also provide interesting 254 optimisation characteristics. For instance, a service provider might 255 force adaptation function like SIP ALGs to be invoked each time the 256 SIP message leave an IPv4 realm for an IPv6 realm (and vice-versa), 257 in order to modify the SDP offer accordingly. This kind of 258 modifications could happen more than once during the SIP signalling 259 exchanges (and even more than once in a single direction). In the 260 end, both UAs intervening in the SIP exchange might be of the same 261 type, thus not requiring any change of the SDP offer. Using the 262 atypes Media Feature Tag such situation could be avoided, as the SIP 263 Proxy Server would determine UAs are compatible, thus no modification 264 should be make to SDP offers, even if Layer 3 information are 265 modified during the routing of the SIP message. 267 The atypes Media Feature Tag can also help in the case where 268 different SIP realms are crossed, where the information from the 269 atypes Media Feature Tag for the distant UA is not available at the 270 originating Proxy Server. In this case, the atypes Media Feature Tag 271 can be included in the SIP request thus enabling the distant SIP 272 Proxy Server, which has the atypes Media Feature Tag information for 273 the remote UA, to determine whether to route the SIP request via its 274 adaptation function. 276 The atypes Media Feature Tag is not limited to the single IPv4-IPv6 277 interconnection problem, though this first version of the 278 specification is dedicated to this usage. 280 Further values of atypes can be defined in future specifications. 281 The atypes Media Feature Tag is also compatible with the parallel 282 usage of ICE or ALTC. 284 4. Specification of sip.atypes Media Feature Tag 286 4.1. sip.atypes Media Feature Tag 288 The 'sip.app-subtype' media feature tag is of type token with a case- 289 sensitive equality relationship. It indicates whether a 290 (communications) device supports IPv4 for both signaling and media, 291 IPv6 for both signaling and media, IPv6 for signaling and IPv4 for 292 media simultaneously, IPv4 for signaling and IPv6 for media 293 simultaneously. A plurality of tokens is included for all the 294 supported combinations. Its values include: 296 o ipv4: The device supports IPv4. 298 o ipv6: The device supports IPv6. 300 Other values of atypes can be defined such as: 302 o 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 o 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 o 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 4.2. Behavior 317 When atypes is included in the Contact header field of a REGISTER 318 request or an INVITE request, a UAC SHOULD include all atypes values 319 that represent the address type combinations it can currently 320 support. When included in the Contact header field of a response a 321 UAS SHOULD include all atypes values that represent the address type 322 combinations it can currently support. 324 A UAS that receives an OPTIONS request SHOULD include in the Contact 325 header field an atypes Media Feature Tag containing all atypes values 326 that represent the address type combinations it can currently 327 support. 329 A given UA MAY restrict its SIP communications to its IPv4-only 330 interface or IPv6-only ones or MAY use all available ones. The 331 selected local restriction is conveyed in the atypes Media Feature 332 Tag. Within this context, an IPv6 interface is judged available only 333 if the scope of this interface is global and not local to the link. 335 When included in the Accept-Contact or Reject-Contact header field, 336 it indicates a desire on the part of a UAC to be connected to a UAS 337 which can support, or cannot support respectively, the address types 338 and address type combinations specified. 340 4.3. Session Routing Considerations 342 Based on atypes tag value, the Registrar classifies the UA IP address 343 capabilities for signaling and media. 345 In order to route calls and to decide the need to invoke a SIP ALG or 346 to alter SIP messages, which leads to a successful call between 347 heterogeneous parties, a SIP Proxy Server MAY act as follows: 349 a. A first alternative is to interrogate the registration database 350 maintained by the Registrar Server: In this alternative, the SIP 351 Proxy Server asks the Registrar Server about the type of the 352 Called and the Caller parties. The SIP Proxy Server decides to 353 invoke an ALG in case the two involved parties are either 354 IPv4-only or IPv6-only. 356 b. The second alternative is to examine the atypes Media Feature Tag 357 conveyed in the Contact header field of the INVITE request and 358 the atypes Media Feature Tag values stored by the Registrar 359 Server for the address type of the Called party. In this 360 scenario, the SIP Proxy Server routes the call by comparing the 361 compatibility of the two retrieved atypes values (types of Called 362 and Caller parties). 364 5. Examples of atypes tag usages 366 These sections provide a set of SIP message examples when atypes 367 media feature tag is used. 369 5.1. IPv4-only UA 371 Let consider an IPv4-only UA denoted "HostA". Its IP address is 372 192.0.2.1. This UA has been provisioned with required contact 373 information to contact its Registrar (RS). In this example, a FQDN 374 is provided: registrar.example.com. Means that have been used to 375 provision the UA are out of scope of this document. 377 (1) A sends this REGISTER message to its Registrar Server RS: 379 REGISTER sip:registrar.example.com SIP/2.0 380 Via: SIP/2.0/UDP 192.0.2.1:5062;branch=z9hG4bK00e31d6ed 381 Max-Forwards: 70 382 Content-Length: 0 383 To: HostA 384 From: HostA ;tag=ed3833bd7363e68 385 Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@example.com 386 CSeq: 1830746364 REGISTER 387 Contact: HostA 388 ;atypes="ipv4";expires=900 390 (2) RS answers to A with a 200 OK message as follows: 392 SIP/2.0 200 OK 393 Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@example.com 394 CSeq: 1830746365 REGISTER 395 From: HostA ;tag=ed3833bd7363e68 396 To: HostA ;tag=3ab7fe89d998709 397 Via:SIP/2.0/UDP 192.0.2.1:5062;branch=z9hG4bK00e31d6ed 398 Content-Length: 0 399 Contact: HostA 400 ;atypes="ipv4";expires=900 402 5.2. IPv6-only UA 404 Let consider an IPv6-only UA called HostB which IP address is 405 2001:db8:0:0:1::1. Its attached Registrar Server is identified by 406 this FQDN: registrar.example.com. 408 (1) B sends to its Registrar Server the following message: 410 REGISTER sip:registrar.example.com SIP/2.0 411 Via: SIP/2.0/UDP 412 [2001:db8:0:0:1::1]:5060;branch=z9hG4bK00e31d6ed 413 Max-Forwards: 70 414 Content-Length: 0 415 To: HostB 416 From: HostB ;tag=ed3833bd7363e68 417 Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@example.com 418 CSeq: 1830746364 REGISTER 419 Contact: HostB 420 ;atypes="ipv6";expires=900 422 (2) The Registrar Server answers with the following 200 OK message: 424 SIP/2.0 200 OK 425 Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@example.com 426 CSeq: 1830746365 REGISTER 427 From: HostB ;tag=ed3833bd7363e68 428 To: HostB ;tag=3ab7fe89d998709 429 Via:SIP/2.0/UDP[2001:db8:0:0:1::1]:5060;branch=z9hG4bK00e31d6ed 430 Content-Length: 0 431 Contact: HostB 432 ;atypes="ipv6";expires=900 434 One IP address MAY be enclosed in the Contact header field of a dual 435 stack registration message. The type of the contact address MAY be 436 distinct from the value of atypes. For instance: 438 o an IPv4 address may be enclosed in the Contact header field even 439 if the assigned atypes value is equal to "ipv6", 441 o or only one IP address may be carried in the Contact header field 442 even if the atypes value is set to "ipv6,ipv4". 444 The IP address in the Contact header field MAY be used by 445 intermediary proxies when contacting the UA. 447 5.3. Dual Stack UA 449 Let consider a dual-stack UA (DS) which IP addresses are 450 2001:db8:0:0:1::1 and 192.0.2.2 which does not support IPv4 and IPv6 451 simultaneously. The FQDN of the Register Server is 452 registrar.example.com. 454 (1) DS sends a REGISTER message to its Registrar Server as follows: 456 REGISTER sip:registrar.example.com SIP/2.0 457 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bK00e31d6ed 458 Max-Forwards: 70 459 Content-Length: 0 460 To: DS 461 From: DS ;tag=ed3833bd7363e68 462 Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@example.com 463 CSeq: 1830746364 REGISTER 464 Contact: DS 465 ;atypes="ipv4,ipv6";expires=900 467 (2) The Registrar Server answers with a 200 OK message as shown 468 below: 470 SIP/2.0 200 OK 471 Call-ID: a8a83b610ae5d242289dfc1c78b7f1d8@example.com 472 CSeq: 1830746365 REGISTER 473 From: DS ;tag=ed3833bd7363e68 474 To: DS ;tag=3ab7fe89d998709 475 Via:SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bK00e31d6ed 476 Content-Length: 0 477 Contact: DS 478 ;atypes="ipv4,ipv6";expires=900 480 6. IANA Considerations 482 This specification adds a new media feature tag to the SIP Media 483 Feature Tag Registration Tree defined in RFC 3840 [RFC3840]. 485 Media feature tag name: sip.atypes 487 ASN.1 Identifier: TBD 489 Summary of the media feature indicated by this tag: The sip.atypes 490 media feature tag indicates whether a communications device supports 491 IPv4 for both signaling and media, IPv6 for both signaling and media, 492 IPv6 for signaling and IPv4 for media simultaneously, IPv4 for 493 signaling and IPv6 for media simultaneously. A plurality of tokens 494 is included for all the supported combinations. 496 Values appropriate for use with this feature tag: Token with an 497 equality relationship. 499 Typical values include: 501 ipv4: The device can support IPv4 addresses for both signaling and 502 media. 504 ipv6: The device can support IPv6 addresses for both signaling and 505 media. 507 The feature tag is intended primarily for use in the following 508 applications, protocols, services, or negotiation mechanisms: This 509 feature tag is most useful in a communications application, for 510 describing the capabilities of a device, such as a phone or PDA. 512 Examples of typical use: Optimally routing a session and ensuring 513 compatibility between IP versions to successfully establish sessions. 515 Related standards or documents: RFC XXXX [[Note to IANA: Please 516 replace XXXX with the RFC number of this specification.]]. 518 Security Considerations: Security considerations for this media 519 feature tag are discussed in Section 7 of RFC XXXX . [[Note to IANA: 520 Please replace XXXX with the RFC number of this specification.]] 522 7. Security Considerations 524 SIP-related security considerations are discussed in [RFC3261]. 526 When present in a SIP request or response, this media feature tag may 527 be used to determine whether a session is routed via a ALG/IPv4-IPv6 528 Interworking Function in order to successfully establish a session. 529 If the values of the atypes Media Feature Tags are modified by an 530 intermediary then it is possible that a session would fail to be 531 established if the modified values caused the network proxies to not 532 insert a ALG/IPv4-IPv6 Interworking Function when they are needed. 533 However if the contact address itself is also modified this could 534 also prevent a session being established. Integrity protection for 535 the Contact header field SHOULD be provided. 537 8. References 539 8.1. Normative References 541 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 542 Requirement Levels", BCP 14, RFC 2119, March 1997. 544 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 545 A., Peterson, J., Sparks, R., Handley, M., and E. 546 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 547 June 2002. 549 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 550 "Indicating User Agent Capabilities in the Session 551 Initiation Protocol (SIP)", RFC 3840, August 2004. 553 8.2. Informative References 555 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 556 Preferences for the Session Initiation Protocol (SIP)", 557 RFC 3841, August 2004. 559 [RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network 560 Address Types (ANAT) Semantics for the Session Description 561 Protocol (SDP) Grouping Framework", RFC 4091, June 2005. 563 [RFC4092] Camarillo, G. and J. Rosenberg, "Usage of the Session 564 Description Protocol (SDP) Alternative Network Address 565 Types (ANAT) Semantics in the Session Initiation Protocol 566 (SIP)", RFC 4092, June 2005. 568 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 569 (ICE): A Protocol for Network Address Translator (NAT) 570 Traversal for Offer/Answer Protocols", RFC 5245, April 571 2010. 573 [RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 574 Transition in the Session Initiation Protocol (SIP)", RFC 575 6157, April 2011. 577 [RFC6947] Boucadair, M., Kaplan, H., Gilman, R., and S. 578 Veikkolainen, "The Session Description Protocol (SDP) 579 Alternate Connectivity (ALTC) Attribute", RFC 6947, May 580 2013. 582 [TS.24229] 583 3GPP, "IP multimedia call control protocol based on 584 Session Initiation Protocol (SIP) and Session Description 585 Protocol (SDP); Stage 3", March 2013. 587 Authors' Addresses 589 Mohamed Boucadair 590 France Telecom 591 Rennes 35000 592 France 594 Email: mohamed.boucadair@orange.com 596 Andrew Allen 597 Blackberry 598 USA 600 Email: aallen@blackberry.com