idnits 2.17.1 draft-boucadair-mmusic-altc-09.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 10 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 (January 29, 2013) is 4076 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-06) exists of draft-ietf-mboned-64-multicast-address-format-04 == Outdated reference: A later version (-07) exists of draft-ietf-mboned-multrans-addr-acquisition-01 == Outdated reference: A later version (-04) exists of draft-ietf-mboned-v4v6-mcast-ps-01 -- 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: 2 errors (**), 0 flaws (~~), 4 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: Informational H. Kaplan 5 Expires: August 2, 2013 Acme Packet 6 R. Gilman 7 Independent 8 S. Veikkolainen 9 Nokia 10 January 29, 2013 12 Session Description Protocol (SDP) Alternate Connectivity (ALTC) 13 Attribute 14 draft-boucadair-mmusic-altc-09 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 (Alternative Network Address 22 Types), due to its syntax. 24 The proposed solution is applicable to scenarios where connectivity 25 checks are not required. If connectivity checks are required, ICE 26 (RFC 5245) provides such a solution. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 2, 2013. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Overall Context . . . . . . . . . . . . . . . . . . . . . 4 69 1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3. Overview of the ALTC Mechanism . . . . . . . . . . . . . . . . 7 73 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.2. Rationale for the Chosen Syntax . . . . . . . . . . . . . 8 75 4. Alternate Connectivity Attribute . . . . . . . . . . . . . . . 8 76 4.1. ALTC Syntax . . . . . . . . . . . . . . . . . . . . . . . 8 77 4.2. Usage and Interaction . . . . . . . . . . . . . . . . . . 10 78 4.2.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . 10 79 4.2.2. Usage of ALTC in an SDP Answer . . . . . . . . . . . . 11 80 4.2.3. Interaction with ICE . . . . . . . . . . . . . . . . . 11 81 4.2.4. Interaction with SDP-Cap-Neg . . . . . . . . . . . . . 12 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 87 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 88 Appendix A. ALTC Use Cases . . . . . . . . . . . . . . . . . . . 15 89 A.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 15 90 A.2. Multicast Use Case . . . . . . . . . . . . . . . . . . . . 16 91 A.3. Introducing IPv6 into SIP-based Architectures . . . . . . 17 92 A.3.1. Avoid Crossing CGN Devices . . . . . . . . . . . . . . 17 93 A.3.2. Basic Scenario for IPv6 SIP Service Delivery . . . . . 17 94 A.3.3. Avoid IPv4/IPv6 Interworking . . . . . . . . . . . . . 18 95 A.3.4. DBE Bypass Procedure . . . . . . . . . . . . . . . . . 20 96 A.3.5. Direct Communications Between IPv6-enabled User 97 Agents . . . . . . . . . . . . . . . . . . . . . . . . 22 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 100 1. Introduction 102 1.1. Overall Context 104 Due to the IPv4 address exhaustion problem, IPv6 deployment is 105 becoming an urgent need, along with the need to properly handle IPv6 106 and IPv4 co-existence. The reality of IPv4-IPv6 co-existence 107 introduces heterogeneous scenarios with combinations of IPv4 and IPv6 108 nodes, some of which are capable of supporting both IPv4 and IPv6 109 dual-stack (DS) and some of which are capable of supporting only IPv4 110 or only IPv6. In this context, Session Initiation Protocol (SIP 111 [RFC3261]) User Agents (UAs) need to be able to indicate their 112 available IP capabilities in order to increase the ability to 113 establish successful SIP sessions, and also to avoid invocation of 114 adaptation functions such as Application Layer Gateways (ALGs) and 115 IPv4-IPv6 interconnection functions (e.g., NAT64 [RFC6146]), and to 116 avoid using private IPv4 addresses through consumer NATs or Carrier 117 Grade NATs (CGN, [I-D.ietf-behave-lsn-requirements]). 119 In the meantime, service providers are investigating scenarios to 120 upgrade their service offering to be IPv6-capable. The current 121 strategies involve either offering IPv6 only, for example to mobile 122 devices, or providing both IPv4 and IPv6 but with private IPv4 123 addresses which are NAT'ed by CGNs. In the latter case the end 124 device may be using "normal" IPv4 and IPv6 stacks and interfaces, or 125 it may tunnel the IPv4 packets though a DS-Lite stack integrated into 126 the host [RFC6333]; in either case the device has both address 127 families available from a SIP and media perspective. 129 Regardless of the IPv6 transition strategy being used, it is obvious 130 that there will be a need for dual-stack SIP devices to communicate 131 with IPv4-only legacy UAs, and IPv6-only UAs, and other dual-stack 132 UAs. It may not, for example, be possible for a dual-stack UA to 133 communicate with an IPv6-only UA unless the dual-stack UA had a means 134 of providing the IPv6-only UA with its IPv6 local address for media, 135 while clearly it needs to provide a legacy IPv4-only device its local 136 IPv4 address. The communication must be possible in a backwards- 137 compatible fashion, such that IPv4-only SIP devices need not support 138 the new mechanism to communicate with dual-stack UAs. 140 The current means by which multiple address families can be 141 communicated are through ANAT [RFC4091] or ICE [RFC5245]. ANAT has 142 serious backwards-compatibility problems as described in [RFC4092], 143 which effectively make it unusable, and it is deprecated by the IETF 144 [RFC5245]. ICE at least allows interoperability with legacy devices, 145 by not doing ICE in such cases, but it is a complicated and 146 processing intensive mechanism, and has seen limited deployment and 147 implementation in SIP applications. 149 ALTC has been implemented as reported in 150 [I-D.boucadair-pcp-nat64-experiments]; no issue has been reported in 151 that document. 153 1.2. Purpose 155 This document proposes a new alternative: a backwards-compatible 156 syntax for indicating multiple media connection addresses and ports 157 in an SDP offer, which can immediately be selected from and used in 158 an SDP answer. 160 The proposed mechanism is independent of the model described in 161 [RFC5939] and does not require implementation of sdp-capabilities- 162 negotiations (a.k.a., SDPCapNeg) to function. 164 It should be noted that "backwards-compatible" in this document 165 generally refers to working with legacy IPv4-only devices. The 166 choice has to be made, one way or the other, because to interoperate 167 with legacy devices requires constructing SDP bodies which they would 168 understand and support, such that they detect their local address 169 family in the SDP connection line. It is not possible to support 170 interworking with both legacy IPv4-only and legacy IPv6-only devices 171 with the same SDP offer. Clearly, there are far more legacy IPv4- 172 only devices in existence, and thus those are the ones assumed in 173 this document. However, the syntax allows for a UA to choose which 174 address family to be backwards-compatible with, in case it has some 175 means of determining it. 177 Furthermore, even for cases where both sides support the same address 178 family, there should be a means by which the "best" address family 179 transport is used, based on what the UAs decide. The address family 180 which is "best" for a particular session cannot always be known a 181 priori. For example, in some cases the IPv4 transport may be better, 182 even if both UAs support IPv6. 184 The proposed solution provides the following benefits: 186 o Allows a UA to signal more than one IP address (type) in the same 187 SDP offer/answer; 188 o Is backwards compatible. No parsing or semantic errors will be 189 experienced by a legacy UA or intermediary SIP nodes which do not 190 understand this new 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; 194 o Is easily deployable in managed networks; 195 o Requires minimal increase of the length of the SDP offer (I.e., 196 minimizes fragmentation risks). 198 ALTC may also be useful for the multicast context (e.g., Section 3.4 199 of [I-D.venaas-behave-v4v6mc-framework] or Section 3.3 of 200 [I-D.ietf-mboned-multrans-addr-acquisition]). 202 More detailed information about ALTC use cases is provided in 203 Appendix A. 205 1.3. Scope 207 This document proposes an alternative scheme, as replacement to the 208 ANAT procedure [RFC4091], to carry several IP address types in the 209 same SDP offer/answer while preserving backward compatibility. 211 While clearly two UAs communicating directly at a SIP layer need to 212 be able to support the same address family for SIP itself, current 213 SIP deployments almost always have Proxy Servers or B2BUA's in the 214 SIP signaling path, which can provide the necessary interworking of 215 the IP address family at the SIP layer (e.g., [RFC6157]). SIP-layer 216 address family interworking is out of scope of this document. 217 Instead, this document focuses on the problem of communicating media 218 address family capabilities in a backwards-compatible fashion. Since 219 media can go directly between two UAs, without a priori knowledge by 220 the UAC of which address family the far-end UAS supports, it has to 221 offer both, in a backwards-compatible fashion. 223 2. Use Cases 225 The ALTC mechanism defined in this document is primary meant for 226 managed networks. In particular, the following use cases were 227 explicitly considered: 229 o A dual-stack UAC initiating a SIP session without knowing the 230 address family of the ultimate target UAS. 231 o A UA receiving a SIP session request with SDP offer and wishes to 232 avoid using IPv4, or to avoid IPv6. 233 o An IPv6-only UA wishes to avoid using a NAT64 [RFC6146]. 234 o A SIP UA behind a Dual-Stack Lite CGN [RFC6333]. 235 o A SIP Service Provider or Enterprise domain of IPv4-only and/or 236 IPv6-only UA, which provides interworking by invoking IPv4-IPv6 237 media relays, wishes to avoid invoking such functions and let 238 media go end-to-end as much as possible. 239 o A SIP Service Provider or Enterprise domain of a UA, which 240 communicates with other domains and wishes to either avoid 241 invoking IPv4-IPv6 interworking or let media go end-to-end as much 242 as possible. 243 o A SIP Service Provider providing transit peering services for SIP 244 sessions, which may need to modify SDP in order to provide IPv4- 245 IPv6 interworking, but would prefer to avoid such interworking or 246 avoid relaying media in general, as much as possible. 247 o SIP sessions using the new mechanism crossing legacy SDP-aware 248 middleboxes which may not understand this new mechanism. 250 3. Overview of the ALTC Mechanism 252 3.1. Overview 254 The ALTC mechanism relies solely on the SDP offer/answer mechanism, 255 with specific syntax to indicate alternative connection addresses. 256 The basic concept is to use a new SDP attribute "altc", to indicate 257 the IP addresses for potential alternative connection addresses. The 258 address which is most likely to get chosen for the session is in the 259 normal 'c=' line. Typically in current operational networks this 260 would be an IPv4 address. The "a=altc" lines contain the alternative 261 addresses offered for this session. This way, a dual-stack UA might 262 encode its IPv4 address in the "c=" line, while possibly preferring 263 to use an IPv6 address by explicitly indicating the preference order 264 in the corresponding "a=altc" line. One of the "a=altc" lines 265 duplicates the address contained in the "c=" line, for reasons 266 explained in Section 3.2). The SDP answerer would indicate its 267 chosen address, by simply using that address family in the "c=" line 268 of its response. 270 An example of an SDP offer using this mechanism is as follows when 271 IPv4 is considered most likely to be used for the session, but IPv6 272 is preferred: 274 v=0 275 o=- 25678 753849 IN IP4 192.0.2.1 276 s= 277 c=IN IP4 192.0.2.1 278 t=0 0 279 m=audio 12340 RTP/AVP 0 8 280 a=altc:1 IP6 2001:db8::1 45678 281 a=altc:2 IP4 192.0.2.1 12340 283 If IPv6 was considered most likely to be used for the session, the 284 SDP offer would be as follows: 286 v=0 287 o=- 25678 753849 IN IP6 2001:db8::1 288 s= 289 c=IN IP6 2001:db8::1 290 t=0 0 291 m=audio 45678 RTP/AVP 0 8 292 a=altc:1 IP6 2001:db8::1 45678 293 a=altc:2 IP4 192.0.2.1 12340 295 Since an alternative address is likely to require an alternative TCP/ 296 UDP port number as well, the new "altc" attribute includes both an IP 297 address and a receive transport port number (or multiple port 298 numbers). The ALTC mechanism does not itself support offering a 299 different transport type (i.e., UDP vs. TCP), codec, nor any other 300 attribute. It is only intended for offering an alternative IP 301 address and port number. 303 3.2. Rationale for the Chosen Syntax 305 The use of an 'a=' attribute line is, according to [RFC4566], the 306 primary means for extending SDP and tailoring it to particular 307 applications or media. A compliant SDP parser will ignore the 308 unsupported attribute lines. 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 [RFC4566] "attribute" production. 325 The ABNF syntax [RFC5234] of altc is provided below: 327 altc-attr = "altc" ":" att-value 328 att-value = altc-num SP addrtype SP connection-address SP port ["/" rtcp-port] 329 altc-num = 1*DIGIT 330 rtcp-port = port 331 Figure 1: Connectivity Capability Attribute ABNF 333 The meaning of the fields are listed hereafter: 335 o altc-num: digit to uniquely refer to an address alternative. It 336 must be in preference order; "1" indicates the most preferred 337 address. 338 o addrtype: the addrtype field as defined in [RFC4566] for 339 connection data. 340 o connection-address: a network address as defined in [RFC4566] 341 corresponding to the address type specified by addrtype. 342 o port: the port number to be used, as defined in [RFC4566]. 343 Distinct port numbers may be used per IP address type. If the 344 specified address type does not require a port number, a value 345 defined for that address type should be used. 346 o rtcp-port: Including an RTCP port is optional. An RTCP port may 347 be indicated in the alternative "c=" line when the RTCP port can 348 not be derived from the RTP port. 350 The "altc" attribute is only applicable in an SDP offer. The "altc" 351 attribute is a media-level-only attribute, and MUST NOT appear at the 352 SDP session level (since it defines a port number, it is inherently 353 tied to the media level). There MUST NOT be more than one "altc" 354 attribute per addrtype within each media description. This 355 restriction is necessary in order that the addrtype of the reply may 356 be used by the offerer to determine which alternative was accepted. 358 The 's of the altc MUST correspond to the of the 359 current connection (c=) line. 361 A media description MUST contain two "altc" attributes: the 362 alternative address and an alternative port as well as an address and 363 port which "duplicates" the address/port information from the current 364 'c=' and 'm=' lines. Each media level MUST contain at least one such 365 duplicate altc attribute, of the same IP address family, address, and 366 transport port number as those in the SDP connection and media lines 367 of its level. In particular, if a 'c=' line appears within a media 368 description, the addr-type and connection-address from that 'c=' line 369 MUST be used in the duplicate "altc" attribute for that media 370 description. If a 'c=' line appears only at the session level and a 371 given media description does not have its own connection line, then 372 the duplicate "altc" attribute for that media description MUST be the 373 same as the session-level address information. 375 The "altc" attributes appearing within a media description MUST be 376 prioritized; the explicit preference order is indicated in each line 377 ("1" is used to indicate the address with the highest priority). 378 Given this rule, and the requirement that the address information 379 provided in the "m=" line and "o=" line must be provided in an "altc" 380 attribute as well, it is possible that the address in the "m=" line 381 and "o=" line are not the preferred choice. 383 If the addrtype of an "altc" attribute is not compatible with the 384 transport protocol or media format specified in the media 385 description, that altc attribute MUST be ignored. 387 Note that "a=altc" lines describe alternative connection addresses, 388 NOT addresses for parallel connections. When several altc lines are 389 present, multiple sessions establishment MUST be avoided. Only one 390 session is to be maintained with the remote party for the associated 391 media description. 393 If no port number is indicated for the alternative address, the same 394 port number is used for all address families. 396 4.2. Usage and Interaction 398 4.2.1. Usage 400 In an SDP offer/answer model, the SDP offer includes "altc" 401 attributes to indicate alternative connection information (i.e., 402 address type, address and port number(s)), including the "duplicate" 403 connection information already identified in the 'c=' and 'm=' lines. 405 Additional, subsequent offers MAY include "altc" attributes again, 406 and may change the IP address, port numbers, and order of preference; 407 but they MUST include a duplicate "altc" attribute for the connection 408 and media lines in that specific subsequent offer. In other words, 409 every offered SDP media description with an alternative address offer 410 with an "altc" attribute has two of them: 412 - one duplicating the 'c=' and 'm=' line information for that 413 media description, and 414 - one for the alternative, 416 even though these need not be the same as the original SDP offer. 418 The purpose of encoding a duplicate "altc" attribute is to allow 419 receivers of the SDP offer to detect if a legacy SDP-changing middle 420 box has modified the 'c=' and/or 'm=' line address/port information. 421 If the SDP answerer does not find a duplicate "altc" attribute value 422 for which the address and port match exactly those in the 'c=' line 423 and 'm=' line, the SDP answerer MUST ignore the "altc" attributes and 424 use the 'c=' and 'm=' offered address/ports for the entire SDP 425 instead, as if no "altc" attributes were present. The rationale for 426 this is that many SDP-changing middleboxes will end the media 427 sessions if they do not detect media flowing through them; if a 428 middlebox modified the SDP addresses, media MUST be sent using the 429 modified information. 431 Note that for RTCP, if applicable for the given media types, each 432 side would act as if the chosen "altc" attribute's port number was in 433 the 'm=' media line. Typically, this would mean RTCP is sent to the 434 odd +1 of the port number, unless some other attribute determines 435 otherwise. For example the RTP/RTCP multiplexing mechanism defined 436 in [RFC5761] can still be used with ALTC, such that if both sides 437 support multiplexing they will indicate so using the 'a=rtcp-mux' 438 attribute as defined in [RFC5761]; but the IP connection address and 439 port they use may be chosen using the ALTC mechanism. 441 If the SDP offerer wishes to use the RTCP attribute defined in 442 [RFC3605], a complication can arise since it may not be clear which 443 address choice the 'a=rtcp' attribute applies to, relative the 444 choices offered by ALTC. Technically RFC 3605 allows indicating the 445 address for RTCP explicitly in the 'a=rtcp' attribute itself, but 446 this is optional and rarely used. For this reason, this document 447 recommends using 'a=rtcp' attribute to be for the address choice 448 encoded in the "m=" line, and include an alternate RTCP port in the 449 'a=altc' attribute corresponding to the alternative address. In 450 other words, if the 'a=rtcp' attribute explicitly encodes an address 451 in its attribute, then that applies for ALTC as per [RFC3605]; if it 452 does not, then ALTC assumes the 'a=rtcp' attribute is for the address 453 in the "m=" line, and the alternative "altc" attribute include an 454 RTCP alternate port number. 456 4.2.2. Usage of ALTC in an SDP Answer 458 The SDP answer SHOULD NOT contain "altc" attributes, as the answer's 459 'c=' line implicitly and definitively chooses the address family from 460 the offer and includes it in "c=" and "m=" lines of the answer. 461 Furthermore, this avoids establishing several sessions simultaneously 462 between the participating peers. 464 Any solution requiring the use of ALTC in SDP answer SHOULD document 465 its usage, in particular how sessions are established between the 466 participating peers. 468 4.2.3. Interaction with ICE 470 Since ICE [RFC5245] also includes address and port number information 471 in its candidate attributes, a potential problem arises: which one 472 wins. Since ICE also includes specific ICE attributes in the SDP 473 answer, the problem is easily avoided: if the SDP offerer supports 474 both ALTC and ICE, it may include both sets of attributes in the same 475 SDP offer. A legacy ICE-only answerer will simply ignore the ALTC 476 attributes, and use ICE. An ALTC-only answerer will ignore the ICE 477 attributes and reply without them. An answerer which supports both 478 MUST choose one and only one of the mechanisms to use: either ICE or 479 ALTC (unless the 'm=' or 'c=' lines were changed by a middlebox, in 480 which case the rules for both ALTC and ICE would make the answerer 481 revert to basic SDP semantics). 483 4.2.4. Interaction with SDP-Cap-Neg 485 The ALTC mechanism is orthogonal to SDPCapNeg [RFC5939]. If the 486 offerer supports both ALTC and SDPCapNeg, it may offer both. 488 5. IANA Considerations 490 This document requests the following new SDP attribute: 492 SDP Attribute ("att-field"): 494 Attribute name altc 495 Long form Alternate Connectivity 496 Type of name att-field 497 Type of attribute Media level only 498 Subject to charset No 499 Purpose See Section 1.2, Section 3 500 Specification Section 4 502 The contact person for this registration is Mohamed Boucadair (email: 503 mohamed.boucadair@orange.com; phone: +33 2 99 12 43 71). 505 6. Security Considerations 507 The security implications for ALTC are effectively the same as they 508 are for SDP in general [RFC4566]. 510 7. Acknowledgements 512 Many thanks to T. Taylor, F. Andreasen and G. Camarillo for their 513 review and comments. 515 8. References 516 8.1. Normative References 518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 519 Requirement Levels", BCP 14, RFC 2119, March 1997. 521 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 522 A., Peterson, J., Sparks, R., Handley, M., and E. 523 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 524 June 2002. 526 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 527 in Session Description Protocol (SDP)", RFC 3605, 528 October 2003. 530 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 531 Description Protocol", RFC 4566, July 2006. 533 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 534 Specifications: ABNF", STD 68, RFC 5234, January 2008. 536 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 537 Control Packets on a Single Port", RFC 5761, April 2010. 539 8.2. Informative References 541 [I-D.boucadair-pcp-nat64-experiments] 542 Abdesselam, M., Boucadair, M., Hasnaoui, A., and J. 543 Queiroz, "PCP NAT64 Experiments", 544 draft-boucadair-pcp-nat64-experiments-00 (work in 545 progress), September 2012. 547 [I-D.ietf-behave-lsn-requirements] 548 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 549 and H. Ashida, "Common requirements for Carrier Grade NATs 550 (CGNs)", draft-ietf-behave-lsn-requirements-10 (work in 551 progress), December 2012. 553 [I-D.ietf-mboned-64-multicast-address-format] 554 Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and 555 M. Xu, "IPv6 Multicast Address With Embedded IPv4 556 Multicast Address", 557 draft-ietf-mboned-64-multicast-address-format-04 (work in 558 progress), August 2012. 560 [I-D.ietf-mboned-multrans-addr-acquisition] 561 Tsou, T., Clauberg, A., Boucadair, M., Venaas, S., and Q. 562 Sun, "Address Acquisition For Multicast Content When 563 Source and Receiver Support Differing IP Versions", 564 draft-ietf-mboned-multrans-addr-acquisition-01 (work in 565 progress), January 2013. 567 [I-D.ietf-mboned-v4v6-mcast-ps] 568 Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., Tsou, T., 569 and Q. Sun, "IPv4-IPv6 Multicast: Problem Statement and 570 Use Cases", draft-ietf-mboned-v4v6-mcast-ps-01 (work in 571 progress), November 2012. 573 [I-D.venaas-behave-v4v6mc-framework] 574 Venaas, S., Li, X., and C. Bao, "Framework for IPv4/IPv6 575 Multicast Translation", 576 draft-venaas-behave-v4v6mc-framework-03 (work in 577 progress), June 2011. 579 [RFC2871] Rosenberg, J. and H. Schulzrinne, "A Framework for 580 Telephony Routing over IP", RFC 2871, June 2000. 582 [RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network 583 Address Types (ANAT) Semantics for the Session Description 584 Protocol (SDP) Grouping Framework", RFC 4091, June 2005. 586 [RFC4092] Camarillo, G. and J. Rosenberg, "Usage of the Session 587 Description Protocol (SDP) Alternative Network Address 588 Types (ANAT) Semantics in the Session Initiation Protocol 589 (SIP)", RFC 4092, June 2005. 591 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 592 (ICE): A Protocol for Network Address Translator (NAT) 593 Traversal for Offer/Answer Protocols", RFC 5245, 594 April 2010. 596 [RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, 597 A., and M. Bhatia, "Requirements from Session Initiation 598 Protocol (SIP) Session Border Control (SBC) Deployments", 599 RFC 5853, April 2010. 601 [RFC5939] Andreasen, F., "Session Description Protocol (SDP) 602 Capability Negotiation", RFC 5939, September 2010. 604 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 605 NAT64: Network Address and Protocol Translation from IPv6 606 Clients to IPv4 Servers", RFC 6146, April 2011. 608 [RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 609 Transition in the Session Initiation Protocol (SIP)", 610 RFC 6157, April 2011. 612 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 613 Stack Lite Broadband Deployments Following IPv4 614 Exhaustion", RFC 6333, August 2011. 616 [RFC6406] Malas, D. and J. Livingood, "Session PEERing for 617 Multimedia INTerconnect (SPEERMINT) Architecture", 618 RFC 6406, November 2011. 620 Appendix A. ALTC Use Cases 622 A.1. Terminology 624 The following terms are used: 625 o SBE (Signaling Path Border Element) denotes a functional element, 626 located at the boundaries of an ITAD (IP Telephony Administrative 627 Domain, [RFC2871]), which is responsible for intercepting 628 signaling flows received from User Agents and relay them to the 629 core service platform. A SBE may be located at the access segment 630 (i.e., be the service contact point for User Agents) or be located 631 at the interconnection with adjacent domains ([RFC6406]). A SBE 632 controls one or more DBEs. SBE and DBE may be located in the same 633 device (e.g., SBC [RFC5853]) or be separated. 634 o DBE (Data Path Border Element) denotes a functional element, 635 located at the boundaries of an ITAD, which is responsible for 636 intercepting media/data flows received from User Agents and relay 637 them to another DBE (or media servers, e.g., announcement server 638 or IVR). An example of DBE is a media gateway intercepting RTP 639 flows. SBE may be located at the access segment (i.e., be the 640 service contact point for User Agents) or be located at the 641 interconnection with adjacent domains ([RFC6406]). 642 o Core service platform is a macro functional block including 643 session routing, interfaces to advanced services and access 644 control. Figure 2 provides an overview of the overall 645 architecture including SBE, DBE and Core service platform. 647 +----------+ 648 | Core SIP | 649 +--------->| SPF |<---------+ 650 | SIP +----------+ SIP | 651 v v 652 +-----------+ +-----------+ 653 +-----+ SIP | SBE | | SBE | SIP 654 | S |<----->| | | |<-----> 655 | I | +-----------+ +-----------+ 656 | P | || || 657 | | +-----------+ +-----------+ 658 | U | RTP | DBE | RTP | DBE | RTP 659 | A |<----->| |<----------------->| | <-----> 660 +-----+ +-----------+ +-----------+ 662 SIP UA can be embedded in the CPE or in a host behind the CPE 664 Figure 2: Service Architecture: Overview 666 A.2. Multicast Use Case 668 Recently, a significant effort has been undertaken within IETF to 669 specify new mechanisms to interconnect IPv6-only hosts to IPv4-only 670 servers (e.g., [RFC6146]). This effort covered exclusively unicast 671 transfer mode. An ongoing initiative, called multrans, has been 672 launched to cover multicast issues to be encountered during IPv6 673 transition. The overall problem statement is documented in 674 [I-D.ietf-mboned-v4v6-mcast-ps]. 676 A particular issue encountered in the context of IPv4/IPv6 co- 677 existence and IPv6 transition of multicast services is the discovery 678 of multicast group and source (refer to Section 3.4 of 679 [I-D.ietf-mboned-v4v6-mcast-ps]): 681 1. An IPv6-only receiver requesting multicast content generated by 682 an IPv4-only source: 683 (1.1) An ALG is required to help an IPv6 receiver to select the 684 appropriate IP address when only the IPv4 address is 685 advertised (e.g., using SDP); otherwise the access to the 686 IPv4 multicast content can not be offered to the IPv6 687 receiver. The ALG may be located downstream the receiver. 688 As such, the ALG does not know in advance whether the 689 receiver is dual-stack or IPv6-only. The ALG may be tuned 690 to insert both the original IPv4 address and corresponding 691 IPv6 multicast address using for instance the ALTC SDP 692 attribute. 694 (1.2) In order to avoid involving an ALG in the path, an IPv4- 695 only source can advertise both its IPv4 address and IPv4- 696 embedded IPv6 multicast address 697 [I-D.ietf-mboned-64-multicast-address-format] using for 698 instance the ALTC SDP attribute. 699 2. A dual-stack source sending its multicast content over IPv4 and 700 IPv6: both IPv4 and IPv6 addresses need to be inserted in the SDP 701 part. A means (e.g, ALTC) is needed for this purpose. 703 A.3. Introducing IPv6 into SIP-based Architectures 705 A.3.1. Avoid Crossing CGN Devices 707 Some service providers are in the process of enabling DS-Lite 708 [RFC6333] as a means to continue delivering IPv4 services to their 709 customers. To avoiding crossing four levels of NAT when placing a 710 media session (2 NAT in DS-Lite AFTR + 2 NAT in the DBE), it is 711 recommended to enable IPv6 functions in some SBEs/DBEs. Therefore 712 DS-Lite AFTRs won't be crossed for DS-Lite serviced customers if 713 their UA is IPv6-enabled: 715 o For SIP UA embedded in the CPE, this is easy to implement since 716 the SIP UA [RFC3261] can be tuned to behave as IPv6-only UA when 717 DS-Lite is enabled. No ALTC is required for that use case. 718 o But for SIP User Agents located behind the CPE, a solution to 719 indicate both IPv4 and IPv6 (e.g., ALTC) is required in order to 720 avoid crossing the DS-Lite CGN. 722 A.3.2. Basic Scenario for IPv6 SIP Service Delivery 724 A basic solution to deliver SIP-based services using IPv4-only core 725 service platform to IPv6-enabled UA is to enabled IPv4/IPv6 726 interworking function in SBE/DBE. Signaling and media between two 727 SBEs and DBEs is maintained over IPv4. IPv6 is used between an IPv6- 728 enabled UA and a SBE/DBE. 730 Figure 3 shows the results of session establishment between UAs. In 731 this scenario, IPv4/IPv6 interworking function is invoked even when 732 both involved UAs are IPv6-enabled. 734 +----------+ 735 | Core SIP | 736 +--->|SPF (IPv4)|<---+ 737 IPv4 SIP | +----------+ |IPv4 SIP 738 v v 739 +-----------+ +-----------+ 740 | SBE | | SBE | SIP 741 +------->|IPv4/v6 IWF| | |<-------+ 742 |IPv6 +-----------+ +-----------+ IPv4| 743 | SIP SIP| 744 +----+ | +-----------+ +-----------+ | +----+ 745 |IPv6|-+IPv6 RTP| DBE |IPv4 RTP| DBE |IPv4 RTP+-|IPv4| 746 | UA |<-------->|IPv4/v6 IWF|<------>| |<-------->| UA | 747 +----+ +-----------+ +-----------+ +----+ 749 +----------+ 750 | Core SIP | 751 +--->|SPF (IPv4)|<---+ 752 IPv4 SIP | +----------+ |IPv4 SIP 753 v v 754 +-----------+ +-----------+ 755 | SBE | | SBE | SIP 756 +------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+ 757 |IPv6 +-----------+ +-----------+ IPv6| 758 | SIP SIP| 759 +----+ | +-----------+ +-----------+ | +----+ 760 |IPv6|-+IPv6 RTP| DBE |IPv4 RTP| DBE |IPv6 RTP+-|IPv6| 761 | UA |<-------->|IPv4/v6 IWF|<------>|IPv4/v6 IWF|<-------->| UA | 762 +----+ +-----------+ +-----------+ +----+ 764 Figure 3: Basic scenario 766 Solutions to avoid redundant IPv4/IPv6 NAT and involving several DBEs 767 may be valuable to consider by service providers. 769 A.3.3. Avoid IPv4/IPv6 Interworking 771 For services providers wanting: 772 1. Means to promote the invocation of IPv6 transfer capabilities can 773 be enabled while no parsing error is to be experienced by core 774 service nodes legacy nodes 775 2. Optimize cost related to IPv4-IPv6 translation licenses 776 3. Reduce the dual-stack lifetime 777 4. Maintain an IPv4-only core 778 5. Only a set of SBE/DBE are IPv6-enabled 780 A solution to indicate both IPv4 and IPv6 addresses is required. 781 This section provides an overview of this procedure: 783 When a SBE receives an INVITE, it instantiates in its DBE an IPv6- 784 IPv6 context and an IPv6-IPv4 context. Both an IPv6 address and an 785 IPv4 address are returned together with other information such as 786 port numbers. SBE builds an SDP offer including both IPv4 and IPv6- 787 related information using ALTC attribute. IPv6 is indicated as 788 preferred connectivity type. 790 o=- 25678 753849 IN IP4 192.0.2.2 791 c=IN IP4 192.0.2.2 792 m=audio 12340 RTP/AVP 0 8 793 a=altc:1 IP6 2001:db8::2 6000 794 a=altc:2 IP4 192.0.2.2 12340 796 Figure 4: SDP offer updated by the SBE 798 The request is then forwarded to the core SPF which in its turn 799 forwards the requests to the terminating SBE. 801 o If this SBE is a legacy one, then it will ignore ALTC attributes 802 and use "c" line. 803 o If the terminating SBE is IPv6-enabled: 804 * If the called UA is IPv4-only, then an IPv6-IPv4 context is 805 created in the corresponding DBE. 806 * If the called UA is IPv6-enabled, then an IPv6-IPv6 context is 807 created in the corresponding DBE. 809 Figure 5 shows the result of the procedure when placing a session 810 between an IPv4 and IPv6 UAs while Figure 6 shows the results of 811 establishing a session between two IPv6-enabled UAs. The result is 812 still not optima since redundant NAT66 is required (Appendix A.3.4). 814 +----------+ 815 | Core SIP | 816 +--->|SPF (IPv4)|<---+ 817 IPv4 SIP | +----------+ |IPv4 SIP 818 v v 819 +-----------+ +-----------+ 820 | SBE | | SBE | SIP 821 +------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+ 822 |IPv6 +-----------+ +-----------+ IPv4| 823 | SIP SIP| 824 +----+ | +-----------+ +-----------+ | +----+ 825 |IPv6|-+IPv6 RTP| DBE |IPv6 RTP| DBE |IPv4 RTP+-|IPv4| 826 | UA |<-------->| NAT66 |<------>|IPv4/v6 IWF|<-------->| UA | 827 +----+ +-----------+ +-----------+ +----+ 828 2001:db8::2 830 Figure 5: Session establishement between IPv4 and IPv6 UAs 832 +----------+ 833 | Core SIP | 834 +--->|SPF (IPv4)|<---+ 835 IPv4 SIP | +----------+ |IPv4 SIP 836 v v 837 +-----------+ +-----------+ 838 | SBE | | SBE | SIP 839 +------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+ 840 |IPv6 +-----------+ +-----------+ IPv6| 841 | SIP SIP| 842 +----+ | +-----------+ +-----------+ | +----+ 843 |IPv6|-+IPv6 RTP| DBE |IPv6 RTP| DBE |IPv6 RTP+-|IPv6| 844 | UA |<-------->| NAT66 |<------>| NAT66 |<-------->| UA | 845 +----+ +-----------+ +-----------+ +----+ 846 2001:db8::2 848 Figure 6: Session establishement between IPv6 UAs 850 A.3.4. DBE Bypass Procedure 852 For service providers wanting to involve only one DBE in the media 853 path, when not all SBE/DBE and UAs are IPv6-enabled, a means to 854 indicate both IPv4 and IPv6 addresses without inducing session 855 failures is required. Below is proposed an example of a proposed 856 procedure using ALTC attribute. 858 When the originating SBE receives an INVITE from an IPv6-enabled UA, 859 it instantiates in its DBE an IPv6-IPv6 context and an IPv6-IPv4 860 context. Both an IPv6 address and an IPv4 address are returned 861 together with other information such as port numbers. SBE builds an 862 SDP offer including both IPv4 and IPv6-related information using ALTC 863 attribute (Figure 7). IPv6 is indicated as preferred connectivity 864 type. 866 o=- 25678 753849 IN IP4 192.0.2.2 867 c=IN IP4 192.0.2.2 868 m=audio 12340 RTP/AVP 0 8 869 a=altc:1 IP6 2001:db8::2 6000 870 a=altc:2 IP4 192.0.2.2 12340 872 Figure 7: SDP offer updated by the SBE 874 The request is then forwarded to the core SPF which in its turn 875 forwards the requests to the terminating SBE: 876 o If the destination UA is IPv6 or reachable with a public IPv4 877 address, the SBEs only forwards the request without altering the 878 SDP offer. No parsing error is experienced by core service nodes 879 since ALTC is backward compatible. 880 o If the terminating SBE does not support ALTC, it will ignore this 881 attribute an uses the legacy procedure. 883 As a consequence, only one DBE is maintained in the path when one of 884 the involved parties is IPv6-enabled. Figure 8 shows the overall 885 procedure when involved UAs are IPv6-enabled. 887 +----------+ 888 | Core SIP | 889 +--->|SPF (IPv4)|<---+ 890 IPv4 SIP | +----------+ |IPv4 SIP 891 v v 892 +-----------+ +-----------+ 893 | SBE | | SBE | SIP 894 +------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+ 895 |IPv6 +-----------+ +-----------+ IPv6| 896 | SIP SIP| 897 +----+ | +-----------+ | +----+ 898 |IPv6|-+IPv6 RTP| DBE | IPv6 RTP +-|IPv6| 899 | UA |<-------->| NAT66 |<----------------------------->| UA | 900 +----+ +-----------+ +----+ 901 2001:db8::1 2001:db8::2 903 Figure 8: DBE Bypass Overview 905 The main advantages of such solutions are as follows: 907 o DBE resources are optimized 908 o No redundant NAT is maintained in the path when IPv6-enabled UAs 909 are involved 910 o End-to-end delay is optimized 911 o The robustness of the service is optimized since the delivery of 912 the service relies on fewer nodes 913 o The signaling path is also optimized since no communication 914 between the SBE (through SPDF in TISPAN/IMS context) and DBE at 915 the terminating side is required for some sessions. 917 A.3.5. Direct Communications Between IPv6-enabled User Agents 919 For service providers wanting to allow direct IPv6 communications 920 between IPv6-enabled UAs, when not all SBE/DBE and UA are IPv6- 921 enabled, a means to indicate both IPv4 and IPv6 addresses without 922 inducing session failures is required. Below is proposed an example 923 of a proposed procedure using ALTC attribute. 925 At the SBE originating side, when the SBE receives an INVITE from the 926 calling IPv6 UA (Figure 9), it uses ALTC to indicate two IP 927 addresses: 928 1. An IPv4 address belonging to its controlled DBE 929 2. The same IPv6 address and port as received in the initial offer 930 made by the calling IPv6 932 Figure 10 shows an excerpt example of the SDP offer generated by the 933 originating SBE. 935 o=- 25678 753849 IN IP6 2001:db8::1 936 c=IN IP6 2001:db8::1 937 m=audio 6000 RTP/AVP 0 8 939 Figure 9: SDP offer of the calling UA 941 o=- 25678 753849 IN IP4 192.0.2.2 942 c=IN IP4 192.0.2.2 943 m=audio 12340 RTP/AVP 0 8 944 a=altc:1 IP6 2001:db8::1 6000 945 a=altc:2 IP4 192.0.2.2 12340 947 Figure 10: SDP offer updated by the SBE 949 The INVITE message will be routed appropriately to the destination 950 SBE: 951 1. If the SBE is a legacy device (i.e., IPv4-only); it will ignore 952 IPv6 addresses and contacts its DBE to instantiate an IPv4-IPv4 953 context. 955 2. If the SBE is IPv6-enabled, it will only forwards the INVITE to 956 the address of contact of the called party: 957 A. If the called party is IPv6-enabled, the communication will 958 be placed using IPv6. As such no DBE is involved in the data 959 path as illustrated in Figure 11. 960 B. If not, IPv4 will be used between the originating DBE and 961 called UA. 963 +----------+ 964 | Core SIP | 965 +--->|SPF (IPv4)|<---+ 966 IPv4 SIP | +----------+ |IPv4 SIP 967 v v 968 +-----------+ +-----------+ 969 | SBE | | SBE | SIP 970 +------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+ 971 |IPv6 +-----------+ +-----------+ IPv6| 972 | SIP SIP| 973 +----+ | | +----+ 974 |IPv6|-+ IPv6 RTP +-|IPv6| 975 | UA |<---------------------------------------------------->| UA | 976 +----+ +----+ 977 2001:db8::1 979 Figure 11: Direct IPv6 communication 981 Authors' Addresses 983 Mohamed Boucadair 984 France Telecom 985 Rennes 35000 986 France 988 Email: mohamed.boucadair@orange.com 990 Hadriel Kaplan 991 Acme Packet 992 71 Third Ave. 993 Burlington, MA 01803 994 USA 996 Email: hkaplan@acmepacket.com 997 Robert R Gilman 998 Independent 1000 Email: bob_gilman@comcast.net 1001 URI: 1003 Simo Veikkolainen 1004 Nokia 1006 Email: Simo.Veikkolainen@nokia.com 1007 URI: