idnits 2.17.1 draft-boucadair-behave-64-multicast-address-format-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 are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 -- The draft header indicates that this document updates RFC4291, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC6052, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4291, updated by this document, for RFC5378 checks: 2003-10-10) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 24, 2011) is 4689 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-09) exists of draft-boucadair-mmusic-altc-02 == Outdated reference: A later version (-03) exists of draft-ietf-behave-nat64-learn-analysis-00 == Outdated reference: A later version (-03) exists of draft-jaclee-behave-v4v6-mcast-ps-02 == Outdated reference: A later version (-02) exists of draft-xu-softwire-mesh-multicast-01 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE WG M. Boucadair 3 Internet-Draft France Telecom 4 Updates: 4291, 6052 (if approved) J. Qin 5 Intended status: Standards Track ZTE 6 Expires: December 26, 2011 Y. Lee 7 Comcast 8 S. Venaas 9 Cisco Systems 10 X. Li 11 CERNET Center/Tsinghua 12 University 13 M. Xu 14 Tsinghua University 15 June 24, 2011 17 IPv4-Embedded IPv6 Multicast Address Format 18 draft-boucadair-behave-64-multicast-address-format-02 20 Abstract 22 This document specifies an extension to the IPv6 multicast addressing 23 architecture to be used in the context of IPv4-IPv6 interconnection. 24 In particular, this document defines an address format for IPv4- 25 embedded IPv6 multicast addresses. This address format can be used 26 for IPv4-IPv6 translation or encapsulation schemes. 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 December 26, 2011. 50 Copyright Notice 52 Copyright (c) 2011 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. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4. Why an Address Format is Needed for Multicast IPv4-IPv6 72 Interconnection? . . . . . . . . . . . . . . . . . . . . . . . 6 73 5. Why Identifying an IPv4-Embedded IPv6 Multicast Address is 74 Required? . . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 6. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 7 76 6.1. Location of the IPv4 Address . . . . . . . . . . . . . . . 7 77 6.2. Location of the M-bit . . . . . . . . . . . . . . . . . . 7 78 6.3. Encapsulation vs. Translation . . . . . . . . . . . . . . 9 79 7. IPv4-Embedded IPv6 Multicast Address Format: ASM Mode . . . . 9 80 8. IPv4-Embedded IPv6 Multicast Address Format: SSM Mode . . . . 10 81 9. Textual Representation . . . . . . . . . . . . . . . . . . . . 11 82 10. Multicast PREFIX64 . . . . . . . . . . . . . . . . . . . . . . 11 83 11. Source IPv4 Address in the IPv6 Ream . . . . . . . . . . . . . 12 84 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 85 13. Security Considerations . . . . . . . . . . . . . . . . . . . 12 86 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 87 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 15.1. Normative References . . . . . . . . . . . . . . . . . . . 13 89 15.2. Informative References . . . . . . . . . . . . . . . . . . 13 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 92 1. Introduction 94 This document specifies an extension to the multicast IPv6 addressing 95 architecture [RFC4291]. This extension is used for building IPv4- 96 embedded IPv6 multicast addresses. 98 This specification can be used in conjunction with other extensions 99 such as building unicast prefix-based multicast IPv6 address 100 [RFC3306] or embedding the rendezvous point [RFC3956]. 102 This document updates [RFC6052] which focuses exclusively on IPv4- 103 embedded IPv6 unicast addresses. 105 More discussion about issues related to IPv4/IPv6 multicast can be 106 found at [I-D.jaclee-behave-v4v6-mcast-ps]. 108 1.1. Scope 110 The address format defined in this document applies for both IPv4- 111 IPv6 translation and encapsulation schemes. 113 It is out of scope of this document to define the overall procedure 114 for the delivery of IPv4-embedded IPv6 multicast to the requesting 115 receivers. Practical details about the procedure is defined in 116 specific documents such as [I-D.venaas-behave-v4v6mc-framework] and 117 [I-D.qin-softwire-dslite-multicast]. 119 2. Terminology 121 This document makes use of the following terms: 123 o IPv4-embedded IPv6 multicast address: denotes a multicast IPv6 124 address which includes in 32 bits an IPv4 address. Two types of 125 IPv6 addresses are defined that carry an IPv4 address in the low- 126 order 32 bits of the address. The format to build such addresses 127 is defined in Section 7 for ASM mode and Section 8 for SSM mode. 129 o IPv4-IPv6 Interconnection Function: refers to a function which is 130 enabled in a node interconnecting an IPv4-enabled domain with an 131 IPv6-enabled one. 133 An IPv4-IPv6 Interconnection Function can be implemented using 134 encapsulation or translation techniques. 136 It can be located in various places of the multicast network; 137 it is deployment-specific issue left to operators. 138 Particularly, in terms of multicast control message, it can be 139 an IGMP/MLD Interworking Function or an IPv4-IPv6 PIM 140 Interworking Function. Since from the protocol perspective, 141 the MLD protocol [RFC3810] is a translation of IGMP [RFC3376] 142 in the semantics of IPv6 and PIM [RFC4601] has been designed to 143 accommodate both IPv4 and IPv6, no extra functionality is 144 needed to be defined, but to follow the address format 145 specified in Section 7 for ASM mode and Section 8 for SSM mode. 146 In terms of multicast traffic forwarding, it can be 147 translation-based or encapsulation-based. 149 o Multicast Prefix64 (or MPREFIX64 for short) refers to an IPv6 150 multicast prefix to be used to construct IPv4-embedded IPv6 151 multicast addresses. 153 o ASM_MPREFIX64: denotes a multicast Prefix64 used in ASM mode 154 (Section 7). 156 o SSM_MPREFIX64: denotes a multicast Prefix64 used in SSM mode 157 (Section 8). 159 3. Motivations 161 Recently various solutions (e.g., 162 [I-D.venaas-behave-v4v6mc-framework], 163 [I-D.xu-softwire-mesh-multicast], 164 [I-D.qin-softwire-dslite-multicast], 165 [I-D.sarikaya-behave-netext-nat64-pmip] or 166 [I-D.sarikaya-behave-mext-nat64-dsmip]) have been proposed to allow 167 access to IPv4 multicast content from hosts attached to IPv6-enabled 168 domains. 170 Even if these solutions have distinct applicability scopes 171 (translation vs. encapsulation) and target different use cases, they 172 all make use of specific IPv6 multicast addresses to embed an IPv4 173 multicast address. Particularly, the IPv4-embedded IPv6 multicast 174 address is used as a destination IPv6 address of multicast flows 175 received from an IPv4-enabled domain and injected by the IPv4-IPv6 176 Interconnection Function into an IPv6-enabled domain. It is also 177 used to build an IPv6 multicast state (*, G6) or (S6, G6) 178 corresponding to their (*, G4) or (S4, G4) IPv4 counter parts by the 179 IPv4-IPv6 Interconnection Function. 181 This document aims at harmonizing the definition of an IPv4-embedded 182 IPv6 address format. 184 4. Why an Address Format is Needed for Multicast IPv4-IPv6 185 Interconnection? 187 Arguments why an IPv6 address format is needed to embed multicast 188 IPv4 address are quite similar to those of [RFC6052]. Concretely, 189 the definition of a multicast address format embedding a multicast 190 IPv4 address allows: 192 o Stateless IPv4-IPv6 header translation of multicast flows; 194 o Stateless IPv4-IPv6 PIM interworking function; 196 o Stateless IGMP-MLD interworking function (e.g., required for an 197 IPv4 receiver to access to IPv4 multicast content via an IPv6 198 network); 200 o Stateless (local) synthesis of IPv6 address when IPv4 multicast 201 address are embedded in application payload (e.g., SDP [RFC4566]); 203 o Except the provisioning of the same MPREFIX64, no coordination is 204 required between IPv4-IPv6 PIM interworking function, IGMP-MLD 205 interworking function, IPv4-IPv6 Interconnection Function and any 206 ALG (Application Level Gateway) in the path; 208 o Minimal operational constraints on the multicast address 209 management: IPv6 multicast addresses can be constructed using what 210 has been deployed for IPv4 delivery mode. 212 5. Why Identifying an IPv4-Embedded IPv6 Multicast Address is Required? 214 Reserving an M-bit in the IPv6 multicast address (which is equivalent 215 to reserving a dedicated multicast block for IPv4-IPv6 216 interconnection purposes) is a means to guide the address selection 217 process at the receiver side; in particular it assists the receiver 218 to select the appropriate IP multicast address while avoiding to 219 involve an IPv4-IPv6 interconnection function in the path. 221 Two use cases to illustrate this behavior are provided below: 223 1. An ALG is required to help an IPv6 receiver to select the 224 appropriate IP address when only the IPv4 address is advertised 225 (e.g., using SDP); otherwise the access to the IPv4 multicast 226 content can not be offered to the IPv6 receiver. The ALG may be 227 located downstream the receiver. As such, the ALG does not know 228 in advance whether the receiver is dual-stack or IPv6-only. The 229 ALG may be tuned to insert both the original IPv4 address and 230 corresponding IPv6 multicast address using for instance the ALTC 231 SDP attribute [I-D.boucadair-mmusic-altc]. If the M-bit is not 232 used, a dual-stack receiver may prefer to use the IPv6 address to 233 receive the multicast content. This address selection would 234 require multicast flows to cross an IPv4-IPv6 interconnection 235 function. 237 2. In order to avoid involving an ALG in the path, an IPv4-only 238 source can advertise both its IPv4 address and IPv4-embedded IPv6 239 multicast address using for instance the ALTC SDP attribute. If 240 the M-bit is not used, a dual-stack receiver may prefer to use 241 the IPv6 address to receive the multicast content. This address 242 selection would require multicast flows to cross an IPv4-IPv6 243 interconnection function. 245 Reserving an M-bit in the IPv6 multicast address for IPv4-IPv6 246 interconnection purposes mitigates the issues discussed in 247 [I-D.ietf-behave-nat64-learn-analysis] in a multicast context. 249 6. Design Choices 251 6.1. Location of the IPv4 Address 253 There is no strong argument to allow for flexible options to encode 254 the IPv4 address inside the multicast IPv6 address. The option 255 retained by the authors is to encode the multicast IPv4 address in 256 the low-order 32 bits of the IPv6 address. 258 This choice is also motivated by the need to be compliant with 259 [RFC3306] and [RFC3956]. 261 6.2. Location of the M-bit 263 Figure 1 is a reminder of the IPv6 multicast address format as 264 defined in [RFC4291]: 266 | 8 | 4 | 4 | 112 bits | 267 +------ -+----+----+---------------------------------------------+ 268 |11111111|flgs|scop| group ID | 269 +--------+----+----+---------------------------------------------+ 270 +-+-+-+-+ 271 flgs is a set of 4 flags: |0|R|P|T| 272 +-+-+-+-+ 273 * "T-bit" is defined in [RFC4291]; 274 * "P-bit" is defined in [RFC3306] 275 * "R-bit" is defined in [RFC3956] 277 Figure 1: IPv6 Multicast address format as defined in RFC4291 279 It was tempting to use the remaining flag to indicate whether an IPv6 280 address embeds an IPv4 address or not. This choice has been 281 abandoned by the authors for various reasons: 283 o ff3x::/32 is defined as SSM. Defining a new flag would require 284 standards and implementations to also treat ffbx::/32 as SSM. 286 o Prefixes starting with ff7x are defined as embedded-RP, but not 287 prefixes starting with fffx. Blow is provided an excerpt from 288 [RFC3956]: 290 " ...the encoding and the protocol mode used when the two high- 291 order bits in "flgs" are set to 11 ("FFF0::/12") is 292 intentionally unspecified until such time that the highest- 293 order bit is defined. Without further IETF specification, 294 implementations SHOULD NOT treat the FFF0::/12 range as 295 Embedded-RP." 297 as such defining a new flag would require implementations to 298 also treat ff7x::/12 as embedded-RP prefix. 300 o This is the last remaining flag and at this stage we are not sure 301 whether there is other usage scenarios of the flag. 303 As a conclusion, the remaining flag is not used to indicate an IPv6 304 multicast address embeds an IPv4 multicast address. However the 305 following constraints should be met: 307 (1) Belong to ff3x::/32 and be compatible with unicast-based 308 prefix [RFC3306] for SSM. Note that [RFC3306] suggests to set 309 "plen" to 0 and "network-prefix" to 0. 311 (2) Be compatible with embedded-RP [RFC3956] and unicast-based 312 prefix [RFC3306] for ASM; 313 (3) Avoid ff3x::4000:0001-ff3x::7fff:ffff which is reserved for 314 IANA. 316 Meeting (1) and (2) with the same location of the M-bit is not 317 feasible without modifying embedded-RP and unicast-based prefix 318 specifications; this option is avoided. 320 As a consequence, two multicast blocks are proposed to be used when 321 embedding IPv4 address: one block for ASM (Section 7 ) and another 322 one for the SSM (Section 8). 324 6.3. Encapsulation vs. Translation 326 IPv4-IPv6 encapsulator and translator may be embedded in the same 327 device or even implemented with the same software module. In order 328 to help the function whether an encapsulated IPv6 multicast packets 329 or translated IPv6 ones are to be transferred. It was tempting to 330 define an S-bit for that purpose but this choice has been abandoned 331 in favor of the recommendation to use distinct MPREFIX64 for each 332 scheme. 334 As such, there is no need to reserve a bit in the IPv6 multicast 335 address to separate between the translation and the encapsulation 336 schemes. 338 7. IPv4-Embedded IPv6 Multicast Address Format: ASM Mode 340 To meet the requirements listed in Section 6.2, the following address 341 format is defined to enclose an IPv4 multicast address when ASM mode 342 is used: 344 | 8 | 4 | 4 | 4 | 76 | 32 | 345 +--------+----+----+----+------------------------------+----------+ 346 |11111111|flgs|scop|64IX| sub-group-id |v4 address| 347 +--------+----+----+----+-----------------------------------------+ 348 +-+-+-+-+ 349 IPv4-IPv6 Interconnection bits (64IX): |M|r|r|r| 350 +-+-+-+-+ 352 Figure 2: IPv4-Embedded IPv6 Multicast Address Format: ASM Mode 354 The description of the fields is as follows: 356 o "flgs" and "scop" fields are defined in [RFC4291]. 358 o 64IX field (IPv4-IPv6 interconnection bits): The first bit is the 359 M-bit. When "M-bit" is set to 1, it indicates that an multicast 360 IPv4 address is embedded in the low-order 32 bits of the multicast 361 IPv6 address. All the remaining bits are reserved and MUST be set 362 to 0. 364 o sub-group-id: This field is configurable according to local 365 policies of the entity managing the IPv4-IPv6 Interconnection 366 Function. This field must follow the recommendations specified in 367 [RFC3306] if If unicast-based prefix is used or the 368 recommendations specified in [RFC3306] if embedded-RP is used. 369 The default value is all zeros. 371 o The low-order 32 bits MUST include an IPv4 multicast address when 372 the M-bit is set to 1. The enclosed IPv4 multicast address SHOULD 373 NOT be in 232/8 range. 375 [[DISCUSSION NOTE: Restrict an IPv6 ASM address to embed only 376 an ASM IPv4 address or relax it?]] 378 8. IPv4-Embedded IPv6 Multicast Address Format: SSM Mode 380 As mentioned above, any IPv4-embedded IPv6 address used in SSM mode 381 MUST be part of ff3x::/32 [RFC4607]. Figure 3 describes the format 382 of the IPv6 multicast address to be used to enclose an IPv4 multicast 383 address. 385 | 8 | 4 | 4 | 16 | 4 | 60 | 32 | 386 +--------+----+----+-----------+----+------------------+----------+ 387 |11111111|0011|scop|00.......00|64IX| sub-group-id |v4 address| 388 +--------+----+----+-----------+----+------------------+----------+ 389 +-+-+-+-+ 390 IPv4-IPv6 Interconnection bits (64IX): |M|r|r|r| 391 +-+-+-+-+ 393 Figure 3: IPv4-Embedded IPv6 Multicast Address Format: SSM Mode 395 The description of the fields is as follows: 397 o Flags must be set to 0011. 399 o "scop" is defined in [RFC4291]. 401 o 64IX field (IPv4-IPv6 interconnection bits): Same meaning as 402 Section 7. 404 o sub-group-id: The default value is all zeros. 406 o The low-order 32 bits MUST include an IPv4 multicast address when 407 the M-bit is set to 1. The embedded IPv4 address SHOULD be in the 408 232/8 range [RFC4607]. 232.0.0.1-232.0.0.255 range is being 409 reserved to IANA. 411 [[DISCUSSION NOTE: Restrict an IPv6 SSM address to embed only 412 an SSM IPv4 address?]] 414 9. Textual Representation 416 The embedded IPv4 address in an IPv6 multicast address is included in 417 the last 32 bits; therefore dotted decimal notation can be used. 419 10. Multicast PREFIX64 421 For the delivery of the IPv4-IPv6 multicast interconnection services, 422 a dedicated multicast prefix denoted as MPREFIX64 should be 423 provisioned to any function requiring to build an IPv4-embedded IPv6 424 multicast address based on an IPv4 multicast address. MPREFIX64 can 425 be of ASM or SSM type. When both modes are used, two prefixes are 426 required to be provisioned. 428 The structure of the MPREFIX64 follows the guidelines specified in 429 Section 7 for the ASM mode and Section 8 when SSM mode is used. 431 MPREFIX64 MAY be of any length from /32 to /96; /96 being the 432 RECOMMENDED prefix length as shown in Figure 4). 434 The format of the MPREFIX64 should be compatible with what is 435 specified in [RFC3306] and [RFC3956] if corresponding mechanisms are 436 used. 438 ASM Mode: 440 | 8 | 4 | 4 | 4 | 76 | 32 | 441 +--------+----+----+----+------------------------------+----------+ 442 |11111111|flgs|scop|64IX| sub-group-id |v4 address| 443 +--------+----+----+----+------------------------------+----------+ 444 | | | 445 v v v 446 +------------------------------------------------------+----------+ 447 | ASM_MPREFIX64 |v4 address| 448 +------------------------------------------------------+----------+ 450 SSM Mode: 452 | 8 | 4 | 4 | 16 | 4 | 60 | 32 | 453 +--------+----+----+-----------+----+------------------+----------+ 454 |11111111|0011|scop|00.......00|64IX| sub-group-id |v4 address| 455 +--------+----+----+-----------+----+------------------+----------+ 456 | | | 457 v v v 458 +------------------------------------------------------+----------+ 459 | SSM_MPREFIX64 |v4 address| 460 +------------------------------------------------------+----------+ 462 Figure 4: MPREFIX64 464 11. Source IPv4 Address in the IPv6 Ream 466 An IPv4 source is represented in the IPv6 realm with its IPv4- 467 converted IPv6 address [RFC6052]. 469 12. IANA Considerations 471 TBC. 473 13. Security Considerations 475 This document defined an address format to embed an IPv4 multicast 476 address in an IPv6 multicast address. The same security 477 considerations as those discussed in [RFC6052] are to be taken into 478 consideration. 480 14. Acknowledgements 482 Many thanks to B. Sarikaya and P. Savola for their comments. 484 15. References 486 15.1. Normative References 488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 489 Requirement Levels", BCP 14, RFC 2119, March 1997. 491 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 492 Multicast Addresses", RFC 3306, August 2002. 494 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 495 Thyagarajan, "Internet Group Management Protocol, Version 496 3", RFC 3376, October 2002. 498 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 499 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 501 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 502 Point (RP) Address in an IPv6 Multicast Address", 503 RFC 3956, November 2004. 505 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 506 Architecture", RFC 4291, February 2006. 508 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 509 Description Protocol", RFC 4566, July 2006. 511 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 512 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 513 Protocol Specification (Revised)", RFC 4601, August 2006. 515 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 516 IP", RFC 4607, August 2006. 518 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 519 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 520 October 2010. 522 15.2. Informative References 524 [I-D.boucadair-mmusic-altc] 525 Boucadair, M., Kaplan, H., Gilman, R., and S. 526 Veikkolainen, "Session Description Protocol (SDP) 527 Alternate Connectivity (ALTC) Attribute", 528 draft-boucadair-mmusic-altc-02 (work in progress), 529 March 2011. 531 [I-D.ietf-behave-nat64-learn-analysis] 532 Korhonen, J. and T. Savolainen, "Analysis of solution 533 proposals for hosts to learn NAT64 prefix", 534 draft-ietf-behave-nat64-learn-analysis-00 (work in 535 progress), May 2011. 537 [I-D.jaclee-behave-v4v6-mcast-ps] 538 Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., and T. 539 ZOU), "IPv4-IPv6 Multicast: Problem Statement and Use 540 Cases", draft-jaclee-behave-v4v6-mcast-ps-02 (work in 541 progress), June 2011. 543 [I-D.qin-softwire-dslite-multicast] 544 Wang, Q., Qin, J., Boucadair, M., Jacquenet, C., and Y. 545 Lee, "Multicast Extensions to DS-Lite Technique in 546 Broadband Deployments", 547 draft-qin-softwire-dslite-multicast-04 (work in progress), 548 June 2011. 550 [I-D.sarikaya-behave-mext-nat64-dsmip] 551 Sarikaya, B. and F. Xia, "NAT64 for Dual Stack Mobile 552 IPv6", draft-sarikaya-behave-mext-nat64-dsmip-02 (work in 553 progress), January 2011. 555 [I-D.sarikaya-behave-netext-nat64-pmip] 556 Sarikaya, B. and F. Xia, "NAT64 for Proxy Mobile IPv6", 557 draft-sarikaya-behave-netext-nat64-pmip-01 (work in 558 progress), January 2011. 560 [I-D.venaas-behave-v4v6mc-framework] 561 Venaas, S., Li, X., and C. Bao, "Framework for IPv4/IPv6 562 Multicast Translation", 563 draft-venaas-behave-v4v6mc-framework-03 (work in 564 progress), June 2011. 566 [I-D.xu-softwire-mesh-multicast] 567 Xu, M., Cui, Y., Yang, S., Metz, C., and G. Shepherd, 568 "Softwire Mesh Multicast", 569 draft-xu-softwire-mesh-multicast-01 (work in progress), 570 March 2011. 572 Authors' Addresses 574 Mohamed Boucadair 575 France Telecom 576 Rennes, 35000 577 France 579 Email: mohamed.boucadair@orange-ftgroup.com 581 Jacni Qin 582 ZTE 583 Shanghai 584 China 586 Email: jacniq@gmail.com 588 Yiu L. Lee 589 Comcast 591 Email: yiu_lee@cable.comcast.com 592 URI: http://www.comcast.com 594 Stig Venaas 595 Cisco Systems 596 Tasman Drive 597 San Jose, CA 95134 598 USA 600 Email: stig@cisco.com 602 Xing Li 603 CERNET Center/Tsinghua University 604 Room 225, Main Building, Tsinghua University 605 Beijing, 100084 606 P.R. China 608 Phone: +86 10-62785983 609 Fax: 610 Email: xing@cernet.edu.cn 611 URI: 613 Mingwei Xu 614 Tsinghua University 615 Department of Computer Science, Tsinghua University 616 Beijing, 100084 617 P.R.China 619 Phone: +86-10-6278-5822 620 Email: xmw@cernet.edu.cn