idnits 2.17.00 (12 Aug 2021) /tmp/idnits12072/draft-boucadair-mmusic-ipv6-use-cases-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 1, 2011) is 3817 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: draft-boucadair-mmusic-altc has been published as RFC 6947 == Outdated reference: A later version (-05) exists of draft-boucadair-pcp-rtp-rtcp-03 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC WG M. Boucadair 3 Internet-Draft France Telecom 4 Intended status: Informational December 1, 2011 5 Expires: June 3, 2012 7 Session Description Protocol (SDP) Alternate Connectivity (ALTC): Use 8 Cases 9 draft-boucadair-mmusic-ipv6-use-cases-00 11 Abstract 13 This memo identifies a set of use cases which motivate the 14 specification of Session Description Protocol (SDP) Alternate 15 Connectivity (ALTC) attribute. These use cases are specific to IPv4/ 16 IPv6 co-existence, IPv4/IPv6 interworking and IPv6 migration. Both 17 IPv6-related unicast and multicast are covered. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on June 3, 2012. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Multicast Use Case . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Introducing IPv6 into SIP-based Architectures . . . . . . . . 5 57 4.1. Avoid Crossing CGN Devices . . . . . . . . . . . . . . . . 5 58 4.2. Basic Scenario for IPv6 SIP Service Delivery . . . . . . . 6 59 4.3. Avoid IPv4/IPv6 Interworking . . . . . . . . . . . . . . . 7 60 4.4. DBE Bypass Procedure . . . . . . . . . . . . . . . . . . . 8 61 4.5. Direct Communications Between IPv6-enabled User Agents . . 10 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 1. Introduction 72 This document describes some uses cases for the Session Description 73 Protocol (SDP, [RFC4566]) Alternate Connectivity (ALTC) attribute. 74 These use cases are specific to IPv4/IPv6 co-existence, IPv4/IPv6 75 interworking and IPv6 migration. Both IPv6-related unicast 76 (Section 4) and multicast (Section 3) contexts are covered. 78 For the use cases listed in Section 4: 79 o SBE/DBE are managed by the same administrative entity. 80 o No connectivity issue is encountered between SBEs/DBEs. 81 o No IPv6 connectivity issue is to be encountered between an IPv6- 82 enabled UA and SBE/DBE. 83 o Symmetric RTP/RTCP [RFC4961] is used even for IPv6 flows so that 84 no complications are encountered when firewalls are placed between 85 the UA and DBE. 87 These use cases motivate the need to define a simple and backward 88 compatible extension to SDP to be able to convey both an IPv4 and 89 IPv6 addresses. [I-D.boucadair-mmusic-altc] is an example providing 90 such functionality. The main features of ALTC are:* 92 o Simple 93 o Backwards-compatible 94 o Enables IPv6 transition, where the starting point is legacy IPv4 95 UA's without ICE. 96 o Works with an IPv4-only core 97 o Works with middleboxes 99 2. Terminology 101 This document makes use of the following terms: 103 o SBE (Signaling Path Border Element) denotes a functional element, 104 located at the boundaries of an ITAD (IP Telephony Administrative 105 Domain, [RFC2871]), which is responsible for intercepting 106 signaling flows received from User Agents and relay them to the 107 core service platform. A SBE may be located at the access segment 108 (i.e., be the service contact point for User Agents) or be located 109 at the interconnection with adjacent domains ([RFC6406]). A SBE 110 controls one or more DBEs. SBE and DBE may be located in the same 111 device (e.g., SBC [RFC5853]) or be separated. 113 o DBE (Data Path Border Element) denotes a functional element, 114 located at the boundaries of an ITAD, which is responsible for 115 intercepting media/data flows received from User Agents and relay 116 them to another DBE (or media servers, e.g., announcement server 117 or IVR). An example of DBE is a media gateway intercepting RTP 118 flows. SBE may be located at the access segment (i.e., be the 119 service contact point for User Agents) or be located at the 120 interconnection with adjacent domains ([RFC6406]). 122 o Core service platform is a macro functional block including 123 session routing, interfaces to advanced services and access 124 control. Figure 1 provides an overview of the overall 125 architecture including SBE, DBE and Core service platform. 127 +----------+ 128 | Core SIP | 129 +--------->| SPF |<---------+ 130 | SIP +----------+ SIP | 131 v v 132 +-----------+ +-----------+ 133 +-----+ SIP | SBE | | SBE | SIP 134 | S |<----->| | | |<-----> 135 | I | +-----------+ +-----------+ 136 | P | || || 137 | | +-----------+ +-----------+ 138 | U | RTP | DBE | RTP | DBE | RTP 139 | A |<----->| |<----------------->| | <-----> 140 +-----+ +-----------+ +-----------+ 142 SIP UA can be embedded in the CPE or in a host behind the CPE 144 Figure 1: Service Architecture: Overview 146 3. Multicast Use Case 148 Recently, a significant effort has been undertaken within IETF to 149 specify new mechanisms to interconnect IPv6-only hosts to IPv4-only 150 servers (e.g., [RFC6146]). This effort covered exclusively unicast 151 transfer mode. An ongoing initiative, called multrans, has been 152 launched to cover multicast issues to be encountered during IPv6 153 transition. The overall problem statement is documented in 154 [I-D.jaclee-behave-v4v6-mcast-ps]. 156 A particular issue encountered in the context of IPv4/IPv6 co- 157 existence and IPv6 transition of multicast services is the discovery 158 of multicast group and source (refer to Section 3.4 of 159 [I-D.jaclee-behave-v4v6-mcast-ps]): 161 1. An IPv6-only receiver requesting multicast content generated by 162 an IPv4-only source: 163 (1.1) An ALG is required to help an IPv6 receiver to select the 164 appropriate IP address when only the IPv4 address is 165 advertised (e.g., using SDP); otherwise the access to the 166 IPv4 multicast content can not be offered to the IPv6 167 receiver. The ALG may be located downstream the receiver. 168 As such, the ALG does not know in advance whether the 169 receiver is dual-stack or IPv6-only. The ALG may be tuned 170 to insert both the original IPv4 address and corresponding 171 IPv6 multicast address using for instance the ALTC SDP 172 attribute [I-D.boucadair-mmusic-altc]. 173 (1.2) In order to avoid involving an ALG in the path, an IPv4- 174 only source can advertise both its IPv4 address and IPv4- 175 embedded IPv6 multicast address 176 [I-D.boucadair-behave-64-multicast-address-format] using 177 for instance the ALTC SDP attribute 178 [I-D.venaas-behave-v4v6mc-framework]. 179 2. A dual-stack source sending its multicast content over IPv4 and 180 IPv6: both IPv4 and IPv6 addresses need to be inserted in the SDP 181 part. A means (e.g, ALTC) is needed for this purpose. 183 4. Introducing IPv6 into SIP-based Architectures 185 4.1. Avoid Crossing CGN Devices 187 Some service providers are in the process of enabling DS-Lite 188 [RFC6333] as a means to continue delivering IPv4 services to their 189 customers. To avoiding crossing four levels of NAT when placing a 190 media session (2 NAT in DS-Lite AFTR + 2 NAT in the DBE), it is 191 recommended to enable IPv6 functions in some SBEs/DBEs. Therefore 192 DS-Lite AFTRs won't be crossed for DS-Lite serviced customers if 193 their UA is IPv6-enabled: 195 o For SIP UA embedded in the CPE, this is easy to implement since 196 the SIP UA [RFC3261] can be tuned to behave as IPv6-only UA when 197 DS-Lite is enabled. No ALTC is required for that use case. 198 o But for SIP User Agents located behind the CPE, a solution to 199 indicate both IPv4 and IPv6 are required in order to avoid 200 crossing the DS-Lite CGN. For the NAT traversal, PCP can be used 201 for that purpose [I-D.boucadair-pcp-rtp-rtcp]. This would allow 202 to avoid embedding SIP ALG in the DS-Lite CGN, avoid impacting the 203 SBE by the HNT function and reduce keepalive messages. Both DS- 204 Lite AFTR and SBE are not overloaded by keepalive messages. 206 4.2. Basic Scenario for IPv6 SIP Service Delivery 208 A basic solution to deliver SIP-based services using IPv4-only core 209 service platform to IPv6-enabled UA is to enabled IPv4/IPv6 210 interworking function in SBE/DBE. Signaling and media between two 211 SBEs and DBEs is maintained over IPv4. IPv6 is used between an IPv6- 212 enabled UA and a SBE/DBE. 214 Figure 2 shows the results of session establishment between UAs. In 215 this scenario, IPv4/IPv6 interworking function is invoked even when 216 both involved UAs are IPv6-enabled. 218 +----------+ 219 | Core SIP | 220 +--->|SPF (IPv4)|<--+ 221 IPv4 SIP | +----------+ |IPv4 SIP 222 v v 223 +-----------+ +-----------+ 224 | SBE | | SBE | SIP 225 +------->|IPv4/v6 IWF| | |<-------+ 226 |IPv6 +-----------+ +-----------+ IPv4| 227 | SIP SIP| 228 +----+ | +-----------+ +-----------+ | +----+ 229 |IPv6|-+IPv6 RTP| DBE |IPv4 RTP| DBE |IPv4 RTP+-|IPv4| 230 | UA |<-------->|IPv4/v6 IWF|<------>| |<-------->| UA | 231 +----+ +-----------+ +-----------+ +----+ 233 +----------+ 234 | Core SIP | 235 +--->|SPF (IPv4)|<--+ 236 IPv4 SIP | +----------+ |IPv4 SIP 237 v v 238 +-----------+ +-----------+ 239 | SBE | | SBE | SIP 240 +------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+ 241 |IPv6 +-----------+ +-----------+ IPv6| 242 | SIP SIP| 243 +----+ | +-----------+ +-----------+ | +----+ 244 |IPv6|-+IPv6 RTP| DBE |IPv4 RTP| DBE |IPv6 RTP+-|IPv6| 245 | UA |<-------->|IPv4/v6 IWF|<------>|IPv4/v6 IWF|<-------->| UA | 246 +----+ +-----------+ +-----------+ +----+ 248 Figure 2: Basic scenario 250 Solutions to avoid redundant IPv4/IPv6 NAT and involving several DBEs 251 may be valuable to consider by service providers. 253 4.3. Avoid IPv4/IPv6 Interworking 255 For services providers wanting: 256 1. Means to promote the invocation of IPv6 transfer capabilities can 257 be enabled while no parsing error is to be experienced by core 258 service nodes legacy nodes 259 2. Optimize cost related to IPv4-IPv6 translation licenses 260 3. Reduce the dual-stack lifetime 261 4. Maintain an IPv4-only core 262 5. Only a set of SBE/DBE are IPv6-enabled 264 A solution to indicate both IPv4 and IPv6 addresses is required. 265 This section provides an overview of this procedure: 267 When a SBE receives an INVITE, it instantiates in its DBE an IPv6- 268 IPv6 context and an IPv6-IPv4 context. Both an IPv6 address and an 269 IPv4 address are returned together with other information such as 270 port numbers. SBE builds an SDP offer including both IPv4 and IPv6- 271 related information using ALTC attribute. IPv6 is indicated as 272 preferred connectivity type. 274 o=- 25678 753849 IN IP4 192.0.2.2 275 c=IN IP4 192.0.2.2 276 m=audio 12340 RTP/AVP 0 8 277 a=altc IP6 2001:db8::2 6000 278 a=altc IP4 192.0.2.2 12340 280 Figure 3: SDP offer updated by the SBE 282 The request is then forwarded to the core SPF which in its turn 283 forwards the requests to the terminating SBE. 285 o If this SBE is a legacy one, then it will ignore ALTC attributes 286 and use "c" line. 287 o If the terminating SBE is IPv6-enabled: 288 * If the called UA is IPv4-only, then an IPv6-IPv4 context is 289 created in the corresponding DBE. 290 * If the called UA is IPv6-enabled, then an IPv6-IPv6 context is 291 created in the corresponding DBE. 293 Figure 4 shows the result of the procedure when placing a session 294 between an IPv4 and IPv6 UAs while Figure 5 shows the results of 295 establishing a session between two IPv6-enabled UAs. The result is 296 still not optima since redundant NAT66 is required (Section 4.4). 298 +----------+ 299 | Core SIP | 300 +--->|SPF (IPv4)|<--+ 301 IPv4 SIP | +----------+ |IPv4 SIP 302 v v 303 +-----------+ +-----------+ 304 | SBE | | SBE | SIP 305 +------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+ 306 |IPv6 +-----------+ +-----------+ IPv4| 307 | SIP SIP| 308 +----+ | +-----------+ +-----------+ | +----+ 309 |IPv6|-+IPv6 RTP| DBE |IPv6 RTP| DBE |IPv4 RTP+-|IPv4| 310 | UA |<-------->| NAT66 |<------>|IPv4/v6 IWF|<-------->| UA | 311 +----+ +-----------+ +-----------+ +----+ 312 2001:db8::2 314 Figure 4: Session establishement between IPv4 and IPv6 UAs 316 +----------+ 317 | Core SIP | 318 +--->|SPF (IPv4)|<--+ 319 IPv4 SIP | +----------+ |IPv4 SIP 320 v v 321 +-----------+ +-----------+ 322 | SBE | | SBE | SIP 323 +------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+ 324 |IPv6 +-----------+ +-----------+ IPv6| 325 | SIP SIP| 326 +----+ | +-----------+ +-----------+ | +----+ 327 |IPv6|-+IPv6 RTP| DBE |IPv6 RTP| DBE |IPv6 RTP+-|IPv6| 328 | UA |<-------->| NAT66 |<------>| NAT66 |<-------->| UA | 329 +----+ +-----------+ +-----------+ +----+ 330 2001:db8::2 332 Figure 5: Session establishement between IPv6 UAs 334 4.4. DBE Bypass Procedure 336 For service providers wanting to involve only one DBE in the media 337 path, when not all SBE/DBE and UAs are IPv6-enabled, a means to 338 indicate both IPv4 and IPv6 addresses without inducing session 339 failures is required. Below is proposed an example of a proposed 340 procedure using ALTC attribute. 342 When the originating SBE receives an INVITE from an IPv6-enabled UA, 343 it instantiates in its DBE an IPv6-IPv6 context and an IPv6-IPv4 344 context. Both an IPv6 address and an IPv4 address are returned 345 together with other information such as port numbers. SBE builds an 346 SDP offer including both IPv4 and IPv6-related information using ALTC 347 attribute (Figure 6). IPv6 is indicated as preferred connectivity 348 type. 350 o=- 25678 753849 IN IP4 192.0.2.2 351 c=IN IP4 192.0.2.2 352 m=audio 12340 RTP/AVP 0 8 353 a=altc IP6 2001:db8::2 6000 354 a=altc IP4 192.0.2.2 12340 356 Figure 6: SDP offer updated by the SBE 358 The request is then forwarded to the core SPF which in its turn 359 forwards the requests to the terminating SBE: 360 o If the destination UA is IPv6 or reachable with a public IPv4 361 address, the SBEs only forwards the request without altering the 362 SDP offer. No parsing error is experienced by core service nodes 363 since ALTC is backward compatible. 364 o If the terminating SBE does not support ALTC, it will ignore this 365 attribute an uses the legacy procedure. 367 As a consequence, only one DBE is maintained in the path when one of 368 the involved parties is IPv6-enabled. Figure 7 shows the overall 369 procedure when involved UAs are IPv6-enabled. 371 +----------+ 372 | Core SIP | 373 +--->|SPF (IPv4)|<--+ 374 IPv4 SIP | +----------+ |IPv4 SIP 375 v v 376 +-----------+ +-----------+ 377 | SBE | | SBE | SIP 378 +------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+ 379 |IPv6 +-----------+ +-----------+ IPv6| 380 | SIP SIP| 381 +----+ | +-----------+ | +----+ 382 |IPv6|-+IPv6 RTP| DBE | IPv6 RTP +-|IPv6| 383 | UA |<-------->| NAT66 |<----------------------------->| UA | 384 +----+ +-----------+ +----+ 385 2001:db8::1 2001:db8::2 387 Figure 7: DBE Bypass Overview 389 The main advantages of such solutions are as follows: 391 o DBE resources are optimized 392 o No redundant NAT is maintained in the path when IPv6-enabled UAs 393 are involved 394 o End-to-end delay is optimized 395 o The robustness of the service is optimized since the delivery of 396 the service relies on fewer nodes 397 o The signaling path is also optimized since no communication 398 between the SBE (through SPDF in TISPAN/IMS context) and DBE at 399 the terminating side is required for some sessions. 401 4.5. Direct Communications Between IPv6-enabled User Agents 403 For service providers wanting to allow direct IPv6 communications 404 between IPv6-enabled UAs, when not all SBE/DBE and UA are IPv6- 405 enabled, a means to indicate both IPv4 and IPv6 addresses without 406 inducing session failures is required. Below is proposed an example 407 of a proposed procedure using ALTC attribute. 409 At the SBE originating side, when the SBE receives an INVITE from the 410 calling IPv6 UA (Figure 8), it updates uses the ALTC to indicate two 411 IP addresses: 412 1. An IPv4 address belonging to its controlled DBE 413 2. The same IPv6 address and port as received in the initial offer 414 made by the calling IPv6 416 Figure 9 shows an excerpt example of the SDP offer generated by the 417 originating SBE. 419 o=- 25678 753849 IN IP6 2001:db8::1 420 c=IN IP6 2001:db8::1 421 m=audio 12340 RTP/AVP 0 8 423 Figure 8: SDP offer of the calling UA 425 o=- 25678 753849 IN IP4 192.0.2.2 426 c=IN IP4 192.0.2.2 427 m=audio 12340 RTP/AVP 0 8 428 a=altc IP6 2001:db8::1 6000 429 a=altc IP4 192.0.2.2 12340 431 Figure 9: SDP offer updated by the SBE 433 The INVITE message will be routed appropriately to the destination 434 SBE: 435 1. If the SBE is a legacy device (i.e., IPv4-only); it will ignore 436 IPv6 addresses and contacts its DBE to instantiate an IPv4-IPv4 437 context. 439 2. If the SBE is IPv6-enabled, it will only forwards the INVITE to 440 the address of contact of the called party: 441 A. If the called party is IPv6-enabled, the communication will 442 be placed using IPv6. As such no DBE is involved in the data 443 path as illustrated in Figure 10. 444 B. If not, IPv4 will be used between the originating DBE and 445 called UA. 447 +----------+ 448 | Core SIP | 449 +--->|SPF (IPv4)|<--+ 450 IPv4 SIP | +----------+ |IPv4 SIP 451 v v 452 +-----------+ +-----------+ 453 | SBE | | SBE | SIP 454 +------->|IPv4/v6 IWF| |IPv4/v6 IWF|<-------+ 455 |IPv6 +-----------+ +-----------+ IPv6| 456 | SIP SIP| 457 +----+ | | +----+ 458 |IPv6|-+ IPv6 RTP +-|IPv6| 459 | UA |<---------------------------------------------------->| UA | 460 +----+ +----+ 461 2001:db8::1 463 Figure 10: Direct IPv6 communication 465 5. IANA Considerations 467 This document makes no request of IANA. 469 6. Security Considerations 471 This document does not define any protocol nor architecture; as such 472 there are no security considerations to be elaborated. 474 7. Acknowledgments 476 TBC. 478 8. References 479 8.1. Normative References 481 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 482 A., Peterson, J., Sparks, R., Handley, M., and E. 483 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 484 June 2002. 486 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 487 Description Protocol", RFC 4566, July 2006. 489 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 490 BCP 131, RFC 4961, July 2007. 492 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 493 NAT64: Network Address and Protocol Translation from IPv6 494 Clients to IPv4 Servers", RFC 6146, April 2011. 496 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 497 Stack Lite Broadband Deployments Following IPv4 498 Exhaustion", RFC 6333, August 2011. 500 8.2. Informative References 502 [I-D.boucadair-behave-64-multicast-address-format] 503 Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and 504 M. Xu, "IPv4-Embedded IPv6 Multicast Address Format", 505 draft-boucadair-behave-64-multicast-address-format-03 506 (work in progress), October 2011. 508 [I-D.boucadair-mmusic-altc] 509 Boucadair, M., Kaplan, H., Gilman, R., and S. 510 Veikkolainen, "Session Description Protocol (SDP) 511 Alternate Connectivity (ALTC) Attribute", 512 draft-boucadair-mmusic-altc-04 (work in progress), 513 November 2011. 515 [I-D.boucadair-pcp-rtp-rtcp] 516 Boucadair, M. and S. Sivakumar, "Reserving N and N+1 Ports 517 with PCP", draft-boucadair-pcp-rtp-rtcp-03 (work in 518 progress), October 2011. 520 [I-D.jaclee-behave-v4v6-mcast-ps] 521 Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., and T. 522 ZOU), "IPv4-IPv6 Multicast: Problem Statement and Use 523 Cases", draft-jaclee-behave-v4v6-mcast-ps-03 (work in 524 progress), October 2011. 526 [I-D.venaas-behave-v4v6mc-framework] 527 Venaas, S., Li, X., and C. Bao, "Framework for IPv4/IPv6 528 Multicast Translation", 529 draft-venaas-behave-v4v6mc-framework-03 (work in 530 progress), June 2011. 532 [RFC2871] Rosenberg, J. and H. Schulzrinne, "A Framework for 533 Telephony Routing over IP", RFC 2871, June 2000. 535 [RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, 536 A., and M. Bhatia, "Requirements from Session Initiation 537 Protocol (SIP) Session Border Control (SBC) Deployments", 538 RFC 5853, April 2010. 540 [RFC6406] Malas, D. and J. Livingood, "Session PEERing for 541 Multimedia INTerconnect (SPEERMINT) Architecture", 542 RFC 6406, November 2011. 544 Author's Address 546 Mohamed Boucadair 547 France Telecom 549 Email: mohamed.boucadair@orange.com