idnits 2.17.1 draft-boucadair-mmusic-altc-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 24 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 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 (March 7, 2011) is 4799 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 510, but no explicit reference was found in the text == Unused Reference: 'RFC3388' is defined on line 515, but no explicit reference was found in the text == Unused Reference: 'RFC5234' is defined on line 531, 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 (-11) exists of draft-ietf-softwire-dual-stack-lite-07 Summary: 5 errors (**), 0 flaws (~~), 6 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: September 8, 2011 Acme Packet 6 R. Gilman 7 Independent 8 S. Veikkolainen 9 Nokia 10 March 7, 2011 12 Session Description Protocol (SDP) Alternate Connectivity (ALTC) 13 Attribute 14 draft-boucadair-mmusic-altc-02.txt 16 Abstract 18 This document proposes a mechanism which allows to carry multiple IP 19 addresses, of different address families (e.g., IPv4, IPv6), in the 20 same SDP offer. The proposed attribute solves the backward 21 compatibility problem which plagued ANAT, due to its syntax. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 8, 2011. 46 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.1. Overall Context . . . . . . . . . . . . . . . . . . . . . 4 77 1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 3. Overview of the ALTC Mechanism . . . . . . . . . . . . . . . . 7 81 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 3.2. Rationale for the Chosen Syntax . . . . . . . . . . . . . 8 83 4. Alternate Connectivity Attribute . . . . . . . . . . . . . . . 8 84 4.1. ALTC Syntax . . . . . . . . . . . . . . . . . . . . . . . 8 85 4.2. Usage and Interaction . . . . . . . . . . . . . . . . . . 10 86 4.2.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . 10 87 4.2.2. Usage of ALTC in an SDP Answer . . . . . . . . . . . . 11 88 4.2.3. Interaction with ICE . . . . . . . . . . . . . . . . . 11 89 4.2.4. Interaction with SDP-Cap-Neg . . . . . . . . . . . . . 11 90 5. The ALTC Option Tag . . . . . . . . . . . . . . . . . . . . . 11 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 93 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 94 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 95 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 98 1. Introduction 100 1.1. Overall Context 102 Due to the IPv4 address exhaustion problem, IPv6 deployment is 103 becoming an urgent need, along with the need to properly handle IPv6 104 and IPv4 co-existence. The reality of IPv4-IPv6 co-existence 105 introduces heterogeneous scenarios with combinations of IPv4 and IPv6 106 nodes, some of which are capable of supporting both IPv4 and IPv6 107 dual-stack (DS) and some of which are capable of supporting only IPv4 108 or only IPv6. In this context, Session Initiation Protocol (SIP) 109 User Agents (UAs) need to be able to indicate their available IP 110 capabilities in order to increase the ability to establish successful 111 SIP sessions, and also to avoid invocation of adaptation functions 112 such as Application Layer Gateways (ALGs) and IPv4-IPv6 113 interconnection functions (e.g., NAT64 114 [I-D.ietf-behave-v6v4-xlate-stateful]), and to avoid using private 115 IPv4 addresses through consumer NATs or Carrier Grade NATs (CGN). 117 In the meantime, service providers are investigating scenarios to 118 upgrade their service offering to be IPv6-capable. The current 119 strategies involve either offering IPv6 only, for example to mobile 120 devices, or providing both IPv4 and IPv6 but with private IPv4 121 addresses which are NAT'ed by CGNs. In the latter case the end 122 device may be using "normal" IPv4 and IPv6 stacks and interfaces, or 123 it may tunnel the IPv4 packets though a DS-Lite stack integrated into 124 the host; in either case the device has both address families 125 available from a SIP and media perspective. 127 Regardless of the IPv6 transition strategy being used, it is obvious 128 that there will be a need for dual-stack SIP devices to communicate 129 with IPv4-only legacy UAs, and IPv6-only UAs, and other dual-stack 130 UAs. It may not, for example, be possible for a dual-stack UA to 131 communicate with an IPv6-only UA unless the dual-stack UA had a means 132 of providing the IPv6-only UA with its IPv6 local address for media, 133 while clearly it needs to provide a legacy IPv4-only device its local 134 IPv4 address. The communication must be possible in a backwards- 135 compatible fashion, such that IPv4-only SIP devices need not support 136 the new mechanism to communicate with dual-stack UAs. 138 The current means by which multiple address families can be 139 communicated are through ANAT [RFC4091] or ICE [I-D.ietf-mmusic-ice]. 140 ANAT has serious backwards-compatibility problems as described in 141 [RFC4092], which effectively make it unusable, and it is planned to 142 be deprecated by the IETF. ICE at least allows interoperability with 143 legacy devices, by not doing ICE in such cases, but it is a 144 complicated and processing intensive mechanism, and has seen limited 145 deployment and implementation in SIP applications. In some 146 deployment models, ICE is not usable at all. 148 1.2. Purpose 150 This document proposes a new alternative: a backwards-compatible 151 syntax for indicating multiple media connection addresses and ports 152 in an SDP offer, which can immediately be selected from and used in 153 an SDP answer. 155 The proposed mechanism is independent of the model described in 156 [I-D.ietf-mmusic-sdp-capability-negotiation] and does not require 157 implementation of sdp-capabilities-negotiations (a.k.a., sdp-cap-neg) 158 to function. When sdp-cap-neg is supported, the CCAP attribute 159 defined in [I-D.garcia-mmusic-sdp-misc-cap] should be used. 161 It should be noted that "backwards-compatible" in this document 162 generally refers to working with legacy IPv4-only devices. The 163 choice has to be made, one way or the other, because to interoperate 164 with legacy devices requires constructing SDP bodies which they would 165 understand and support, such that they detect their local address 166 family in the SDP connection line. It is not possible to support 167 interworking with both legacy IPv4-only and legacy IPv6-only devices 168 with the same SDP offer. Clearly, there are far more legacy IPv4- 169 only devices in existence, and thus those are the ones assumed in 170 this document. However, the syntax allows for a UA to choose which 171 address family to be backwards-compatible with, in case it has some 172 means of determining it. 174 Furthermore, even for cases where both sides support the same address 175 family, there should be a means by which the "best" address family 176 transport is used, based on what the UAs decide. The address family 177 which is "best" for a particular session cannot always be known a 178 priori. For example, in some cases the IPv4 transport may be better, 179 even if both UAs support IPv6. 181 The proposed solution provides the following benefits: 183 o Allows a UA to signal more than one IP address (type) in the same 184 SDP offer/answer; 186 o Is backwards compatible. No parsing or semantic errors will be 187 experienced by a legacy UA or intermediary nodes (e.g., Proxy 188 Servers, Registrar Servers, etc.) which do not understand this new 189 mechanism; 191 o Is as lightweight as possible to achieve the goal, while still 192 allowing and interoperating with nodes which support other similar 193 or related mechanisms. 195 1.3. Scope 197 This document proposes an alternative scheme, as replacement to the 198 ANAT procedure, to carry several IP address types in the same SDP 199 offer/answer while preserving backward compatibility. 201 While clearly two UAs communicating directly at a SIP layer need to 202 be able to support the same address family for SIP itself, current 203 SIP deployments almost always have Proxy Servers or B2BUA's in the 204 SIP signaling path, which can provide the necessary interworking of 205 the IP address family at the SIP layer. SIP-layer address family 206 interworking is out of scope of this document (see 207 [I-D.boucadair-sipping-ipv6-atypes] for a solution candidate). 208 Instead, this document focuses on the problem of communicating 209 *media* address family capabilities in a backwards-compatible 210 fashion. Since media can go directly between two UAs, without a 211 priori knowledge by the UAC of which address family the far-end UAS 212 supports, it has to offer both, in a backwards-compatible fashion. 214 2. Use Cases 216 Although the ALTC mechanism defined in this document is meant for 217 general use, the following use cases were explicitly considered: 219 o A dual-stack UAC initiating a SIP session without knowing the 220 address family of the ultimate target UAS. 222 o A UA receiving a SIP session request with SDP offer and wishes to 223 avoid using IPv4, or to avoid IPv6. 225 o An IPv6-only UA wishes to avoid using a NAT64 226 [I-D.ietf-behave-v6v4-xlate-stateful]. 228 o A SIP UA behind a Dual-Stack Lite CGN 229 [I-D.ietf-softwire-dual-stack-lite]. 231 o A SIP Service Provider or Enterprise domain of IPv4-only and/or 232 IPv6-only UA, which provides interworking by invoking IPv4-IPv6 233 media relays, wishes to avoid invoking such functions and let 234 media go end-to-end as much as possible. 236 o A SIP Service Provider or Enterprise domain of a UA, which 237 communicates with other domains and wishes to either avoid 238 invoking IPv4-IPv6 interworking or let media go end-to-end as much 239 as possible. 241 o A SIP Service Provider providing transit peering services for SIP 242 sessions, which may need to modify SDP in order to provide IPv4- 243 IPv6 interworking, but would prefer to avoid such interworking or 244 avoid relaying media in general, as much as possible. 246 o SIP sessions using the new mechanism crossing legacy SDP-aware 247 middleboxes which may not understand this new mechanism. 249 3. Overview of the ALTC Mechanism 251 3.1. Overview 253 The ALTC mechanism relies solely on the SDP offer/answer mechanism, 254 with specific syntax to indicate alternative connection addresses. 255 The basic concept is to use a new SDP attribute "altc", to indicate 256 the IP addresses for potential alternative connection addresses. The 257 address which is most likely to get chosen for the session is in the 258 normal 'c=' line. Typically in current operational networks this 259 would be an IPv4 address. The "a=altc" lines contain, in preference 260 order, the alternative addresses offered for this session. This way, 261 a dual-stack UA might encode its IPv4 address in the "c=" line, while 262 possibly preferring to use an IPv6 address by indicating this by the 263 "a=altc" attribute line ordering. One of the "a=altc" lines 264 duplicates the address contained in the "c=" line, for reasons 265 explained in Section 3.2). The SDP answerer would indicate its 266 chosen address, by simply using that address family in the "c=" line 267 of its response. 269 An example of an SDP offer using this mechanism is as follows when 270 IPv4 is considered most likely to be used for the session, but IPv6 271 is preferred: 273 v=0 274 o=- 25678 753849 IN IP4 192.0.2.1 275 s= 276 c=IN IP4 192.0.2.1 277 t=0 0 278 m=audio 12340 RTP/AVP 0 8 279 a=altc IP6 2001:db8::1 45678 280 a=altc IP4 192.0.2.1 12340 282 If IPv6 was considered most likely to be used for the session, the 283 SDP offer would be as follows: 285 v=0 286 o=- 25678 753849 IN IP6 2001:db8::1 287 s= 288 c=IN IP6 2001:db8::1 289 t=0 0 290 m=audio 12340 RTP/AVP 0 8 291 a=altc IP6 2001:db8::1 45678 292 a=altc IP4 192.0.2.1 12340 294 Since an alternative address is likely to require an alternative TCP/ 295 UDP port number as well, the new "altc" attribute includes both an IP 296 address and a receive transport port number (or multiple port 297 numbers). The ALTC mechanism does not itself support offering a 298 different transport type (i.e., UDP vs. TCP), codec, nor any other 299 attribute. It is only intended for offering an alternative IP 300 address and port number. 302 3.2. Rationale for the Chosen Syntax 304 The use of an 'a=' attribute line is, according to [RFC4566], the 305 primary means for extending SDP and tailoring it to particular 306 applications or media. A compliant SDP parser will ignore any 307 session description that contains attribute lines it does not 308 support. 310 The rationale for encoding the same address and port in the "a=altc" 311 line as in the "m=" and "c=" lines is to provide detection of legacy 312 SDP-changing middleboxes. Such systems may change the connection 313 address and media transport port numbers, but not support this new 314 mechanism, and thus two UAs supporting this mechanism would try to 315 connect to the wrong addresses. Therefore, the rules detailed in 316 this document require the SDP processor to check for matching altc 317 and connection line addresses and media ports, before choosing one of 318 the alternatives. 320 4. Alternate Connectivity Attribute 322 4.1. ALTC Syntax 324 The altc attribute adheres to the RFC 4566 "attribute" production. 325 The ABNF syntax of altc is provided below: 327 altc-attr = "altc" att-value 328 att-value = addrtype SP connection-address SP port ["/" integer] ;defined in [RFC4566] 330 Figure 1: Connectivity Capability Attribute ABNF 332 The meaning of the fields are listed hereafter: 334 o addrtype: the addrtype field as defined in [RFC4566] for 335 connection data. 337 o connection-address: a network address as defined in [RFC4566] 338 corresponding to the address type specified by addrtype. 340 o port: the port number to be used, as defined in [RFC4566]. 341 Distinct port numbers may be used per IP address type. If the 342 specified address type does not require a port number, a value 343 defined for that address type should be used. 345 The "altc" attribute is only applicable in an SDP offer. The "altc" 346 attribute is a media-level-only attribute, and MUST NOT appear at the 347 SDP session level (since it defines a port number, it is inherently 348 tied to the media level). There MUST NOT be more than one "altc" 349 attribute per addrtype within each media description. This 350 restriction is necessary in order that the addrtype of the reply may 351 be used by the offerer to determine which alternative was accepted. 353 The 's of the altc MUST correspond to the of the 354 current connection (c=) line. 356 A media description MUST contain at least two "altc" attributes: the 357 alternative address and port as well as an address and port which 358 "duplicates" the address/port information from the current 'c=' and 359 'm=' lines. Each media level MUST contain at least one such 360 duplicate altc attribute, of the same IP address family, address, and 361 transport port number as those in the SDP connection and media lines 362 of its level. In particular, if a 'c=' line appears within a media 363 description, the addr-type and connection-address from that 'c=' line 364 MUST be used in the duplicate "altc" attribute for that media 365 description. If a 'c=' line appears only at the session level and a 366 given media description does not have its own connection line, then 367 the duplicate "altc" attribute for that media description MUST be the 368 same as the session-level address information. 370 The "altc" attributes appearing within a media description MUST be 371 prioritized in order of appearance, with the first altc given highest 372 priority and the following altc attributes prioritized in decending 373 order. Given this rule, and the requirement that the address 374 information provided in the "m=" line and "o=" line must be provided 375 in an "altc" attribute as well, it is possible that the address in 376 the "m=" line and "o=" line are not the preferred choice. 378 If the addrtype of an "altc" attribute is not compatible with the 379 transport protocol or media format specified in the media 380 description, that altc attribute MUST be ignored. 382 Note that "a=altc" lines describe alternative connection addresses, 383 NOT addresses for parallel connections. When several altc lines are 384 present, multiple sessions establishment MUST be avoided. Only one 385 session is to be maintained with the remote party for the associated 386 media description. 388 4.2. Usage and Interaction 390 4.2.1. Usage 392 In an SDP offer/answer model, the SDP offer includes "altc" 393 attributes to indicate alternative connection information (i.e., 394 address type, address and port number(s)), including the "duplicate" 395 connection information already identified in the 'c=' and 'm=' lines. 397 Additional, subsequent offers MAY include "altc" attributes again, 398 and may change the IP address, port numbers, and order of preference; 399 but they MUST include a duplicate "altc" attribute for the connection 400 and media lines in that specific subsequent offer. In other words, 401 every offered SDP media description with an alternative address offer 402 with an "altc" attribute has at least two of them: 404 - one duplicating the 'c=' and 'm=' line information for that 405 media description, and 407 - one for each of the alternatives, 409 even though these need not be the same as the original SDP offer. 411 The purpose of encoding a duplicate "altc" attribute is to allow 412 receivers of the SDP offer to detect if a legacy SDP-changing middle 413 box has modified the 'c=' and/or 'm=' line address/port information. 414 If the SDP answerer does not find a duplicate "altc" attribute value 415 for which the address and port match exactly those in the 'c=' line 416 and 'm=' line, the SDP answerer MUST ignore the "altc" attributes and 417 use the 'c=' and 'm=' offered address/ports for the entire SDP 418 instead, as if no "altc" attributes were present. The rationale for 419 this is that many SDP-changing middleboxes will end the media 420 sessions if they do not detect media flowing through them; if a 421 middlebox modified the SDP addresses, media MUST be sent using the 422 modified information. 424 Note that for RTCP, if applicable for the given media types, each 425 side would act as if the chosen "altc" attribute's port number was in 426 the 'm=' media line. Typically, this would mean RTCP is sent to the 427 odd +1 of the port number, unless some other attribute determines 428 otherwise. 430 4.2.2. Usage of ALTC in an SDP Answer 432 The SDP answer SHOULD NOT contain "altc" attributes, as the answer's 433 'c=' line implicitly and definitively chooses the address family from 434 the offer and includes it in "c=" and "m=" lines of the answer. 435 Furthermore, this avoids establishing several sessions simultaneously 436 between the participating peers. 438 Any solution requiring the use of ALTC in SDP answer SHOULD document 439 its usage, in particular how sessions are established between the 440 participating peers. 442 4.2.3. Interaction with ICE 444 Since ICE also includes address and port number information in its 445 candidate attributes, a potential problem arises: which one wins. 446 Since ICE also includes specific ICE attributes in the SDP answer, 447 the problem is easily avoided: if the SDP offerer supports both ALTC 448 and ICE, it may include both sets of attributes in the same SDP 449 offer. A legacy ICE-only answerer will simply ignore the ALTC 450 attributes, and use ICE. An ALTC-only answerer will ignore the ICE 451 attributes and reply without them. An answerer which supports both 452 MUST choose one and only one of the mechanisms to use: either ICE or 453 ALTC (unless the 'm=' or 'c=' lines were changed by a middlebox, in 454 which case the rules for both ALTC and ICE would make the answerer 455 revert to basic SDP semantics). 457 4.2.4. Interaction with SDP-Cap-Neg 459 The ALTC mechanism is orthogonal to sdp-cap-neg. If the offerer 460 supports both ALTC and sdp-cap-neg, it may offer both. 462 A method based on sdp-cap-neg is described in 463 [I-D.garcia-mmusic-sdp-misc-cap] and may be used to specify different 464 connectivity for alternative configurations. 466 5. The ALTC Option Tag 468 This document defines a new SIP option-tag for use in the "Supported" 469 SIP header field called "altc". This option-tag is for the purpose 470 of indicating that a UA supports the ALTC mechanism defined in this 471 document AND actually has multiple address family addresses 472 available, in order to improve troubleshooting, and in some cases 473 provide a hint to other nodes that the UA is capable of both IPv4 and 474 IPv6 and ALTC. 476 A UA MUST NOT include this option tag unless it both (1) supports the 477 ALTC mechanism AND (2) has both an IPv4 and IPv6 address available 478 for media use. The reason it only includes the "altc" option-tag if 479 it actually has both addresses, is that having only a single address 480 family available implies the UA cannot truly perform ALTC in an 481 offer; it may have the necessary logic to, but it does not have the 482 addresses to do so. (remember one does not include the "altc" 483 attribute in SDP unless one has both address families available) 485 A UA SHOULD include the ALTC option-tag in a "Supported" SIP header 486 field in SIP REGISTER, OPTIONS, and INVITE requests and related 487 responses, if it has both address-family addresses available and 488 supports the ALTC mechanism. A UA MUST NOT include the ALTC option- 489 tag in the "Require" or "Proxy-Require" SIP header fields under any 490 conditions. 492 6. IANA Considerations 494 If this document moves forward, it requests a new SDP attribute name 495 "altc", as defined earlier; and a new SIP option-tag be reserved, 496 named "altc", for the purposes described earlier. 498 7. Security Considerations 500 The security implications for ALTC are effectively the same as they 501 are for SDP in general [RFC4566]. 503 8. References 505 8.1. Normative References 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, March 1997. 510 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 511 A., Peterson, J., Sparks, R., Handley, M., and E. 512 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 513 June 2002. 515 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 516 Schulzrinne, "Grouping of Media Lines in the Session 517 Description Protocol (SDP)", RFC 3388, December 2002. 519 [RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network 520 Address Types (ANAT) Semantics for the Session Description 521 Protocol (SDP) Grouping Framework", RFC 4091, June 2005. 523 [RFC4092] Camarillo, G. and J. Rosenberg, "Usage of the Session 524 Description Protocol (SDP) Alternative Network Address 525 Types (ANAT) Semantics in the Session Initiation Protocol 526 (SIP)", RFC 4092, June 2005. 528 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 529 Description Protocol", RFC 4566, July 2006. 531 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 532 Specifications: ABNF", STD 68, RFC 5234, January 2008. 534 8.2. Informative References 536 [I-D.boucadair-sipping-ipv6-atypes] 537 Boucadair, M., Noisette, Y., and A. Allen, "The atypes 538 media feature tag for Session Initiation Protocol (SIP)", 539 draft-boucadair-sipping-ipv6-atypes-02 (work in progress), 540 July 2009. 542 [I-D.garcia-mmusic-sdp-misc-cap] 543 Garcia, M., Veikkolainen, S., and R. Gilman, 544 "Miscellaneous Capabilities Negotiation in the Session 545 Description Protocol (SDP)", 546 draft-garcia-mmusic-sdp-misc-cap-01 (work in progress), 547 July 2009. 549 [I-D.ietf-behave-v6v4-xlate-stateful] 550 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 551 NAT64: Network Address and Protocol Translation from IPv6 552 Clients to IPv4 Servers", 553 draft-ietf-behave-v6v4-xlate-stateful-12 (work in 554 progress), July 2010. 556 [I-D.ietf-mmusic-ice] 557 Rosenberg, J., "Interactive Connectivity Establishment 558 (ICE): A Protocol for Network Address Translator (NAT) 559 Traversal for Offer/Answer Protocols", 560 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 562 [I-D.ietf-mmusic-sdp-capability-negotiation] 563 Andreasen, F., "SDP Capability Negotiation", 564 draft-ietf-mmusic-sdp-capability-negotiation-13 (work in 565 progress), March 2010. 567 [I-D.ietf-softwire-dual-stack-lite] 568 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 569 Stack Lite Broadband Deployments Following IPv4 570 Exhaustion", draft-ietf-softwire-dual-stack-lite-07 (work 571 in progress), March 2011. 573 Authors' Addresses 575 Mohamed Boucadair 576 France Telecom 577 3, Av Francois Chateau 578 Rennes 35000 579 France 581 Email: mohamed.boucadair@orange-ftgroup.com 583 Hadriel Kaplan 584 Acme Packet 585 71 Third Ave. 586 Burlington, MA 01803 587 USA 589 Email: hkaplan@acmepacket.com 591 Robert R Gilman 592 Independent 594 Email: bob_gilman@comcast.net 595 URI: 597 Simo Veikkolainen 598 Nokia 600 Email: Simo.Veikkolainen@nokia.com 601 URI: