idnits 2.17.00 (12 Aug 2021) /tmp/idnits15569/draft-boucadair-mmusic-ccap-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 is 1 instance of too long lines in the document, the longest one being 26 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 06, 2009) is 4695 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) == Unused Reference: 'RFC3261' is defined on line 483, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3388 (Obsoleted by RFC 5888) ** Obsolete normative reference: RFC 4091 (Obsoleted by RFC 5245) ** Obsolete normative reference: RFC 4092 (Obsoleted by RFC 5245) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-02) exists of draft-boucadair-sipping-ipv6-atypes-01 == Outdated reference: draft-ietf-mmusic-ice has been published as RFC 5245 == Outdated reference: draft-ietf-mmusic-sdp-capability-negotiation has been published as RFC 5939 Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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 H. Kaplan 5 Expires: January 7, 2010 Acme Packet 6 July 06, 2009 8 Session Description Protocol (SDP) Connectivity Capability (CCAP) 9 Attribute 10 draft-boucadair-mmusic-ccap-00.txt 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. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 7, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This memo proposes a mechanism which allows to carry multiple IP 49 addresses, of different address families (e.g., IPv4, IPv6), in the 50 same SDP offer/answer. The proposed attribute solves the backward 51 compatibility problem which plagued ANAT, due to its syntax. 53 Requirements Language 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC 2119 [RFC2119]. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Overall Context . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Overview of the CCAP Mechanism . . . . . . . . . . . . . . . . 6 67 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 7 69 4. Connectivity Capability Attribute . . . . . . . . . . . . . . 7 70 4.1. CCAP Syntax . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.2. Usage and Interaction . . . . . . . . . . . . . . . . . . 8 72 4.2.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . 8 73 4.2.2. Interaction with ICE . . . . . . . . . . . . . . . . . 9 74 4.2.3. Interaction with SDP-Cap-Neg . . . . . . . . . . . . . 10 75 5. The CCAP Option Tag . . . . . . . . . . . . . . . . . . . . . 10 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 81 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 82 Appendix A. ANAT and ICE . . . . . . . . . . . . . . . . . . . . 12 83 A.1. ANAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 A.2. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 [Editorial Note: this section is lengthy/verbose, and is here simply 90 to provide some initial background. This section, as well as 91 Appendix-A, will be removed or at least reduced after initial draft 92 versions.] 94 1.1. Overall Context 96 Due to the IPv4 address exhaustion problem, IPv6 deployment is 97 becoming an urgent need, along with the need to properly handle IPv6 98 and IPv4 co-existence. The reality of IPv4-IPv6 co-existence 99 introduces heterogeneous scenarios with combinations of IPv4 and IPv6 100 nodes, some of which are capable of supporting both IPv4 and IPv6 101 dual-stack (DS) and some of which are capable of supporting only IPv4 102 or only IPv6. In this context, SIP User Agents (UAs) need to be able 103 to indicate their available IP capabilities in order to increase the 104 ability to establish successful SIP sessions, and also to avoid 105 invocation of adaptation functions such as ALGs and NAT64, and to 106 avoid using private IPv4 addresses through consumer NATs or Carrier- 107 Grade NATs (CG-NAT). 109 In the meantime, service providers are investigating scenarios to 110 upgrade their service offering to be IPv6-capable. The current 111 strategies involve either offering IPv6 only, for example to mobile 112 devices, or providing both IPv4 and IPv6 but with private IPv4 113 addresses which are NAT'ed by CG-NATs. In the latter case the end 114 device may be using "normal" IPv4 and IPv6 stacks and interfaces, or 115 it may tunnel the IPv4 packets though a DS-Lite stack integrated into 116 the host; in either case the device has both address families 117 available from a SIP and media perspective. 119 Regardless of the IPv6-transition strategy being used, it is obvious 120 that there will be a need for dual-stack SIP devices to communicate 121 with IPv4-only legacy UAs, and IPv6-only UAs, and other dual-stack 122 UAs. It may not, for example, be possible for a dual-stack UA to 123 communicate with an IPv6-only UA unless the dual-stack UA had a means 124 of providing the IPv6-only UA with its IPv6 local address for media, 125 while clearly it needs to provide a legacy IPv4-only device its local 126 IPv4 address. The communication must be possible in a backwards- 127 compatible fashion, such that IPv4-only SIP devices need not support 128 the new mechanism to communicate with dual-stack UAs. 130 The current means by which multiple address families can be 131 communicated are through ANAT [RFC4091] or ICE [I-D.ietf-mmusic-ice]. 132 ANAT has serious backwards-compatibility problems as described in 133 [RFC4092], which effectively make it unusable, and it is planned to 134 be deprecated by the IETF. ICE at least allows interoperability with 135 legacy devices, by not doing ICE in such cases, but it is a 136 complicated and processing intensive mechanism, and has seen limited 137 deployment and implementation in SIP applications. In some 138 deployment models, ICE is not usable at all. Further details of why 139 neither model is appropriate are described in Appendix A. 141 1.2. Purpose 143 This document proposes a new alternative: a backwards-compatible 144 syntax for indicating multiple media connection addresses and ports 145 in an SDP offer, which can immediately be selected from and used in 146 an SDP answer. 148 The proposed mechanism (called ccap) follows the model described in 149 [I-D.ietf-mmusic-sdp-capability-negotiation] in syntax, but does not 150 propose a full implementation of sdp-capabilities-negotiations 151 (a.k.a., sdp-cap-neg) to function. If the full model is implemented, 152 the mechanism proposed in this memo works with it as well, but 153 orthogonally. The mechanism is an alternative to ICE, such that both 154 mechanisms may be offered, but only one is chosen and used. 156 It should be noted that "backwards-compatible" in this document 157 generally refers to working with legacy IPv4-only devices. The 158 choice has to be made, one way or the other, because to interoperate 159 with legacy devices requires constructing SDP bodies which they would 160 understand and support, such that they detect their local address 161 family in the SDP connection line. It is not possible to support 162 interworking with both legacy IPv4-only and legacy IPv6-only devices 163 with the same SDP offer. Clearly, there are far more legacy IPv4- 164 only devices in existence, and thus those are the ones assumed in 165 this document. However, the syntax allows for a UA to choose which 166 address family to be backwards-compatible with, in case it has some 167 means of determining it. [Note: though this may be considered odd, 168 it is technically and practically possible for certain devices to 169 know such a thing in real-world deployments] 171 Furthermore, even for cases where both sides support the same address 172 family, there should be a means by which the "best" address family 173 transport is used, based on what the UAs decide. Which address 174 family is "best" for a particular session is not defineable a priori. 175 For example, in some cases the IPv4 transport may be better, even if 176 both UAs support IPv6. 178 The proposed solution provides the following benefits: 180 o Allows a UA to signal more than one IP address (type) in the same 181 SDP offer/answer; 183 o Is backwards compatible. No parsing or semantic errors will be 184 experienced by a legacy UA or intermediary nodes (e.g., Proxy 185 Servers, Registrar Servers, etc.) which do not understand this new 186 mechanism; 188 o Is as lightweight as possible to achieve the goal, while still 189 allowing and interoperating with nodes which support other similar 190 or related mechanisms. 192 1.3. Scope 194 This document proposes an alternative scheme, as replacement to the 195 ANAT procedure, to carry several IP address types in the same SDP 196 offer/answer while preserving backward compatibility. 198 While clearly two UAs communicating directly at a SIP layer need to 199 be able to support the same address family for SIP itself, current 200 SIP deployments almost always have Proxy Servers or B2BUA's in the 201 SIP signaling path, which can provide the necessary interworking of 202 the IP address family at the SIP layer. SIP-layer address family 203 interworking is out of scope of this document (see 204 [I-D.boucadair-sipping-ipv6-atypes] for a solution candidate). 205 Instead, this document focuses on the problem of communicating 206 *media* address family capabilities in a backwards-compatible 207 fashion. Since media can go directly between two UAs, without a 208 priori knowledge by the UAC of which address family the far-end UAS 209 supports, it has to offer both, in a backwards-compatible fashion. 211 2. Use Cases 213 Although the CCAP mechanism defined in this document is meant for 214 general use, the following use cases were explicitly considered: 216 o A dual-stack UAC initiating a SIP session without knowing the 217 address family of the ultimate target UAS. 219 o A UA receiving a SIP session request with SDP offer and wishes to 220 avoid using IPv4, or to avoid IPv6. 222 o An IPv6-only UA wishes to avoid using a NAT64. 224 o A SIP Service Provider or Enterprise domain of IPv4-only and/or 225 IPv6-only UA, which provides interworking by invoking IPv4-IPv6 226 media relays, wishes to avoid invoking such functions and let 227 media go end-to-end as much as possible. 229 o A SIP Service Provider or Enterprise domain of a UA, which 230 communicates with other domains and wishes to either avoid 231 invoking IPv4-IPv6 interworking or let media go end-to-end as much 232 as possible. 234 o A SIP Service Provider providing transit peering services for SIP 235 sessions, which may need to modify SDP in order to provide IPv4- 236 IPv6 interworking, but would prefer to avoid such interworking or 237 avoid relaying media in general, as much as possible. 239 o SIP sessions using the new mechanism crossing legacy SDP-aware 240 middleboxes which may not understand this new mechanism. 242 3. Overview of the CCAP Mechanism 244 3.1. Overview 246 The CCAP mechanism relies solely on the SDP offer/answer mechanism, 247 with specific syntax to indicate capabilities. Following the sdp- 248 cap-neg model, the basic concept is to use a new SDP attribute 249 "ccap", to indicate the IP addresses for potential alternative 250 connection addresses, while using the most likely-to-succeed address 251 in the normal 'c=' connection line. Typically this would be an IPv4 252 address, however the new attribute also indicate if another address 253 is more preferred. For example, a dual-stack UA might encode its 254 IPv4 in the connection line, while possibly preferring to use an IPv6 255 address by indicating such in the attributes (though, it actually 256 encodes both addresses in the attributes, for reasons explained 257 later). The SDP answerer would indicate its chosen address, by 258 simply using that address family in the SDP connection line of its 259 response. 261 An example of SDP offer using this mechanism is as follows: 263 v=0 264 o=- 25678 753849 IN IP4 192.0.2.1 265 s= 266 c=IN IP4 192.0.2.1 267 t=0 0 268 m=audio 12340 RTP/AVP 0 8 269 a=ccap:1 IP6 2001:db8::1 45678 270 a=ccap:2 IP4 192.0.2.1 12340 272 Since an alternative address is likely to require an alternative TCP/ 273 UDP port number as well, the new attribute includes both an IP 274 address and a receive transport port number. The CCAP mechanism does 275 not itself support offering a different transport type (i.e., UDP vs. 277 TCP), codec, nor any other attribute. It is only intended for 278 offering an alternative IP address and port number. The syntax of 279 the attributes follows sdp-cap-neg and ICE in some regards, but does 280 not require support for either of them. Other mechanisms, such as 281 sdp-cap-neg, may be used at the same time to offer other alternative 282 semantics, but they are orthogonal to the address and port 283 alternatives in this memo. 285 3.2. Rationale 287 The use of an 'a=' attribute line is, according to [RFC4566], the 288 primary means for extending SDP and tailoring it to particular 289 applications or media. An SDP parser will ignore any session 290 description that contains attribute lines it does not support. 291 [Note: of course some devices in the wild may not ignore unknown 292 attributes, but then it is not compliant with SDP rules, and nothing 293 will help it] 295 The rationale for encoding the same address/port as in the media and 296 connection lines is to provide detection of legacy SDP-changing 297 middleboxes. Such systems may change the connection address and 298 media transport port numbers, but not support this new mechanism, and 299 thus two UAs supporting this mechanism would try to connect to the 300 wrong addresses. Therefore, the rules detailed in this document 301 require the SDP processor to check for matching ccap and connection 302 line addresses and media ports, before choosing one of the 303 alternatives. 305 4. Connectivity Capability Attribute 307 4.1. CCAP Syntax 309 The ccap attribute adheres to the RFC 4566 "attribute" production. 310 The ABNF syntax of ccap is provided below: 312 ccap-attr = "ccap" ":" att-value 313 att-value = addr-cap-num SP addrtype SP connection-address SP port ;defined in [RFC4566] 314 addr-cap-num = 1*DIGIT ;defined in [RFC5234] 316 Figure 1: Connectivity Capability Attribute ABNF 318 Note that white space is not permitted before the addr-cap-num. 320 The meaning of the fields are listed hereafter: 322 o addr-cap-num: digit to uniquely refer to an address alternative. 323 It must be in preference order (1=most-preferred). 325 o addrtype: the addrtype field as defined in [RFC4566] for 326 connection data. 328 o connection-address: an IPv4 or IPv6 address as defined in 329 [RFC4566]. 331 o port: the port number to be used, as defined in [RFC4566]. 332 Distinct port numbers may be used per IP address type. 334 The ccap attribute is only applicable in an SDP offer. The ccap 335 attribute MUST NOT appear at the SDP session level (since it defines 336 a port number, it is inherently tied to the media level). There MUST 337 NOT be more than one ccap attribute per IP Address family, per media 338 level. Each and every media level MUST contain exactly two ccap 339 attributes: one for one address family, and a second for the other. 341 This document's mechanism requires a "duplicate" ccap attribute to be 342 included, with the same address/port information as in the RFC 4566 343 base SDP 'c=' connection and 'm=' media lines. Each media level MUST 344 contain at least one such duplicate ccap attribute, of the same IP 345 address family, address, and transport port number as those in the 346 SDP connection and media lines of its level. 348 If a 'c=' connection line appears at the media level, the same 349 address as that 'c=' line MUST be used in the duplicate ccap 350 attribute for that media level. 352 If a 'c=' connection line appears only at the session level and a 353 given media line does not have its own connection line, then the 354 duplicate ccap attribute for that media line MUST be the same as the 355 session-level address information. 357 When several ccap lines are present, multiple sessions establishment 358 MUST be avoided. Only one session is to be maintained with remote 359 party. 361 4.2. Usage and Interaction 363 4.2.1. Usage 365 In an SDP offer/answer model, the SDP offer would include ccap 366 attributes to indicate alternative connection information (i.e., 367 address family, address and port number), as well as the "duplicate" 368 connection information already identified in the 'c=' connection and 369 'm=' media lines. The SDP answer MUST NOT contain ccap attributes, 370 as the answer's 'c=' line implicitly and definitively "chooses" the 371 address family from the offer. 373 Additional, subsequent offers MAY include ccap attributes again, and 374 change the IP address, ports, and order of preference; but they MUST 375 include a duplicate ccap attribute of the connection and media lines 376 in that specific subsequent offer. In other words, every SDP offer 377 with a ccap attribute has two of them: 379 - one duplicating the 'c=' and 'm=' line information in that SDP 380 offer, and 382 - one for the alternative, even though both of those need not be 383 the same as the original SDP offer. 385 The purpose of encoding a "duplicate" ccap attribute is to allow 386 receivers of the SDP offer to detect if a legacy SDP-changing middle 387 box has modified the 'c=' and/or 'm=' line address/port information. 388 If the SDP answerer does not find a duplicate ccap attribute value 389 for which the address and port match exactly those in the 'c=' line 390 and 'm=' line, the SDP answerer MUST ignore the ccap attributes and 391 use the 'c=' and 'm=' offered address/ports for the entire SDP 392 instead, as if no ccap attributes were present. The rationale for 393 this is that many SDP-changing middleboxes will end the SIP session 394 if they do not detect media flowing through them; if a middlebox 395 modified the SDP, media MUST be sent using the modified information. 397 Note that for RTCP, if applicable for the given media types, each 398 side would act as if the chosen ccap attribute's port number was in 399 the 'm=' media line. Typically, this would mean RTCP is sent to the 400 odd +1 of the port number, unless some other attribute determines 401 otherwise. 403 4.2.2. Interaction with ICE 405 Since ICE also includes address and port number information in its 406 candidate attributes, a potential problem arises: which one wins. 407 Since ICE also includes specific ICE attributes in the SDP answer, 408 the problem is easily avoided: if the SDP offerer supports both CCAP 409 and ICE, it may include both sets of attributes in the same SDP 410 offer. A legacy ICE-only answerer will simply ignore the CCAP 411 attributes, and use ICE. A CCAP-only answerer will ignore the ICE 412 attributes and reply without them. An answerer which supports both 413 MUST choose one and only one of the mechanisms to use: either ICE or 414 CCAP (unless the 'm=' or 'c=' lines were changed by a middlebox, in 415 which case the rules for both CCAP and ICE would make the answerer 416 revert to basic SDP semantics). 418 4.2.3. Interaction with SDP-Cap-Neg 420 The CCAP mechanism is orthogonal to sdp-cap-neg. If the offerer 421 supports both ccap and sdp-cap-neg, it may offer both. At this time, 422 sdp-cap-neg does not provide a means of offering alternative 423 addresses/ports, other than through ICE, for which the behavior was 424 described previously. Therefore, there is no conflicting 425 interaction. CCAP capabilities are not negotiated as part of the 426 potential and actual configuration attribute syntax and semantics 427 defined in [I-D.ietf-mmusic-sdp-capability-negotiation]. 429 [Note: it was tempting to in fact make CCAP be yet another set of 430 alternative capabilities in an sdp-cap-neg, but the complexities of 431 sdp-cap-neg, and the subtleties of potentially tying address/port 432 options with media capabilities do not seem to be worth the effort 433 for this case] 435 5. The CCAP Option Tag 437 This document defines a new SIP option-tag for use in the "Supported" 438 SIP header field called "ccap". This option-tag is for the purpose 439 of indicating that a UA supports the CCAP mechanism defined in this 440 document AND actually has multiple address family addresses 441 available, in order to improve troubleshooting, and in some cases 442 provide a hint to other nodes that the UA is capable of both IPv4 and 443 IPv6 and CCAP. 445 A UA MUST NOT include this option tag unless it both (1) supports the 446 CCAP mechanism AND (2) has *both* an IPv4 and IPv6 address available 447 for media use. The reason it only includes the ccap option-tag if it 448 actually has both addresses, is that having only a single address 449 family available implies the UA cannot truly perform CCAP in an 450 offer; it may have the necessary logic to, but it does not have the 451 addresses to do so. (remember one does not include the ccap attribute 452 in SDP unless one has both address families available) 454 A UA SHOULD include the CCAP option-tag in a "Supported" SIP header 455 field in SIP REGISTER, OPTIONS, and INVITE requests and related 456 responses, if it has both address-family addresses available and 457 supports the CCAP mechanism. A UA MUST NOT include the CCAP option- 458 tag in the "Require" or "Proxy-Require" SIP header fields under any 459 conditions. 461 6. IANA Considerations 463 If this document moves forward, it requests a new SDP attribute name 464 "ccap", as defined earlier; and a new SIP option-tag be reserved, 465 named "ccap", for the purposes described earlier. 467 7. Security Considerations 469 The security implications for CCAP are effectively the same as they 470 are for SDP in general. 472 8. Acknowledgements 474 TBC 476 9. References 478 9.1. Normative References 480 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 481 Requirement Levels", BCP 14, RFC 2119, March 1997. 483 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 484 A., Peterson, J., Sparks, R., Handley, M., and E. 485 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 486 June 2002. 488 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 489 Schulzrinne, "Grouping of Media Lines in the Session 490 Description Protocol (SDP)", RFC 3388, December 2002. 492 [RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network 493 Address Types (ANAT) Semantics for the Session Description 494 Protocol (SDP) Grouping Framework", RFC 4091, June 2005. 496 [RFC4092] Camarillo, G. and J. Rosenberg, "Usage of the Session 497 Description Protocol (SDP) Alternative Network Address 498 Types (ANAT) Semantics in the Session Initiation Protocol 499 (SIP)", RFC 4092, June 2005. 501 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 502 Description Protocol", RFC 4566, July 2006. 504 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 505 Specifications: ABNF", STD 68, RFC 5234, January 2008. 507 9.2. Informative References 509 [I-D.boucadair-sipping-ipv6-atypes] 510 Boucadair, M., Noisette, Y., and A. Allen, "The atypes 511 media feature tag for Session Initiation Protocol (SIP)", 512 draft-boucadair-sipping-ipv6-atypes-01 (work in progress), 513 March 2009. 515 [I-D.ietf-mmusic-ice] 516 Rosenberg, J., "Interactive Connectivity Establishment 517 (ICE): A Protocol for Network Address Translator (NAT) 518 Traversal for Offer/Answer Protocols", 519 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 521 [I-D.ietf-mmusic-sdp-capability-negotiation] 522 Andreasen, F., "SDP Capability Negotiation", 523 draft-ietf-mmusic-sdp-capability-negotiation-10 (work in 524 progress), May 2009. 526 Appendix A. ANAT and ICE 528 A.1. ANAT 530 [RFC4091] describes a mechanism allowing multiple alternative network 531 addresses to be enclosed in a single SDP offer/answer. This proposal 532 consists at introducing a new attribute called ANAT (Alternative 533 Network Address Types). ANAT is based on media grouping [RFC3388]. 534 ANAT specification lists IP address as an example of Network Address 535 (without providing other examples). 537 This attribute allows inserting multiple media/connection lines in 538 the same SDP offer (or SDP answer). [RFC4092] defines how SIP can 539 exploit the ANAT semantic by introducing a new option tag called 540 "sdp-anat". This tag can be useful for SIP UAs to be aware of the 541 capabilities of each other and then select from the supported media/ 542 network description lines the ones that are suitable for setting up 543 the SIP communication (and also according to local preferences). A 544 use case for illustrating the usage of this tag is a Dual Stack SIP 545 UA which can communicate either using its IPv6 or its IPv4 546 connectivity. This type of SIP UAs can also set a preference 547 associated with each type of enclosed connectivity type. 549 [RFC4092] states that answerers without support for ANAT will react 550 in different ways upon receipt of an offer using ANAT and different 551 implementations will behave in different ways. This issue is a real 552 problem in current operational SIP-based service offerings. Indeed, 553 in order to support IPv6 is SIP-based architectures, several 554 scenarios may be envisaged. The most pragmatic one is to update the 555 access segment to support IPv6. The support of ANAT is such 556 situations would encounter backward compatibility issues since core 557 service nodes are not ANAT-compliant. This limitation may be a 558 hurdle for the use of IPv6 and particularly to activate policies to 559 encourage the usage of IPv6 and to guarantee successful 560 communications involving heterogeneous (i.e. IPv4 and IPv6) parties. 562 Unfortunately, even with the sdp-anat option tag addition, ANAT is 563 not truly usable in modern SIP usage. In most SIP usage today, the 564 SIP UAC generates the SDP offer in its initial INVITE request. Since 565 it does not know the capabilities of the ultimate far-end UAS, it 566 cannot include ANAT syntax in its SDP due to the backwards- 567 compatibility problem. Inserting an sdp-anat option tag in the 568 Require header would lead to numerous failed INVITE attempts. 569 Inserting it in the Supported header would only allow it to re- 570 negotiate SDP using ANAT afterwards, which would lead to failed 571 initial INVITE requests if it chose to offer an address family 572 initially that the far-end could not support . Neither case is 573 attractive, and in particular failed INVITE attempts are highly 574 undesirable if not outright unacceptable, leaving the UAC with no 575 choice but to either send an offer-less INVITE, or simply assume 576 IPv4. Assuming IPv4 does not solve the address transition problem, 577 as it would require all devices to continue to use IPv4 indefinitely, 578 and offer-less INVITEs have well-known interoperability problems in 579 practice. 581 Note that ANAT specification is to be deprecated by ICE 582 [I-D.ietf-mmusic-ice]. 584 A.2. ICE 586 ICE solves the IPv4-v6 SDP offer problem by having the UAC offer both 587 addresses as alternative candidates in the SDP offer. If the far-end 588 UAS supports ICE, it can choose among them; else it will simply use 589 the one offered in the normal SDP connection line. If ICE is 590 supported, STUN connectivity checks are performed, in a controlled 591 fashion, along with an additional round of SDP negotiation for the 592 final chosen connection path. 594 This solves the problem of backwards-compatibility, but at a heavy 595 price: both sides must implement ICE. While ICE provides other 596 benefits, specifically basic NAT traversal without the aid of 597 middleboxes other than TURN servers, it is complicated and difficult 598 to troubleshoot. It is a very high bar to place on SIP UAs, just to 599 achieve IP address family negotiation. What's needed is as simple a 600 mechanism as possible to achieve the goals, in order to provide 601 reasonable chance of widespread adoption and deployment. 603 Furthermore, ICE does not work in some scenarios. In particular, it 604 does not work when the address(es) are determined based on where the 605 SIP session "goes". ICE assumes there may be many layers of NAT, but 606 that they all cascade from a private to public side, towards the 607 public Internet, and assume that both SIP UAs (ICE clients) can 608 obtain addresses in the public Internet (e.g., through TURN servers), 609 which can be used as a last resort point of media packet rendezvous. 610 Such is not always the case. For example, in common SIP Provider 611 peering arrangements, a SIP UAC is in a private network of one 612 Provider and the UAS in a private network of the other Provider, and 613 media communication does not and cannot cross the public Internet. 614 Multi-hop transit peering cases exacerbate this issue even further. 615 The only devices with knowledge of the correct addresses to use in 616 such scenarios are middleboxes, and they do not know the addresses 617 until the SIP session is initially signaled (and in fact the 618 addresses may change during the session's lifetime). 620 For the sole purpose of negotiating IP address families, therefore, 621 ICE is neither necessary nor sufficient. 623 Authors' Addresses 625 Mohamed Boucadair 626 France Telecom 627 3, Av Francois Chateau 628 Rennes 35000 629 France 631 Email: mohamed.boucadair@orange-ftgroup.com 633 Hadriel Kaplan 634 Acme Packet 635 71 Third Ave. 636 Burlington, MA 01803 637 USA 639 Email: hkaplan@acmepacket.com