idnits 2.17.1 draft-kumar-mboned-64mcast-embedded-address-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 127 has weird spacing: '...etation only...' == Line 128 has weird spacing: '...t to be int...' -- The document date (June 28, 2012) is 4320 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC 5234' is defined on line 407, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-softwire-dslite-multicast' is defined on line 428, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-softwire-mesh-multicast' is defined on line 435, but no explicit reference was found in the text == Unused Reference: 'RFC 4291' is defined on line 444, but no explicit reference was found in the text == Unused Reference: 'RFC 4607' is defined on line 447, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-mboned-v4v6-mcast-ps-00 == Outdated reference: A later version (-06) exists of draft-ietf-mboned-64-multicast-address-format-02 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MBONED Working Group N. Kumar 2 Internet Draft S. Venaas 3 Intended status: Standard Cisco Systems, Inc 4 Expires: December 2012 June 28, 2012 6 PIM/MLD flags for IPv4-IPv6 Multicast Translation Procedure 7 draft-kumar-mboned-64mcast-embedded-address-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet 15 Engineering Task Force (IETF), its areas, and its working 16 groups. Note that other groups may also distribute working 17 documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of 20 six months and may be updated, replaced, or obsoleted by 21 other documents at any time. It is inappropriate to use 22 Internet-Drafts as reference material or to cite them other 23 than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed 29 at http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on December 28, 2012. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as 36 the document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date 41 of publication of this document. Please review these 42 documents carefully, as they describe your rights and 43 restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD 45 License text as described in Section 4.e of the Trust Legal 47 Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation 48 Provisions and are provided without warranty as described in 49 the Simplified BSD License. 51 Abstract 53 This document discusses the procedure that helps to identify 54 IPv4 embedded IPv6 Multicast address without any embedded 55 flags in the address. This document specifies the usage of 56 additional data or attribute in MLD and PIM that helps 57 identify this address. This document is not conclusive and is 58 open for discussion. 60 Table of Contents 62 1. Introduction...................................................2 63 2. Conventions used in this document..............................3 64 3. Terminology....................................................4 65 4. Procedure......................................................4 66 4.1. 64I Join Attribute........................................5 67 4.2. 64I Auxiliary Data........................................5 68 5. Use Cases......................................................6 69 5.1. IPv4 Receiver and Source connected over IPv6-Only 70 network........................................................6 71 5.2. IPv6 Receiver Connected to IPv4 Source through IPv4 72 multicast access network and IPv6 Multicast network............7 73 5.3. IPv6 Receiver and IPv4 Source.............................9 74 6. Security Considerations.......................................10 75 7. IANA Considerations...........................................10 76 8. References....................................................10 77 8.1. Normative References.....................................10 78 8.2. Informative References...................................10 79 9. Acknowledgments...............................................11 81 1. Introduction 83 As part of IPv4 to IPv6 migration, there are multiple 84 standards developed for smooth transition for Unicast. 85 Section 3 of [I-D.ietf-mboned-v4v6-mcast-ps] specifies 87 Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation 88 different possible scenarios for IPv4 to IPv6 multicast 89 transition as below, 91 1. IPv4 Receiver and Source connected over IPv6-Only 92 network 93 2. IPv6 Receiver Connected to IPv4 Source through IPv4 94 multicast access network and IPv6 Multicast network. 95 3. IPv6 Receiver and Source connected to IPv4-Only network. 96 4. IPv6 Receiver and IPv4 Source. 97 5. IPv4 Receiver and IPv6 Source. 99 Section 3.6 of [I-D.ietf-mboned-v4v6-mcast-ps] identifies the 100 use cases involving IPv4 source as highest priority. 102 There are also various solutions proposed (ex., [I-D.ietf- 103 softwire-mesh-multicast], [I-D.ietf-softwire-dslite- 104 multicast]) addressing the above use cases requirement which 105 requires to embed IPv4 multicast address into IPv6 address. 106 This IPv4-embedded IPv6 multicast address will be used as 107 group address within IPv6 cloud. 109 Currently [I-D.ietf-mboned-64-multicast-address-format] 110 defines a new bit in IPv6 Multicast address that signals any 111 router that Ipv4 Multicast address is embedded as last 32 112 bits. This may create backward compatibility issue. 114 This document defines a set of procedures, a new PIM join 115 attribute [RFC 5384] and a new MLD Auxiliary Data that helps 116 achieve the above without a need for any bit embedded within 117 IPv6 Multicast address. 119 2. Conventions used in this document 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 122 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as 124 described in RFC-2119 [RFC2119]. 126 In this document, these words will appear with that 127 interpretation only when in ALL CAPS. Lower case uses of 128 these words are not to be interpreted as carrying RFC-2119 129 significance. 131 Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation 133 3. Terminology 135 (S4, G4)/(*, G4): (S, G) or (*, G) in IPv4 address format 137 (S6, G6)/(*, G6): (S, G) or (*, G) in IPv6 address format 139 4. Procedure 141 Any AFBR on receiving (S4, G4) or (*, G4) PIM join or IGMP 142 Report message and if the S6 after translation is not IPv4 143 translatable address and if the upstream is IPv6 PIM neighbor 144 MUST include transitive 64I JOIN ATTRIBUTE (Section 4.1) in 145 IPv6 PIM Join and embed IPv4 group address in last 32 bits of 146 IPv6 Multicast SSM range address. 148 Any AFBR on receiving (S4, G4) or (*, G4) PIM join or IGMP 149 Report message and if the S6 after translation is IPv4 150 translatable address and if the upstream is IPv6 PIM neighbor 151 SHOULD include transitive 64I JOIN ATTRIBUTE in IPv6 PIM Join 152 and embed IPv4 group address in last 32 bits of IPv6 153 Multicast SSM range address. 155 Any AFBR on receiving (S4, G4) or (*, G4) PIM Join or IGMP 156 Report message and if S6 after translation is not IPv4 157 translatable address and if upstream is IPv6 cloud without 158 PIM neighbor MUST include 64I Auxiliary Data (Section 4.2) in 159 MLDv2 Report Message. 161 Any AFBR on receiving (S4, G4) or (*, G4) PIM Join or IGMP 162 Report message and if S6 after translation is IPv4 163 translatable address and if upstream is IPv6 cloud without 164 PIM neighbor SHOULD include 64I Auxillary Data in MLDv2 165 Report Message. 167 Any AFBR on receiving IPv4 PIM Join with 64I JOIN ATTRIBUTE 168 MUST carry forward the attribute in IPv6 PIM Join sent 169 upstream. 171 Any router on receiving IPv6 PIM Join with 64I JOIN ATTRIBUTE 172 and if upstream is IPv6 cloud without PIM neighbor MUST 173 include 64I Auxillary Data in MLDv2 Report message. 175 Any AFBR on receiving (S6, G6) PIM Join for SSM range address 176 without 64I JOIN ATTRIBUTE and if the IPv6 Source in Join is 177 well known prefix (64:FF9B::/96) or IPv4 translatable IPv6 179 Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation 180 address [RFC 6052] and if the upstream is IPv4 PIM neighbor, 181 MUST pull the last 32 bits to generate IPv4 group address. 183 Any router on receiving (S6, G6) PIM Join from SSM range 184 without 64I JOIN ATTRIBUTE and if Source address is well 185 known prefix (64:FF9B::/96) or IPv4 translatable IPv6 address 186 [RFC 6052] and if the upstream is IPv6 PIM neighbor, MUST 187 include 64I JOIN ATTRIBUTE. 189 Any router on receiving MLD Report with 64I Auxiliary Data 190 MUST include 64I JOIN ATTRIBUTE in IPv6 PIM join sent 191 Upstream for the group. 193 While the above procedure is defined with SSM range address 194 as an example, it is applicable for any (S6, G6) from ASM 195 range. 197 4.1. 64I Join Attribute 199 Below is the format of new PIM JOIN ATTRIBUTE specified in 200 this document, 202 0 1 2 3 203 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 |F|E| Attr Type | Length |T| Reserved | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 F bit: 1, Transitive Attribute 209 E bit: As mentioned in [RFC 5384] 210 Attr Type: TBD 211 Length: 2 212 T bit: 1 213 Reserved: Reserved field for future use. 215 4.2. 64I Auxiliary Data 217 Below is the format of new Auxiliary Data specified in this 218 document, 220 Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation 221 0 1 2 3 222 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Type | Length |T| Reserved | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Type: TBD 228 Length: 229 T Flag: 1 230 Reserved: Reserved bit for future use. 232 5. Use Cases 234 In this document, we also specify the behavior of high 235 priority scenarios with above procedure. 237 5.1. IPv4 Receiver and Source connected over IPv6-Only network 239 This scenario simply known as 4-6-4 is shown below in Figure 240 1. 242 +--------+ +--------+ 243 | Host | | IPv4 | 244 | Rcvr | | DR | 245 | | | | 246 +--------+ +--------+ 247 | | 248 IGMP/IPv4 PIM IGMP/IPv4 PIM 249 | | 250 | | 251 +--------+ +--------+ +--------+ 252 | | MLD | IPv6 | IPv6 | | 253 | AFBR1 |----------| Only |----------| AFBR2 | 254 | | IPv6 PIM | Rtr | PIM | | 255 +--------+ +--------+ +--------+ 256 Figure 1: 4-6-4 Scenario 258 Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation 260 AFBR1 on receiving (S4, G4) or (*, G4) PIM Join or IGMP 261 Report will perform the below, 263 1. If Upstream is IPv6 PIM neighbor, should embed the IPv4 264 multicast group into last 32 bits of IPv6 Multicast SSM 265 range address and send (S6, G6) PIM join with 64I JOIN 266 ATTRIBUTE. 267 2. If Upstream is IPv6 MLD router, should embed the IPv4 268 multicast group into last 32 bits of IPv6 Multicast SSM 269 range address and send MLDv2 Report with 64I Auxillary 270 Data. 272 AFBR2 on receiving (S6, G6) PIM Join without 64I JOIN 273 ATTRIBUTE and if upstream is IPv4 cloud can derive the IPv4 274 multicast group address from last 32 bits. 276 Since F bit will be set in 64I JOIN ATTRIBUTE, it will be 277 delivered to AFBR2 even if any router along the path doesn't 278 understand the attribute. 280 IPv6-only Rtr on receiving (S6, G6) PIM Join with 64I JOIN 281 ATTRIBUTE will send across to AFBR2 with attribute. Since 64I 282 JOIN ATTRIBUTE is transitive in nature, this behavior doesn't 283 change even if IPv6-Only Rtr doesn't understand the 284 attribute. 286 IPv6-only Rtr on receiving (S6, G6) MLD Report with 64I 287 Auxiliary Data will include 64I JOIN ATTRIBUTE in upstream 288 PIM join for (S6, G6). 290 AFBR2 on receiving (S6, G6) PIM Join with 64I JOIN ATTRIBUTE 291 must derive the IPv4 multicast group address from the last 32 292 bits. 294 5.2. IPv6 Receiver Connected to IPv4 Source through IPv4 295 multicast access network and IPv6 Multicast network 297 Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation 298 This scenario simply known as 6-4-6-4 is shown in Figure 2. 300 +--------+ 301 | Host | 302 | Rcvr | 303 | | 304 +--------+ 305 | 306 MLD/IPv6 PIM 307 | 308 | 309 +--------+ +--------+ +--------+ 310 | | IGMP | IPv4 | IPv4 | | 311 | AFBR1 |----------| Only |----------| AFBR2 | 312 | | IPv4 PIM | NW | PIM | | 313 +--------+ +--------+ +--------+ 314 | 315 MLD/IPv6 PIM 316 | 317 | 318 +--------+ +--------+ +--------+ 319 | IPv4 | IGMP | | IPv6 | IPv6 | 320 | DR |----------| AFBR3 |----------| Only | 321 | | IPv4 PIM | | PIM | NW | 322 +--------+ +--------+ +--------+ 323 Figure 2: 6-4-6-4 Scenario 325 In Figure 2, AFBR3 will act as IP/ICMP translator and will 326 advertise IPv4 prefixes into IPv6 cloud as either well known 327 prefix (64:FF9B::/96) or IPv4 translatable IPv6 prefix. 329 In this scenario, AFBR1 or the DR router MUST include 64I 330 JOIN ATTRIBUTE or 64I Auxiliary Data if the source is well 331 known prefix (64:FF9B::/96). AFBR1 or the DR router SHOULD 332 include 64I JOIN ATTRIBUTE or 64I Auxiliary Data if the 333 source is with IPv4 translatable IPv6 prefix. How AFBR1/DR 334 will understand if S6 belongs to IPv4 translatable IPv6 335 prefix is outside the scope of this document. 337 Various solutions are available by which AFBR1 will send the 338 join towards AFBR2. This basically depends if multicast is 339 enabled or disabled on IPv4 cloud. Depending on the solution, 341 Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation 342 AFBR1 will either send IPv6 PIM Join encapsulated within IPv4 343 PIM join or IPv6 PIM Join over some tunnel. 345 AFBR2 on receiving (S6, G6) PIM Join over tunnel or (S6, G6) 346 PIM Join encapsulated within (S4, G4) will send 64I JOIN 347 ATTRIBUTE or 64I Auxiliary Data upstreams towards AFBR3. 349 AFBR3 on receiving (S6, G6) Join with 64I JOIN ATTRIBUTE MUST 350 derive the IPv4 group address from last 32 bits. 352 AFBR3 on receiving (S6, G6) PIM join without 64I JOIN 353 ATTRIBUTE MUST check if S6 falls within well known prefix 354 (64:FF9B::/96) or IPv4 translatable IPv6 Prefix. If S6 is 355 within the above range, it MUST derive IPv4 group from the 356 last 32 bits of G6. 358 5.3. IPv6 Receiver and IPv4 Source 360 +--------+ 361 | Host | 362 | Rcvr | 363 | | 364 +--------+ 365 | 366 MLD/IPv6 PIM 367 | 368 | 369 +--------+ +--------+ +--------+ 370 | | IPv6 | IPv6 | IPv6 | | 371 | DR1 |----------| Only |----------| AFBR1 | 372 | | PIM | NW | PIM | | 373 +--------+ +--------+ +--------+ 374 | 375 IGMP/IPv4 PIM 376 | 377 | 378 +--------+ 379 | | 380 | DR2 | 381 | | 382 +--------+ 383 Figure 3: 6-4 Scenario 385 Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation 387 This scenario works similar to Section 5.2 except that IPv6 388 cloud is not partitioned by IPv4 cloud. 390 6. Security Considerations 392 Security consideration specified in [RFC 5384] and [RFC 6052] 393 are applicable here as well. 395 7. IANA Considerations 397 TBD. 399 8. References 401 8.1. Normative References 403 [RFC2119] Bradner, S., "Key words for use in RFCs to 404 Indicate Requirement Levels", BCP 14, RFC 2119, 405 March 1997. 407 [RFC 5234] Crocker, D. and Overell, P.(Editors), "Augmented 408 BNF for Syntax Specifications: ABNF", RFC 5234, 409 January 2008. 411 8.2. Informative References 413 [I-D.ietf-mboned-v4v6-mcast-ps] 414 Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., 415 Tsou, T., and Q. Sun, "IPv4-IPv6 Multicast: Problem 416 Statement and Use Cases", draft-ietf-mboned-v4v6- 417 mcast-ps-00 (work in progress), May 2012. 419 [I-D.ietf-mboned-64-multicast-address-format] 420 Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, 421 X. and Xu, M, "IPv4-Embedded IPv6 Multicast 422 Address Format", draft-ietf-mboned-64-multicast- 423 address-format-02 (work in progress), February 425 Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation 426 2012. 428 [I-D.ietf-softwire-dslite-multicast] 429 Qin, J., Boucadair, M., Jacquenet, C., Lee, Y., 430 and Q. Wang, "Multicast Extension to DS-Lite 431 Technique in Broadband Deployments", 432 Draft-ietf-softwire-dslite-multicast-02 (work in 433 progress), May 2012. 435 [I-D.ietf-softwire-mesh-multicast] 436 Xu, M., Cui, Y., Yang, S., Wu, J., Metz, C., and 437 G. Shepherd, "Softwire Mesh Multicast", 438 Draft-ietf-softwire-mesh-multicast-02 (work in 439 progress), April 2012. 441 [RFC 5384] Boers, A., Wijnands, I. and Rosen, E., "The 442 Protocol Independent Multicast (PIM) Join 443 Attribute Format", RFC 5384, Nov 2008. 444 [RFC 4291] Hinden, R. and S. Deering, "IP Version 6 445 Addressing Architecture", RFC 4291, February 2006. 447 [RFC 4607] Holbrook, H. and B. Cain "Source-Specific 448 Multicast for IP", RFC 4607, August 2006. 450 [RFC 6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., 451 and X. Li, "IPv6 Addressing of IPv4/IPv6 452 Translators", RFC 6052, October 2010. 454 9. Acknowledgments 456 This document was prepared using 2-Word-v2.0.template.dot. 458 Authors' Addresses 460 Stig Venaas 461 Cisco Systems, Inc. 462 Tasman Drive 463 San Jose, CA 95134 464 USA 465 Email: stig@cisco.com 467 Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation 468 Nagendra Kumar 469 Cisco Systems 470 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 471 Bangalore, KARNATAKA 560 087 472 India 473 Email: naikumar@cisco.com