idnits 2.17.1 draft-ietf-mboned-64-multicast-address-format-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 : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 3 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 (February 06, 2012) is 4463 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 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 Updates: 4291 (if approved) J. Qin 5 Intended status: Standards Track ZTE 6 Expires: August 9, 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 February 06, 2012 17 IPv4-Embedded IPv6 Multicast Address Format 18 draft-ietf-mboned-64-multicast-address-format-00 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 August 9, 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 . . . . 4 73 4. IPv4-Embedded IPv6 Multicast Address Format: SSM Mode . . . . 5 74 5. Textual Representation . . . . . . . . . . . . . . . . . . . . 6 75 6. Multicast PREFIX64 . . . . . . . . . . . . . . . . . . . . . . 6 76 7. Source IPv4 Address in the IPv6 Realm . . . . . . . . . . . . 7 77 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 80 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 81 12. Normative References . . . . . . . . . . . . . . . . . . . . . 8 82 Appendix A. Design Choices . . . . . . . . . . . . . . . . . . . 9 83 A.1. Location of the IPv4 Address . . . . . . . . . . . . . . . 9 84 A.2. Location of the M-bit . . . . . . . . . . . . . . . . . . 9 85 A.3. Encapsulation vs. Translation . . . . . . . . . . . . . . 11 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 88 1. Introduction 90 This document specifies an extension to the IPv6 multicast addressing 91 architecture to be used in the context of IPv4-IPv6 interconnection. 92 In particular, this document defines an address format for IPv4- 93 embedded IPv6 multicast addresses. This address format can be used 94 for IPv4-IPv6 translation or encapsulation schemes. 96 This document updates [RFC4291]. 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 is a companion document to [RFC6052] which focuses 103 exclusively on IPv4-embedded IPv6 unicast addresses. 105 Details about design choices are documented in Appendix A. 107 2. Terminology 109 This document makes use of the following terms: 111 o IPv4-embedded IPv6 multicast address: denotes a multicast IPv6 112 address which includes in 32 bits an IPv4 address. Two types of 113 IPv6 addresses are defined that carry an IPv4 address in the low- 114 order 32 bits of the address. The format to build such addresses 115 is defined in Section 3 for ASM mode and Section 4 for SSM mode. 117 o Multicast Prefix64 (or MPREFIX64 for short) refers to an IPv6 118 multicast prefix to be used to construct IPv4-embedded IPv6 119 multicast addresses. 121 o ASM_MPREFIX64: denotes a multicast Prefix64 used in ASM mode. It 122 follows the format described in Section 3. 124 o SSM_MPREFIX64: denotes a multicast Prefix64 used in SSM mode. It 125 follows the format described in Section 4. 127 3. IPv4-Embedded IPv6 Multicast Address Format: ASM Mode 129 To meet the requirements listed in Appendix A.2, the following 130 address format is defined to enclose an IPv4 multicast address when 131 ASM mode is used: 133 | 8 | 4 | 4 | 4 | 76 | 32 | 134 +--------+----+----+----+------------------------------+----------+ 135 |11111111|flgs|scop|64IX| sub-group-id |v4 address| 136 +--------+----+----+----+-----------------------------------------+ 137 +-+-+-+-+ 138 IPv4-IPv6 Interconnection bits (64IX): |M|r|r|r| 139 +-+-+-+-+ 141 Figure 1: IPv4-Embedded IPv6 Multicast Address Format: ASM Mode 143 The description of the fields is as follows: 144 o "flgs" and "scop" fields are defined in [RFC4291]. 145 o 64IX field (IPv4-IPv6 interconnection bits): The first bit is the 146 M-bit. When "M-bit" is set to 1, it indicates that a multicast 147 IPv4 address is embedded in the low-order 32 bits of the multicast 148 IPv6 address. All the remaining bits are reserved and MUST be set 149 to 0. 150 o sub-group-id: This field is configurable according to local 151 policies of the entity managing the IPv4-IPv6 Interconnection 152 Function. This field must follow the recommendations specified in 153 [RFC3306] if unicast-based prefix is used or the recommendations 154 specified in [RFC3956] if embedded-RP is used. The default value 155 is all zeros. 156 o The low-order 32 bits MUST include an IPv4 multicast address when 157 the M-bit is set to 1. The enclosed IPv4 multicast address SHOULD 158 NOT be in 232/8 range. 160 4. IPv4-Embedded IPv6 Multicast Address Format: SSM Mode 162 As mentioned above, any IPv4-embedded IPv6 address used in SSM mode 163 MUST be part of ff3x::/32 [RFC4607]. Figure 2 describes the format 164 of the IPv6 multicast address to be used to enclose an IPv4 multicast 165 address. 167 | 8 | 4 | 4 | 16 | 4 | 60 | 32 | 168 +--------+----+----+-----------+----+------------------+----------+ 169 |11111111|0011|scop|00.......00|64IX| sub-group-id |v4 address| 170 +--------+----+----+-----------+----+------------------+----------+ 171 +-+-+-+-+ 172 IPv4-IPv6 Interconnection bits (64IX): |M|r|r|r| 173 +-+-+-+-+ 175 Figure 2: IPv4-Embedded IPv6 Multicast Address Format: SSM Mode 177 The description of the fields is as follows: 179 o Flags must be set to 0011. 180 o "scop" is defined in [RFC4291]. 181 o 64IX field (IPv4-IPv6 interconnection bits): Same meaning as 182 Section 3. 183 o sub-group-id: The default value is all zeros. 184 o The low-order 32 bits MUST include an IPv4 multicast address when 185 the M-bit is set to 1. The embedded IPv4 address SHOULD be in the 186 232/8 range [RFC4607]. 232.0.0.1-232.0.0.255 range is being 187 reserved to IANA. 189 5. Textual Representation 191 The embedded IPv4 address in an IPv6 multicast address is included in 192 the last 32 bits; therefore dotted decimal notation can be used. 194 6. Multicast PREFIX64 196 For the delivery of the IPv4-IPv6 multicast interconnection services, 197 a dedicated multicast prefix denoted as MPREFIX64 should be 198 provisioned to any function requiring to build an IPv4-embedded IPv6 199 multicast address based on an IPv4 multicast address. MPREFIX64 can 200 be of ASM or SSM type. When both modes are used, two prefixes are 201 required to be provisioned. 203 The structure of the MPREFIX64 follows the guidelines specified in 204 Section 3 for the ASM mode and Section 4 when SSM mode is used. 206 The RECOMMENDED MPREFIX64 length is /96 (as shown in Figure 3). 208 The format of the MPREFIX64 should follow what is specified in 209 [RFC3306] and [RFC3956] if corresponding mechanisms are used. 211 Note: the format specified in Section 3 uses some reserved bits 212 defined in [RFC3306] and [RFC3956]: the first bit of the reserved 213 bits have now a meaning, while the remaining bits MUST be set to 214 0. 216 ASM Mode: 218 | 8 | 4 | 4 | 4 | 76 | 32 | 219 +--------+----+----+----+------------------------------+----------+ 220 |11111111|flgs|scop|64IX| sub-group-id |v4 address| 221 +--------+----+----+----+------------------------------+----------+ 222 | | | 223 v v v 224 +------------------------------------------------------+----------+ 225 | ASM_MPREFIX64 |v4 address| 226 +------------------------------------------------------+----------+ 228 SSM Mode: 230 | 8 | 4 | 4 | 16 | 4 | 60 | 32 | 231 +--------+----+----+-----------+----+------------------+----------+ 232 |11111111|0011|scop|00.......00|64IX| sub-group-id |v4 address| 233 +--------+----+----+-----------+----+------------------+----------+ 234 | | | 235 v v v 236 +------------------------------------------------------+----------+ 237 | SSM_MPREFIX64 |v4 address| 238 +------------------------------------------------------+----------+ 240 Figure 3: MPREFIX64 242 7. Source IPv4 Address in the IPv6 Realm 244 An IPv4 source is represented in the IPv6 realm with its IPv4- 245 converted IPv6 address [RFC6052]. 247 8. Examples 249 Figure 4 provides an example of ASM IPv4-Embedded IPv6 Address while 250 Figure 4 provides an example of SSM IPv4-Embedded IPv6 Address. 252 +---------------------+--------------+----------------------------+ 253 | MPREFIX64 | IPv4 address | IPv4-embedded IPv6 address | 254 +---------------------+--------------+----------------------------+ 255 | ffxx:8000:abc::/96 | 224.1.2.3 | ffxx:8000:abc::224.1.2.3 | 256 +---------------------+--------------+----------------------------+ 258 Figure 4: Example of ASM IPv4-embedded IPv6 address 260 +---------------------+--------------+----------------------------+ 261 | MPREFIX64 | IPv4 address | IPv4-embedded IPv6 address | 262 +---------------------+--------------+----------------------------+ 263 | ff3x:0:8000::/96 | 232.1.2.3 | ffxx:0:8000::232.1.2.3 | 264 +---------------------+--------------+----------------------------+ 266 Figure 5: Example of SSM IPv4-embedded IPv6 address 268 9. IANA Considerations 270 Authors of this document request to reserve: 271 o ff3x:0:8000/33 SSM block to embed an IPv4 multicast address in the 272 last 32 bits. 273 o ffxx:8000/17 ASM block to embed an IPv4 multicast address in the 274 last 32 bits. 276 10. Security Considerations 278 This document defined an address format to embed an IPv4 multicast 279 address in an IPv6 multicast address. The same security 280 considerations as those discussed in [RFC6052] are to be taken into 281 consideration. 283 11. Acknowledgements 285 Many thanks to R. Bonica, B. Sarikaya, P. Savola and T. Tsou for 286 their comments and review. 288 12. Normative References 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, March 1997. 293 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 294 Multicast Addresses", RFC 3306, August 2002. 296 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 297 Point (RP) Address in an IPv6 Multicast Address", 298 RFC 3956, November 2004. 300 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 301 Architecture", RFC 4291, February 2006. 303 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 304 IP", RFC 4607, August 2006. 306 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 307 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 308 October 2010. 310 Appendix A. Design Choices 312 A.1. Location of the IPv4 Address 314 There is no strong argument to allow for flexible options to encode 315 the IPv4 address inside the multicast IPv6 address. The option 316 retained by the authors is to encode the multicast IPv4 address in 317 the low-order 32 bits of the IPv6 address. 319 This choice is also motivated by the need to be compliant with 320 [RFC3306] and [RFC3956]. 322 A.2. Location of the M-bit 324 Figure 6 is a reminder of the IPv6 multicast address format as 325 defined in [RFC4291]: 327 | 8 | 4 | 4 | 112 bits | 328 +------ -+----+----+---------------------------------------------+ 329 |11111111|flgs|scop| group ID | 330 +--------+----+----+---------------------------------------------+ 331 +-+-+-+-+ 332 flgs is a set of 4 flags: |0|R|P|T| 333 +-+-+-+-+ 334 * "T-bit" is defined in [RFC4291]; 335 * "P-bit" is defined in [RFC3306] 336 * "R-bit" is defined in [RFC3956] 338 Figure 6: IPv6 Multicast address format as defined in RFC4291 340 It was tempting to use the remaining flag to indicate whether an IPv6 341 address embeds an IPv4 address or not. This choice has been 342 abandoned by the authors for various reasons: 343 o ff3x::/32 is defined as SSM. Defining a new flag would require 344 standards and implementations to also treat ffbx::/32 as SSM. 345 o Prefixes starting with ff7x are defined as embedded-RP, but not 346 prefixes starting with fffx. Below is provided an excerpt from 347 [RFC3956]: 348 " ...the encoding and the protocol mode used when the two high- 349 order bits in "flgs" are set to 11 ("fff0::/12") is 350 intentionally unspecified until such time that the highest- 351 order bit is defined. Without further IETF specification, 352 implementations SHOULD NOT treat the fff0::/12 range as 353 Embedded-RP." 354 as such defining a new flag would require implementations to 355 also treat ff7x::/12 as embedded-RP prefix. 356 o This is the last remaining flag and at this stage we are not sure 357 whether there is other usage scenarios of the flag. 359 As a conclusion, the remaining flag is not used to indicate an IPv6 360 multicast address embeds an IPv4 multicast address. However the 361 following constraints should be met: 363 (1) Belong to ff3x::/32 and be compatible with unicast-based 364 prefix [RFC3306] for SSM. Note that [RFC3306] suggests to set 365 "plen" to 0 and "network-prefix" to 0. 366 (2) Be compatible with embedded-RP [RFC3956] and unicast-based 367 prefix [RFC3306] for ASM; 368 (3) Avoid ff3x::4000:0001-ff3x::7fff:ffff which is reserved for 369 IANA. 370 Meeting (1) and (2) with the same location of the M-bit is not 371 feasible without modifying embedded-RP and unicast-based prefix 372 specifications; this option is avoided. 374 As a consequence, two multicast blocks are proposed to be used when 375 embedding IPv4 address: one block for ASM (Section 3 ) and another 376 one for the SSM (Section 4). 378 A.3. Encapsulation vs. Translation 380 IPv4-IPv6 encapsulator and translator may be embedded in the same 381 device or even implemented with the same software module. In order 382 to help the function whether an encapsulated IPv6 multicast packets 383 or translated IPv6 ones are to be transferred. It was tempting to 384 define an S-bit for that purpose but this choice has been abandoned 385 in favor of the recommendation to use distinct MPREFIX64 for each 386 scheme. 388 As such, there is no need to reserve a bit in the IPv6 multicast 389 address to separate between the translation and the encapsulation 390 schemes. 392 Authors' Addresses 394 Mohamed Boucadair (editor) 395 France Telecom 396 Rennes, 35000 397 France 399 Email: mohamed.boucadair@orange.com 401 Jacni Qin 402 ZTE 403 Shanghai 404 China 406 Email: jacniq@gmail.com 408 Yiu L. Lee 409 Comcast 410 U.S.A 412 Email: yiu_lee@cable.comcast.com 413 Stig Venaas 414 Cisco Systems 415 Tasman Drive 416 San Jose, CA 95134 417 USA 419 Email: stig@cisco.com 421 Xing Li 422 CERNET Center/Tsinghua University 423 Room 225, Main Building, Tsinghua University 424 Beijing, 100084 425 P.R. China 427 Phone: +86 10-62785983 428 Email: xing@cernet.edu.cn 430 Mingwei Xu 431 Tsinghua University 432 Department of Computer Science, Tsinghua University 433 Beijing, 100084 434 P.R.China 436 Phone: +86-10-6278-5822 437 Email: xmw@cernet.edu.cn