idnits 2.17.1 draft-ietf-mboned-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 2 instances 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 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 (May 23, 2012) is 4356 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) == Outdated reference: A later version (-04) exists of draft-ietf-mboned-v4v6-mcast-ps-00 == Outdated reference: A later version (-18) exists of draft-ietf-softwire-dslite-multicast-02 == Outdated reference: A later version (-25) exists of draft-ietf-softwire-mesh-multicast-02 == Outdated reference: A later version (-15) exists of draft-ietf-softwire-multicast-prefix-option-00 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MBONED Working Group M. Boucadair, Ed. 3 Internet-Draft France Telecom 4 Updates: 4291 (if approved) J. Qin 5 Intended status: Standards Track Cisco 6 Expires: November 24, 2012 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 May 23, 2012 17 IPv6 Multicast Address Format With Embedded IPv4 Multicast Address 18 draft-ietf-mboned-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 This document updates RFC4291. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC2119]. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on November 24, 2012. 53 Copyright Notice 55 Copyright (c) 2012 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. IPv4-Embedded IPv6 Multicast Address Format: ASM Mode . . . . 5 73 4. IPv4-Embedded IPv6 Multicast Address Format: SSM Mode . . . . 6 74 5. Textual Representation . . . . . . . . . . . . . . . . . . . . 7 75 6. Multicast PREFIX64 . . . . . . . . . . . . . . . . . . . . . . 7 76 7. Source IPv4 Address in the IPv6 Realm . . . . . . . . . . . . 8 77 8. Address Translation Algorithm . . . . . . . . . . . . . . . . 8 78 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 80 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 82 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 13.1. Normative References . . . . . . . . . . . . . . . . . . 10 84 13.2. Informative References . . . . . . . . . . . . . . . . . 10 85 Appendix A. Design Choices . . . . . . . . . . . . . . . . . . . 11 86 A.1. Why an Address Format is Needed for Multicast 87 IPv4-IPv6 Interconnection? . . . . . . . . . . . . . . . 11 88 A.2. Why Identifying an IPv4-Embedded IPv6 Multicast 89 Address is Required? . . . . . . . . . . . . . . . . . . 11 90 A.3. Location of the IPv4 Address . . . . . . . . . . . . . . 12 91 A.4. Location of the M-bit . . . . . . . . . . . . . . . . . . 12 92 A.5. Encapsulation vs. Translation . . . . . . . . . . . . . . 14 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 95 1. Introduction 97 Various solutions (e.g., [I-D.ietf-softwire-mesh-multicast], 98 [I-D.ietf-softwire-dslite-multicast]) have been proposed to allow 99 access to IPv4 multicast content from hosts attached to IPv6-enabled 100 domains. Even if these solutions have distinct applicability scopes 101 (translation vs. encapsulation) and target different use cases, they 102 all make use of specific IPv6 multicast addresses to embed an IPv4 103 multicast address. Particularly, the IPv4-embedded IPv6 multicast 104 address is used as a destination IPv6 address of multicast flows 105 received from an IPv4-enabled domain and injected by the IPv4-IPv6 106 Interconnection Function into an IPv6-enabled domain. It is also 107 used to build an IPv6 multicast state (*, G6) or (S6, G6) 108 corresponding to their (*, G4) or (S4, G4) IPv4 counter parts by the 109 IPv4-IPv6 Interconnection Function. [I-D.ietf-mboned-v4v6-mcast-ps] 110 provides more discussion about issues related to IPv4/IPv6 multicast. 112 This document specifies an extension to the IPv6 multicast addressing 113 architecture to be used in the context of IPv4-IPv6 interconnection. 114 In particular, this document defines an address format for IPv4- 115 embedded IPv6 multicast addresses. This address format can be used 116 for IPv4-IPv6 translation or encapsulation schemes. 118 This document updates [RFC4291]. A new M-bit is defined; if set to 119 "1", it indicates an IPv4 multicast address is embedded in the low- 120 order 32 bits of the IPv6 multicast address. Appendix A.1 enumerates 121 the arguments in favor of defining an address format while 122 Appendix A.2 discusses why identifying an IPv4-embedded IPv6 123 multicast address is needed. 125 This specification can be used in conjunction with other extensions 126 such as building unicast prefix-based multicast IPv6 address 127 [RFC3306] or embedding the rendezvous point [RFC3956]. 129 This document is a companion document to [RFC6052] which focuses 130 exclusively on IPv4-embedded IPv6 unicast addresses. 132 Details about design choices are documented in Appendix A. 134 2. Terminology 136 This document makes use of the following terms: 138 o IPv4-embedded IPv6 multicast address: denotes a multicast IPv6 139 address which includes in 32 bits an IPv4 address. Two types of 140 IPv6 addresses are defined that carry an IPv4 address in the low- 141 order 32 bits of the address. The format to build such addresses 142 is defined in Section 3 for Any Source Multicast (ASM) mode and 143 Section 4 for Source Specific Multicast (SSM) mode. 145 o Multicast Prefix64 (or MPREFIX64 for short) refers to an IPv6 146 multicast prefix to be used to construct IPv4-embedded IPv6 147 multicast addresses. This prefix is used to build an IPv4- 148 embedded IPv6 multicast address as defined in Section 8. 149 Section 8 specifies also how to extract an IPv4 address from an 150 IPv4-embedded IPv6 multicast address. 152 o ASM_MPREFIX64: denotes a multicast Prefix64 used in ASM mode. It 153 follows the format described in Section 3. 155 o SSM_MPREFIX64: denotes a multicast Prefix64 used in SSM mode. It 156 follows the format described in Section 4. 158 o IPv4-IPv6 Interconnection Function: refers to a function which is 159 enabled in a node interconnecting an IPv4-enabled domain with an 160 IPv6-enabled one. It can be located in various places of the 161 multicast network. Particularly, in terms of multicast control 162 messages, it can be an IGMP/MLD Interworking Function or an IPv4- 163 IPv6 PIM Interworking Function. An IPv4-IPv6 Interconnection 164 Function is configured with one or two MPREFIX64s. 166 3. IPv4-Embedded IPv6 Multicast Address Format: ASM Mode 168 To meet the requirements listed in Appendix A.4, the IPv6 multicast 169 address format defined in [RFC4291] is modified to enclose an IPv4 170 multicast address. Figure 1 shows the modified address format when 171 ASM mode is used. 173 | 8 | 4 | 4 | 4 | 76 | 32 | 174 +--------+----+----+----+------------------------------+----------+ 175 |11111111|flgs|scop|64IX| sub-group-id |v4 address| 176 +--------+----+----+----+-----------------------------------------+ 177 +-+-+-+-+ 178 IPv4-IPv6 Interconnection bits (64IX): |M|resvd| 179 +-+-+-+-+ 180 "resvd" are reserved bits. 182 Figure 1: IPv4-Embedded IPv6 Multicast Address Format: ASM Mode 184 The description of the fields is as follows: 185 o "flgs" and "scop" fields are defined in [RFC4291]. 187 o 64IX field (IPv4-IPv6 interconnection bits): The first bit is the 188 M-bit. When "M-bit" is set to 1, it indicates that a multicast 189 IPv4 address is embedded in the low-order 32 bits of the multicast 190 IPv6 address. All the remaining bits are reserved and MUST be set 191 to 0. 192 o sub-group-id: This field is configurable according to local 193 policies (e.g., enable embedded-RP) of the entity managing the 194 IPv4-IPv6 Interconnection Function. This field MUST follow the 195 recommendations specified in [RFC3306] if unicast-based prefix is 196 used or the recommendations specified in [RFC3956] if embedded-RP 197 is used. The default value is all zeros. 198 o The low-order 32 bits MUST include an IPv4 multicast address when 199 the M-bit is set to 1. The enclosed IPv4 multicast address SHOULD 200 NOT be in 232/8 range. 202 4. IPv4-Embedded IPv6 Multicast Address Format: SSM Mode 204 As mentioned in Appendix A.4, any IPv4-embedded IPv6 address used in 205 SSM mode MUST be part of ff3x::/32 [RFC4607]. Figure 2 describes the 206 format of the IPv6 multicast address to be used to enclose an IPv4 207 multicast address. 209 | 8 | 4 | 4 | 16 | 4 | 60 | 32 | 210 +--------+----+----+-----------+----+------------------+----------+ 211 |11111111|0011|scop|00.......00|64IX| sub-group-id |v4 address| 212 +--------+----+----+-----------+----+------------------+----------+ 213 +-+-+-+-+ 214 IPv4-IPv6 Interconnection bits (64IX): |M|resvd| 215 +-+-+-+-+ 216 "resvd" are reserved bits. 218 Figure 2: IPv4-Embedded IPv6 Multicast Address Format: SSM Mode 220 The description of the fields is as follows: 222 o Flags MUST be set to 0011. 223 o "scop" is defined in [RFC4291]. 224 o 64IX field (IPv4-IPv6 interconnection bits): Same meaning as 225 Section 3. 226 o sub-group-id: The default value is all zeros. 227 o The low-order 32 bits MUST include an IPv4 multicast address when 228 the M-bit is set to 1. The embedded IPv4 address SHOULD be in the 229 232/8 range [RFC4607]. 231 5. Textual Representation 233 The embedded IPv4 address in an IPv6 multicast address is included in 234 the last 32 bits; therefore dotted decimal notation can be used. 236 6. Multicast PREFIX64 238 For the delivery of the IPv4-IPv6 multicast interconnection services, 239 a dedicated multicast prefix denoted as MPREFIX64 should be 240 provisioned (e.g., using NETCONF or 241 [I-D.ietf-softwire-multicast-prefix-option]) to any function 242 requiring to build an IPv4-embedded IPv6 multicast address based on 243 an IPv4 multicast address. MPREFIX64 can be of ASM or SSM type. 244 When both modes are used, two prefixes are required to be 245 provisioned. 247 The structure of the MPREFIX64 follows the guidelines specified in 248 Section 3 for the ASM mode and Section 4 when SSM mode is used. 250 The length of MPREFIX64 MUST be /96 (as shown in Figure 3). 252 The format of the MPREFIX64 should follow what is specified in 253 [RFC3306] and [RFC3956] if corresponding mechanisms are used. 255 The format specified in Section 3 uses some reserved bits defined 256 in [RFC3306] and [RFC3956]: the first of the reserved bits now has 257 a meaning, while the remaining bits MUST be set to 0. 259 ASM Mode: 261 | 8 | 4 | 4 | 4 | 76 | 32 | 262 +--------+----+----+----+------------------------------+----------+ 263 |11111111|flgs|scop|64IX| sub-group-id |v4 address| 264 +--------+----+----+----+------------------------------+----------+ 265 | | | 266 v v v 267 +------------------------------------------------------+----------+ 268 | ASM_MPREFIX64 |v4 address| 269 +------------------------------------------------------+----------+ 271 SSM Mode: 273 | 8 | 4 | 4 | 16 | 4 | 60 | 32 | 274 +--------+----+----+-----------+----+------------------+----------+ 275 |11111111|0011|scop|00.......00|64IX| sub-group-id |v4 address| 276 +--------+----+----+-----------+----+------------------+----------+ 277 | | | 278 v v v 279 +------------------------------------------------------+----------+ 280 | SSM_MPREFIX64 |v4 address| 281 +------------------------------------------------------+----------+ 283 Figure 3: MPREFIX64 285 7. Source IPv4 Address in the IPv6 Realm 287 An IPv4 source is represented in the IPv6 realm with its IPv4- 288 converted IPv6 address [RFC6052]. 290 8. Address Translation Algorithm 292 IPv4-embedded IPv6 multicast addresses are composed according to the 293 following algorithm: 294 o Concatenate the MPREFIX64 and the 32 bits of the IPv4 address to 295 obtain a 128-bit address. 297 The IPv4 multicast addresses are extracted from the IPv4-embedded 298 IPv6 multicast addresses according to the following algorithm: 299 o If the multicast address belongs to ff3x:0:8000/33 or ffxx: 300 8000/17, extract the last 32 bits of the IPv6 multicast address. 302 9. Examples 304 Figure 4 provides an example of ASM IPv4-Embedded IPv6 Address while 305 Figure 5 provides an example of SSM IPv4-Embedded IPv6 Address. 307 +---------------------+--------------+----------------------------+ 308 | MPREFIX64 | IPv4 address | IPv4-embedded IPv6 address | 309 +---------------------+--------------+----------------------------+ 310 | ffxx:8000:abc::/96 | 224.1.2.3 | ffxx:8000:abc::224.1.2.3 | 311 +---------------------+--------------+----------------------------+ 313 Figure 4: Example of ASM IPv4-embedded IPv6 address 315 +---------------------+--------------+----------------------------+ 316 | MPREFIX64 | IPv4 address | IPv4-embedded IPv6 address | 317 +---------------------+--------------+----------------------------+ 318 | ff3x:0:8000::/96 | 232.1.2.3 | ff3x:0:8000::232.1.2.3 | 319 +---------------------+--------------+----------------------------+ 321 Figure 5: Example of SSM IPv4-embedded IPv6 address 323 10. IANA Considerations 325 Authors of this document request to reserve: 326 o ff3x:0:8000/33 SSM block to embed an IPv4 multicast address in the 327 last 32 bits. 328 o ffxx:8000/17 ASM block to embed an IPv4 multicast address in the 329 last 32 bits. 331 11. Security Considerations 333 This document defines an address format to embed an IPv4 multicast 334 address in an IPv6 multicast address. The same security 335 considerations as those discussed in [RFC6052] are to be taken into 336 consideration. 338 12. Acknowledgements 340 Many thanks to R. Bonica, B. Sarikaya, P. Savola, T. Tsou and C. 341 Bormann for their comments and review. 343 13. References 344 13.1. Normative References 346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, March 1997. 349 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 350 Multicast Addresses", RFC 3306, August 2002. 352 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 353 Point (RP) Address in an IPv6 Multicast Address", 354 RFC 3956, November 2004. 356 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 357 Architecture", RFC 4291, February 2006. 359 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 360 IP", RFC 4607, August 2006. 362 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 363 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 364 October 2010. 366 13.2. Informative References 368 [I-D.ietf-behave-nat64-learn-analysis] 369 Korhonen, J. and T. Savolainen, "Analysis of solution 370 proposals for hosts to learn NAT64 prefix", 371 draft-ietf-behave-nat64-learn-analysis-03 (work in 372 progress), March 2012. 374 [I-D.ietf-mboned-v4v6-mcast-ps] 375 Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., Tsou, T., 376 and Q. Sun, "IPv4-IPv6 Multicast: Problem Statement and 377 Use Cases", draft-ietf-mboned-v4v6-mcast-ps-00 (work in 378 progress), May 2012. 380 [I-D.ietf-softwire-dslite-multicast] 381 Qin, J., Boucadair, M., Jacquenet, C., Lee, Y., and Q. 382 Wang, "Multicast Extensions to DS-Lite Technique in 383 Broadband Deployments", 384 draft-ietf-softwire-dslite-multicast-02 (work in 385 progress), May 2012. 387 [I-D.ietf-softwire-mesh-multicast] 388 Xu, M., Cui, Y., Yang, S., Wu, J., Metz, C., and G. 389 Shepherd, "Softwire Mesh Multicast", 390 draft-ietf-softwire-mesh-multicast-02 (work in progress), 391 April 2012. 393 [I-D.ietf-softwire-multicast-prefix-option] 394 Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 395 Option for IPv4-Embedded Multicast and Unicast IPv6 396 Prefixes", draft-ietf-softwire-multicast-prefix-option-00 397 (work in progress), March 2012. 399 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 400 Description Protocol", RFC 4566, July 2006. 402 Appendix A. Design Choices 404 A.1. Why an Address Format is Needed for Multicast IPv4-IPv6 405 Interconnection? 407 Arguments why an IPv6 address format is needed to embed multicast 408 IPv4 address are quite similar to those of [RFC6052]. Concretely, 409 the definition of a multicast address format embedding a multicast 410 IPv4 address allows: 412 o Stateless IPv4-IPv6 header translation of multicast flows; 413 o Stateless IPv4-IPv6 PIM interworking function; 414 o Stateless IGMP-MLD interworking function (e.g., required for an 415 IPv4 receiver to access to IPv4 multicast content via an IPv6 416 network); 417 o Stateless (local) synthesis of IPv6 address when IPv4 multicast 418 address are embedded in application payload (e.g., SDP [RFC4566]); 419 o Except the provisioning of the same MPREFIX64, no coordination is 420 required between IPv4-IPv6 PIM interworking function, IGMP-MLD 421 interworking function, IPv4-IPv6 Interconnection Function and any 422 ALG (Application Level Gateway) in the path; 423 o Minimal operational constraints on the multicast address 424 management: IPv6 multicast addresses can be constructed using what 425 has been deployed for IPv4 delivery mode. 427 A.2. Why Identifying an IPv4-Embedded IPv6 Multicast Address is 428 Required? 430 Reserving an M-bit in the IPv6 multicast address (which is equivalent 431 to reserving a dedicated multicast block for IPv4-IPv6 432 interconnection purposes) is a means to guide the address selection 433 process at the receiver side; in particular it assists the receiver 434 to select the appropriate IP multicast address while avoiding to 435 involve an IPv4-IPv6 interconnection function in the path. 437 Two use cases to illustrate this behavior are provided below: 439 1. An ALG is required to help an IPv6 receiver to select the 440 appropriate IP address when only the IPv4 address is advertised 441 (e.g., using SDP); otherwise the access to the IPv4 multicast 442 content can not be offered to the IPv6 receiver. The ALG may be 443 located downstream the receiver. As such, the ALG does not know 444 in advance whether the receiver is dual-stack or IPv6-only. The 445 ALG may be tuned to insert both the original IPv4 address and 446 corresponding IPv6 multicast address. If the M-bit is not used, 447 a dual-stack receiver may prefer to use the IPv6 address to 448 receive the multicast content. This address selection would 449 require multicast flows to cross an IPv4-IPv6 interconnection 450 function. 451 2. In order to avoid involving an ALG in the path, an IPv4-only 452 source can advertise both its IPv4 address and IPv4-embedded IPv6 453 multicast address. If the M-bit is not used, a dual-stack 454 receiver may prefer to use the IPv6 address to receive the 455 multicast content. This address selection would require 456 multicast flows to cross an IPv4-IPv6 interconnection function. 457 Reserving an M-bit in the IPv6 multicast address for IPv4-IPv6 458 interconnection purposes mitigates the issues discussed in 459 [I-D.ietf-behave-nat64-learn-analysis] in a multicast context. 461 A.3. Location of the IPv4 Address 463 There is no strong argument to allow for flexible options to encode 464 the IPv4 address inside the multicast IPv6 address. The option 465 retained by the authors is to encode the multicast IPv4 address in 466 the low-order 32 bits of the IPv6 address. 468 This choice is also motivated by the need to be compliant with 469 [RFC3306] and [RFC3956]. 471 A.4. Location of the M-bit 473 Figure 6 is a reminder of the IPv6 multicast address format as 474 defined in [RFC4291]: 476 | 8 | 4 | 4 | 112 bits | 477 +------ -+----+----+---------------------------------------------+ 478 |11111111|flgs|scop| group ID | 479 +--------+----+----+---------------------------------------------+ 480 +-+-+-+-+ 481 flgs is a set of 4 flags: |0|R|P|T| 482 +-+-+-+-+ 483 * "T-bit" is defined in [RFC4291]; 484 * "P-bit" is defined in [RFC3306] 485 * "R-bit" is defined in [RFC3956] 487 Figure 6: IPv6 Multicast address format as defined in RFC4291 489 It was tempting to use the remaining flag to indicate whether an IPv6 490 address embeds an IPv4 address or not. This choice has been 491 abandoned by the authors for various reasons: 492 o ff3x::/32 is defined as SSM. Defining a new flag would require 493 standards and implementations to also treat ffbx::/32 as SSM. 494 o Prefixes starting with ff7x are defined as embedded-RP, but not 495 prefixes starting with fffx. Below is provided an excerpt from 496 [RFC3956]: 497 " ...the encoding and the protocol mode used when the two high- 498 order bits in "flgs" are set to 11 ("fff0::/12") is 499 intentionally unspecified until such time that the highest- 500 order bit is defined. Without further IETF specification, 501 implementations SHOULD NOT treat the fff0::/12 range as 502 Embedded-RP." 503 as such defining a new flag would require implementations to 504 also treat ff7x::/12 as embedded-RP prefix. 505 o This is the last remaining flag and at this stage we are not sure 506 whether there is other usage scenarios of the flag. 508 As a conclusion, the remaining flag is not used to indicate an IPv6 509 multicast address embeds an IPv4 multicast address. However the 510 following constraints should be met: 512 (1) Belong to ff3x::/32 and be compatible with unicast-based 513 prefix [RFC3306] for SSM. Note that [RFC3306] suggests to set 514 "plen" to 0 and "network-prefix" to 0. 515 (2) Be compatible with embedded-RP [RFC3956] and unicast-based 516 prefix [RFC3306] for ASM; 517 (3) Avoid ff3x::4000:0001-ff3x::7fff:ffff which is reserved for 518 IANA. 519 Meeting (1) and (2) with the same location of the M-bit is not 520 feasible without modifying embedded-RP and unicast-based prefix 521 specifications; this option is avoided. 523 As a consequence, two multicast blocks are proposed to be used when 524 embedding IPv4 address: one block for ASM (Section 3 ) and another 525 one for the SSM (Section 4). 527 A.5. Encapsulation vs. Translation 529 IPv4-IPv6 encapsulator and translator may be embedded in the same 530 device or even implemented with the same software module. In order 531 to help the function whether an encapsulated IPv6 multicast packets 532 or translated IPv6 ones are to be transferred. It was tempting to 533 define an S-bit for that purpose but this choice has been abandoned 534 in favor of the recommendation to use distinct MPREFIX64 for each 535 scheme. 537 As such, there is no need to reserve a bit in the IPv6 multicast 538 address to separate between the translation and the encapsulation 539 schemes. 541 Authors' Addresses 543 Mohamed Boucadair (editor) 544 France Telecom 545 Rennes, 35000 546 France 548 Email: mohamed.boucadair@orange.com 550 Jacni Qin 551 Cisco 552 China 554 Email: jacni@jacni.com 556 Yiu L. Lee 557 Comcast 558 U.S.A 560 Email: yiu_lee@cable.comcast.com 561 Stig Venaas 562 Cisco Systems 563 Tasman Drive 564 San Jose, CA 95134 565 USA 567 Email: stig@cisco.com 569 Xing Li 570 CERNET Center/Tsinghua University 571 Room 225, Main Building, Tsinghua University 572 Beijing, 100084 573 P.R. China 575 Phone: +86 10-62785983 576 Email: xing@cernet.edu.cn 578 Mingwei Xu 579 Tsinghua University 580 Department of Computer Science, Tsinghua University 581 Beijing, 100084 582 P.R.China 584 Phone: +86-10-6278-5822 585 Email: xmw@cernet.edu.cn