idnits 2.17.1 draft-ietf-mboned-64-multicast-address-format-03.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 (August 10, 2012) is 4270 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-03 == Outdated reference: A later version (-15) exists of draft-ietf-softwire-multicast-prefix-option-01 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 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 Intended status: Standards Track J. Qin 5 Expires: February 11, 2013 Cisco 6 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 August 10, 2012 17 IPv6 Multicast Address With Embedded IPv4 Multicast Address 18 draft-ietf-mboned-64-multicast-address-format-03 20 Abstract 22 This document reserves two IPv6 multicast prefixes to be used in the 23 context of IPv4-IPv6 interconnection. The document specifies an 24 algorithmic translation of an IPv6 multicast address to a 25 corresponding IPv4 multicast address, and vice versa. This 26 algorithmic translation can be used in both IPv4-IPv6 translation or 27 encapsulation schemes. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on February 11, 2013. 51 Copyright Notice 53 Copyright (c) 2012 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. IPv4-Embedded IPv6 Multicast Prefix & Address . . . . . . . . 5 71 3.1. Reserving Dedicated Prefixes . . . . . . . . . . . . . . . 5 72 3.2. IPv4-Embedded IPv6 Multicast Address . . . . . . . . . . . 6 73 3.3. Address Translation Algorithm . . . . . . . . . . . . . . 7 74 3.4. Textual Representation . . . . . . . . . . . . . . . . . . 7 75 3.5. Source IPv4 Address in the IPv6 Realm . . . . . . . . . . 7 76 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 83 Appendix A. Motivations . . . . . . . . . . . . . . . . . . . . . 10 84 A.1. Why an Address Format is Needed for Multicast 85 IPv4-IPv6 Interconnection? . . . . . . . . . . . . . . . . 10 86 A.2. Why Identifying an IPv4-Embedded IPv6 Multicast 87 Address is Required? . . . . . . . . . . . . . . . . . . . 10 88 A.3. Location of the IPv4 Address . . . . . . . . . . . . . . . 11 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 91 1. Introduction 93 Various solutions (e.g., [I-D.ietf-softwire-mesh-multicast], 94 [I-D.ietf-softwire-dslite-multicast]) have been proposed to allow 95 access to IPv4 multicast content from hosts attached to IPv6-enabled 96 domains. Even if these solutions have distinct applicability scopes 97 (translation vs. encapsulation) and target different use cases, they 98 all make use of specific IPv6 multicast addresses to embed an IPv4 99 multicast address. Particularly, the IPv4-embedded IPv6 multicast 100 address is used as a destination IPv6 address of multicast flows 101 received from an IPv4-enabled domain and injected by the IPv4-IPv6 102 Interconnection Function into an IPv6-enabled domain. It is also 103 used to build an IPv6 multicast state (*, G6) or (S6, G6) 104 corresponding to their (*, G4) or (S4, G4) IPv4 counter parts by the 105 IPv4-IPv6 Interconnection Function. [I-D.ietf-mboned-v4v6-mcast-ps] 106 provides more discussion about issues related to IPv4/IPv6 multicast. 108 This document reserves two prefixes to be used to synthesize IPv4- 109 embedded IPv6 multicast address. This document also defines how 110 IPv4-embedded IPv6 multicast addresses are constructed. Both IPv4- 111 IPv6 translation or encapsulation schemes can make use of these 112 prefixes. 114 Appendix A.1 enumerates the arguments in favor of reserving dedicated 115 prefixes Appendix A.2 discusses why identifying an IPv4-embedded IPv6 116 multicast address is needed. 118 This specification can be used in conjunction with other extensions 119 such as building unicast prefix-based multicast IPv6 address 120 [RFC3306] or embedding the rendezvous point [RFC3956]. These 121 techniques are important tools to simplify IPv6 multicast 122 deployments. Indeed, unicast prefix-based IPv6 addressing is used in 123 many current IPv6 multicast deployments, and has also been defined 124 for IPv4, and is seen as a very useful technique. Also embedded-RP 125 is used in existing deployments. 127 This document is a companion document to [RFC6052] which focuses 128 exclusively on IPv4-embedded IPv6 unicast addresses. 130 2. Terminology 132 This document makes use of the following terms: 134 o IPv4-embedded IPv6 multicast address: denotes a multicast IPv6 135 address which includes in 32 bits an IPv4 address. 137 o Multicast Prefix64 (or MPREFIX64 for short) refers to an IPv6 138 multicast prefix to be used to construct IPv4-embedded IPv6 139 multicast addresses. This prefix is used to build an IPv4- 140 embedded IPv6 multicast address as defined in Section 3.3. 141 Section 3.3 specifies also how to extract an IPv4 address from an 142 IPv4-embedded IPv6 multicast address. 144 o ASM_MPREFIX64: denotes a multicast Prefix64 used in Any Source 145 Multicast (ASM) mode. 147 o SSM_MPREFIX64: denotes a multicast Prefix64 used in Source 148 Specific Multicast (SSM) mode. 150 o IPv4-IPv6 Interconnection Function: refers to a function which is 151 enabled in a node interconnecting an IPv4-enabled domain with an 152 IPv6-enabled one. It can be located in various places of the 153 multicast network. Particularly, in terms of multicast control 154 messages, it can be an IGMP/MLD Interworking Function or an IPv4- 155 IPv6 PIM Interworking Function. An IPv4-IPv6 Interconnection 156 Function is configured with one or two MPREFIX64s. 158 3. IPv4-Embedded IPv6 Multicast Prefix & Address 160 3.1. Reserving Dedicated Prefixes 162 The following constraints should be met when reserving dedicated 163 prefix(es) to be used for IPv4/IPv6 multicast interconnection: 165 1: Belong to ff3x::/32 and be compatible with unicast-based prefix 166 [RFC3306] for SSM. Note that [RFC3306] suggests to set "plen" to 167 0 and "network-prefix" to 0. As such, any prefix in the 33-96 168 range can be convenient. Given [RFC4607] indicates future 169 specifications may allow a non-zero network prefix field, a /33 170 would allow for future extensions but it has the drawback of 171 reserving a large block. A /96 would be adequate for the use 172 cases already identified in [I-D.ietf-mboned-v4v6-mcast-ps]. In 173 the event of any concrete extension, reserving additional 174 prefixes may be considered. 176 2: Be compatible with embedded-RP [RFC3956] and unicast-based prefix 177 [RFC3306] for ASM. This results in a prefix length to be in the 178 17-20 range. A /17 has the advantage of allowing for future 179 extensions but it may be seen as a waste of the multicast address 180 space. Consequently, a /20 is preferred. 182 3: Avoid ff3x::4000:0001-ff3x::7fff:ffff which is reserved for IANA. 184 Meeting (1) and (2) with the same prefix is not feasible without 185 modifying embedded-RP and unicast-based prefix specifications; this 186 option is avoided. 188 As a consequence, two multicast prefixes are proposed to be used when 189 embedding IPv4 address: one prefix for ASM and another one for the 190 SSM. This document reserves the following multicast prefixes to be 191 used in the context of IPv4/IPv6 multicast interconnection: 193 o ff3x:0:8000::/96 SSM range to embed an IPv4 multicast address in 194 the last 32 bits. 196 o ffxx:8000::/20 ASM range to embed an IPv4 multicast address in the 197 last 32 bits. 199 3.2. IPv4-Embedded IPv6 Multicast Address 201 For the delivery of the IPv4-IPv6 multicast interconnection services, 202 a dedicated multicast prefix denoted as MPREFIX64 should be 203 provisioned (e.g., using NETCONF or 204 [I-D.ietf-softwire-multicast-prefix-option]) to any function 205 requiring to build an IPv4-embedded IPv6 multicast address based on 206 an IPv4 multicast address. MPREFIX64 can be of ASM or SSM type. 207 When both modes are used, two prefixes are required to be 208 provisioned. 210 The length of MPREFIX64 MUST be /96. MPREFIX64 should belong to 211 ffxx:8000::/20 for ASM mode and ff3x:0:8000::/96 for the SSM mode. 213 For the ASM mode, the format of the MPREFIX64 should follow what is 214 specified in [RFC3306] and [RFC3956] if corresponding mechanisms are 215 used. If not, bits 21-96 can be set to any value. 217 Figure 1 shows how to build an IPv4-embedded IPv6 multicast address 218 using a configured MPREFIX64 and an IPv4 multicast address. The low- 219 order 32 bits MUST include an IPv4 multicast address. The enclosed 220 IPv4 multicast address SHOULD NOT be in 232/8 range if an 221 ASM_PREFIX64 is configured. The enclosed IPv4 multicast address 222 SHOULD be in 232/8 range if an SSM_PREFIX64 is configured. 224 Embedding an IPv4 multicast address in the last 32 bits does not 225 conflict with the Group IDs assigned by IANA (i.e., 0x00000001 to 226 0x3FFFFFFF [RFC3307]). 228 When several MPREFIX64 are available, it is RECOMMENDED to use the 229 MPREFIX64 which preserve the scope of the IPv4 multicast address. 231 | 96 | 32 | 232 +------------------------------------------------------+----------+ 233 | MPREFIX64 |v4 address| 234 +------------------------------------------------------+----------+ 236 Figure 1: IPv4-Embedded IPv6 Multicast Address Format 238 3.3. Address Translation Algorithm 240 IPv4-embedded IPv6 multicast addresses are composed according to the 241 following algorithm: 243 o Concatenate the MPREFIX64 and the 32 bits of the IPv4 address to 244 obtain a 128-bit address. 246 The IPv4 multicast addresses are extracted from the IPv4-embedded 247 IPv6 multicast addresses according to the following algorithm: 249 o If the multicast address belongs to ff3x:0:8000::/96 or ffxx: 250 8000::/20, extract the last 32 bits of the IPv6 multicast address. 252 3.4. Textual Representation 254 The embedded IPv4 address in an IPv6 multicast address is included in 255 the last 32 bits; therefore dotted decimal notation can be used. 257 3.5. Source IPv4 Address in the IPv6 Realm 259 An IPv4 source is represented in the IPv6 realm with its IPv4- 260 converted IPv6 address [RFC6052]. 262 4. Examples 264 Figure 2 provides an example of ASM IPv4-Embedded IPv6 Address while 265 Figure 3 provides an example of SSM IPv4-Embedded IPv6 Address. 267 IPv4 multicast addresses used in the examples are derived from the 268 IPv4 multicast block reserved for documentation in 269 [I-D.ietf-mboned-mcaddrdoc]. 271 +---------------------+--------------+----------------------------+ 272 | MPREFIX64 | IPv4 address | IPv4-embedded IPv6 address | 273 +---------------------+--------------+----------------------------+ 274 | ffxx:8000:0:abc::/96| 233.252.0.1 |ffxx:8000:0:abc::233.252.0.1| 275 +---------------------+--------------+----------------------------+ 277 Figure 2: Example of ASM IPv4-embedded IPv6 address 279 +---------------------+--------------+----------------------------+ 280 | MPREFIX64 | IPv4 address | IPv4-embedded IPv6 address | 281 +---------------------+--------------+----------------------------+ 282 | ff3x:0:8000::/96 | 233.252.0.5 | ff3x:0:8000::233.252.0.5 | 283 +---------------------+--------------+----------------------------+ 285 Figure 3: Example of SSM IPv4-embedded IPv6 address 287 5. IANA Considerations 289 Authors of this document request to reserve: 291 o ff3x:0:8000::/96 SSM range to embed an IPv4 multicast address in 292 the last 32 bits. 294 o ffxx:8000::/20 ASM range to embed an IPv4 multicast address in the 295 last 32 bits. 297 6. Security Considerations 299 This document defines an algorithmic translation of an IPv6 multicast 300 address into an IPv4 multicast address, and vice versa. The security 301 considerations discussed in [RFC6052] are to be taken into 302 consideration. 304 7. Acknowledgements 306 Many thanks to R. Bonica, B. Sarikaya, P. Savola, T. Tsou and C. 307 Bormann for their comments and review. 309 8. References 311 8.1. Normative References 313 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 314 Requirement Levels", BCP 14, RFC 2119, March 1997. 316 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 317 Multicast Addresses", RFC 3306, August 2002. 319 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 320 Addresses", RFC 3307, August 2002. 322 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 323 Point (RP) Address in an IPv6 Multicast Address", 324 RFC 3956, November 2004. 326 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 327 IP", RFC 4607, August 2006. 329 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 330 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 331 October 2010. 333 8.2. Informative References 335 [I-D.ietf-behave-nat64-learn-analysis] 336 Korhonen, J. and T. Savolainen, "Analysis of solution 337 proposals for hosts to learn NAT64 prefix", 338 draft-ietf-behave-nat64-learn-analysis-03 (work in 339 progress), March 2012. 341 [I-D.ietf-mboned-mcaddrdoc] 342 Venaas, S., Parekh, R., Velde, G., Chown, T., and M. 343 Eubanks, "Multicast Addresses for Documentation", 344 draft-ietf-mboned-mcaddrdoc-04 (work in progress), 345 May 2012. 347 [I-D.ietf-mboned-v4v6-mcast-ps] 348 Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., Tsou, T., 349 and Q. Sun, "IPv4-IPv6 Multicast: Problem Statement and 350 Use Cases", draft-ietf-mboned-v4v6-mcast-ps-00 (work in 351 progress), May 2012. 353 [I-D.ietf-softwire-dslite-multicast] 354 Qin, J., Boucadair, M., Jacquenet, C., Lee, Y., and Q. 355 Wang, "Multicast Extensions to DS-Lite Technique in 356 Broadband Deployments", 357 draft-ietf-softwire-dslite-multicast-02 (work in 358 progress), May 2012. 360 [I-D.ietf-softwire-mesh-multicast] 361 Xu, M., Cui, Y., Wu, J., Yang, S., Metz, C., and G. 362 Shepherd, "Softwire Mesh Multicast", 363 draft-ietf-softwire-mesh-multicast-03 (work in progress), 364 July 2012. 366 [I-D.ietf-softwire-multicast-prefix-option] 367 Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 368 Option for IPv4-Embedded Multicast and Unicast IPv6 369 Prefixes", draft-ietf-softwire-multicast-prefix-option-01 370 (work in progress), August 2012. 372 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 373 Description Protocol", RFC 4566, July 2006. 375 Appendix A. Motivations 377 A.1. Why an Address Format is Needed for Multicast IPv4-IPv6 378 Interconnection? 380 Arguments why an IPv6 address format is needed to embed multicast 381 IPv4 address are quite similar to those of [RFC6052]. Concretely, 382 the definition of a multicast address format embedding a multicast 383 IPv4 address allows: 385 o Stateless IPv4-IPv6 header translation of multicast flows; 387 o Stateless IPv4-IPv6 PIM interworking function; 389 o Stateless IGMP-MLD interworking function (e.g., required for an 390 IPv4 receiver to access to IPv4 multicast content via an IPv6 391 network); 393 o Stateless (local) synthesis of IPv6 address when IPv4 multicast 394 address are embedded in application payload (e.g., SDP [RFC4566]); 396 o Except the provisioning of the same MPREFIX64, no coordination is 397 required between IPv4-IPv6 PIM interworking function, IGMP-MLD 398 interworking function, IPv4-IPv6 Interconnection Function and any 399 ALG (Application Level Gateway) in the path; 401 o Minimal operational constraints on the multicast address 402 management: IPv6 multicast addresses can be constructed using what 403 has been deployed for IPv4 delivery mode. 405 A.2. Why Identifying an IPv4-Embedded IPv6 Multicast Address is 406 Required? 408 Reserving a dedicated multicast prefix for IPv4-IPv6 interconnection 409 purposes is a means to guide the address selection process at the 410 receiver side; in particular it assists the receiver to select the 411 appropriate IP multicast address while avoiding to involve an IPv4- 412 IPv6 interconnection function in the path. 414 Two use cases to illustrate this behavior are provided below: 416 1. An ALG is required to help an IPv6 receiver to select the 417 appropriate IP address when only the IPv4 address is advertised 418 (e.g., using SDP); otherwise the access to the IPv4 multicast 419 content can not be offered to the IPv6 receiver. The ALG may be 420 located downstream the receiver. As such, the ALG does not know 421 in advance whether the receiver is dual-stack or IPv6-only. The 422 ALG may be tuned to insert both the original IPv4 address and 423 corresponding IPv6 multicast address. If a dedicated prefix is 424 not used, a dual-stack receiver may prefer to use the IPv6 425 address to receive the multicast content. This address selection 426 would require multicast flows to cross an IPv4-IPv6 427 interconnection function. 429 2. In order to avoid involving an ALG in the path, an IPv4-only 430 source can advertise both its IPv4 address and IPv4-embedded IPv6 431 multicast address. If a dedicated prefix is not reserved, a 432 dual-stack receiver may prefer to use the IPv6 address to receive 433 the multicast content. This address selection would require 434 multicast flows to cross an IPv4-IPv6 interconnection function. 436 Reserving dedicated IPv6 multicast prefixes for IPv4-IPv6 437 interconnection purposes mitigates the issues discussed in 438 [I-D.ietf-behave-nat64-learn-analysis] in a multicast context. 440 A.3. Location of the IPv4 Address 442 There is no strong argument to allow for flexible options to encode 443 the IPv4 address inside the multicast IPv6 address. The option 444 retained by the authors is to encode the multicast IPv4 address in 445 the low-order 32 bits of the IPv6 address. 447 This choice is also motivated by the need to be compliant with 448 [RFC3306] and [RFC3956]. 450 Authors' Addresses 452 Mohamed Boucadair (editor) 453 France Telecom 454 Rennes, 35000 455 France 457 Email: mohamed.boucadair@orange.com 459 Jacni Qin 460 Cisco 461 China 463 Email: jacni@jacni.com 465 Yiu L. Lee 466 Comcast 467 U.S.A 469 Email: yiu_lee@cable.comcast.com 471 Stig Venaas 472 Cisco Systems 473 Tasman Drive 474 San Jose, CA 95134 475 USA 477 Email: stig@cisco.com 479 Xing Li 480 CERNET Center/Tsinghua University 481 Room 225, Main Building, Tsinghua University 482 Beijing, 100084 483 P.R. China 485 Phone: +86 10-62785983 486 Email: xing@cernet.edu.cn 487 Mingwei Xu 488 Tsinghua University 489 Department of Computer Science, Tsinghua University 490 Beijing, 100084 491 P.R.China 493 Phone: +86-10-6278-5822 494 Email: xmw@cernet.edu.cn