idnits 2.17.1 draft-perreault-mboned-igmp-mld-translation-01.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 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 -- The document date (April 10, 2012) is 4396 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) -- Looks like a reference, but probably isn't: '1' on line 476 -- Looks like a reference, but probably isn't: '2' on line 482 == Missing Reference: 'N' is mentioned on line 458, but not defined == Missing Reference: 'M' is mentioned on line 492, but not defined ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Perreault 3 Internet-Draft Viagenie 4 Intended status: Standards Track T. Tsou 5 Expires: October 12, 2012 Huawei Technologies (USA) 6 April 10, 2012 8 Internet Group Management Protocol (IGMP) / Multicast Listener Discovery 9 (MLD)-Based Multicast Translation ("IGMP/MLD Translation") 10 draft-perreault-mboned-igmp-mld-translation-01 12 Abstract 14 This document describes translation between IGMP and MLD. This 15 allows single-stack multicast nodes to participate in multicast 16 groups from a different address family. Both sending and receiving 17 is supported by this translation mechanism. Both any-source and 18 source-specific multicast (ASM and SSM) are supported as well. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on October 12, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Overview of Implementation Types . . . . . . . . . . . . . . . 4 58 4.1. Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.1.1. Mixed IPv4/IPv6 Networks . . . . . . . . . . . . . . . 5 60 4.2. Multicast Router . . . . . . . . . . . . . . . . . . . . . 6 61 5. Signalling Translation . . . . . . . . . . . . . . . . . . . . 6 62 5.1. IP Headers . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5.1.1. Addresses . . . . . . . . . . . . . . . . . . . . . . 6 64 5.1.2. Router-Alert Option . . . . . . . . . . . . . . . . . 7 65 5.2. IGMP/MLD Translation . . . . . . . . . . . . . . . . . . . 7 66 5.2.1. Message Type Equivalences . . . . . . . . . . . . . . 7 67 5.2.2. The "Translated" Bit . . . . . . . . . . . . . . . . . 8 68 5.2.3. Maximum Response {Delay,Time} . . . . . . . . . . . . 12 69 5.2.4. Multicast Group Address . . . . . . . . . . . . . . . 13 70 5.2.5. Source Addresses . . . . . . . . . . . . . . . . . . . 14 71 5.2.6. Additional and Auxiliary Data . . . . . . . . . . . . 14 72 5.3. MTU Considerations . . . . . . . . . . . . . . . . . . . . 14 73 6. Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . 14 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 77 10. Normative References . . . . . . . . . . . . . . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 80 1. Introduction 82 This document specifies IGMP/MLD translation, a mechanism for IPv4- 83 IPv6 transition and coexistence. It enables single-stack (i.e., 84 IPv4-only or IPv6-only) hosts to participate, either as listeners, 85 sources, or both, in multicast groups belonging to a different 86 address family. 88 This translation mechanism is intended to be considered as a "virtual 89 function" that can be implemented in a listener, in a multicast 90 router, in an IGMP/MLD proxy [RFC4605], in existing layer-2 equipment 91 (i.e. as a "bump in the wire"), or as a standalone translating 92 device. Therefore, this function could be located at the customer 93 network edge (e.g., in customer-premises equipment (CPE)) or at the 94 provider network edge (e.g., in a DSLAM for DSL networks, in a CMTS 95 for cable networks, etc.), or any other node reachable by IGMP/MLD 96 packets. Note that intputs and outputs of this translation function 97 can also be virtual. For example, translated packets need not 98 actually be sent on the wire if the function's output is fed directly 99 into a multicast router process (e.g., a PIM daemon) running on the 100 same host. 102 2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 The unqualified term "proxy" refers to an IGMP/MLD proxy as defined 109 in [RFC4605]. 111 3. Overview 113 The translation function produces IGMPv1,2,3 packets from MLDv1,2 114 packets and vice-versa. 116 +-------------+ 117 IGMPv1 --| |-- MLDv1 118 IGMPv2 --| Translation |-- MLDv2 119 IGMPv3 --| <-----> | 120 +-------------+ 122 Virtual translation function 124 IPv4 addresses are mapped to IPv6 addresses and vice versa as defined 125 in [I-D.boucadair-64-multicast-address-format]. This mapping is 126 stateless. This implies that arbitrary IPv6 addresses are not 127 handled. IPv6 addresses MUST be part of a predetermined prefix in 128 order to be translateable. 130 The statelessness of the translation function is considered a 131 desirable property, and is an objective of this specification. In 132 general, stateless network elements makes simpler designs, allows 133 better scalability, and requires less operational overhead. 135 This translation function is stateless when considering full IGMP or 136 MLD packets. Fragmented packets MUST be reassembled before they can 137 be fed to this translation function. 139 4. Overview of Implementation Types 141 The virtual translation function defined in this document can be 142 implemented in various ways. This section presents an overview of 143 some possibilities. 145 4.1. Proxy 147 As described in [RFC4605], an IGMP/MLD proxy is located between an 148 upstream network and one or more downstream networks. Listeners are 149 in the downstream networks while the rest of the multicast 150 infrastructure is upstream. It is possible to arrange multiple 151 proxies in a tree topology, where one proxy's upstream network is 152 another's downstream network. 154 The translation function MUST be logically situated between the proxy 155 function and the upstream network, as shown in Figure 1. 157 Upstream 158 | 159 +----+-----+ 160 |Translator| 161 +----+-----+ 162 | 163 +---+----+ 164 | Proxy | 165 +-+-+-+-++ 166 | | | | 167 Downstream(s) 169 Figure 1: IGMP/MLD translator proxy topology 171 There are two reasons for locating the translator upstream of the 172 proxy rather than downstream: 174 1. Translating addresses on downstream interfaces could interfere 175 with Querier elections. As described in [RFC3376] section 6.6.2 176 and [RFC3810] section 7.6.2, IGMP and MLD routers elect a Querier 177 amongst themselves. The criteria for winning the election is 178 based on the source address of IGMP/MLD Queries. Having a 179 translator on a downstream interface would impose a new 180 constraint on the address mapping scheme: it would need to ensure 181 the same election result before and after applying the mapping. 182 This constraint is lifted when the translation is applied to the 183 upstream interface instead. Since a proxy acts as a client on 184 its upstream interface, it does not participate in Querier 185 elections. 187 2. There is only one upstream interface whereas there may be 188 multiple downstream interfaces. Applying the translation on the 189 upstream interface has the advantage of having a single 190 translation point, which can facilitate debugging and 191 troubleshooting. 193 Conceptually, translation is applied to messages sent upstream by the 194 client state machine and to messages received from upstream. This 195 document specifies how translation is carried out in terms of packet 196 translation. However, a particular implementation is at liberty to 197 adopt any internal structure as long as externally observable 198 behavior is identical. 200 4.1.1. Mixed IPv4/IPv6 Networks 202 In mixed networks, where there may be both IPv4 and IPv6 receivers, 203 two logical proxies are used. Each maintains membership state and 204 runs state machines in the address families of the receivers it is 205 proxying. Translation is applied to only one of them. This is 206 illustrated in Figure 2. 208 Upstream 209 +-----IPvX-----+ 210 | | 211 +----+-----+ | 212 |Translator| | 213 +----+-----+ | 214 | | 215 +---+--------+ +-----+------+ 216 | Proxy IPvY | | Proxy IPvX | 217 +-+-+-+-+-+--+ +-+-+-+-+-+--+ 218 | | | | | | | | | | 219 Downstream(s) Downstream(s) 220 IPvX IPvX 222 Figure 2: Mixed IPv4/IPv6 topology 224 4.2. Multicast Router 226 When implemented as part of a multicast router, the translation 227 function is logically situated on the downstream interfaces, as shown 228 in Figure 3. In this example, the router speaks PIM on an upstream 229 interface and IGMP/MLD on a downstream interface. 231 PIM 232 | 233 +--------+ 234 | Router | 235 +--------+ 236 | 237 +-------------+ 238 | Translation | 239 +-------------+ 240 | 241 IGMP/MLD 243 Figure 3: IGMP/MLD translator router topology 245 Note that the translation function can be completely virtual in this 246 case, as long as the externally observable behavior conforms to this 247 specification. 249 5. Signalling Translation 251 This section describes how to translate between IGMP and MLD. 253 5.1. IP Headers 255 5.1.1. Addresses 257 Destination addresses are translated as follows: 259 MLDv2 and IGMPv3: The destination address is a well-known address 260 and is translated as listed in Table 1. 262 MLDv1, IGMPv1, and IGMPv2: The destination address corresponds to 263 the address of the multicast group. The multicast group address 264 is mapped between IPv4 and IPv6 as described in 265 [I-D.boucadair-64-multicast-address-format]. 267 +--------------------------------------+------------+----------+ 268 | Description | IPv4 | IPv6 | 269 +--------------------------------------+------------+----------+ 270 | All nodes on link | 224.0.0.1 | ff02::1 | 271 | All routers on link | 224.0.0.2 | ff02::2 | 272 | All IGMP/MLD-capable routers on link | 224.0.0.22 | ff02::16 | 273 +--------------------------------------+------------+----------+ 275 Table 1: IPv4/IPv6 Well-Known Multicast Address Equivalences 277 Source addresses are translated as follows: 279 IGMP to MLD: The source address is set to a link-local IPv6 address 280 assigned to the proxy's upstream interface. 282 MLD to IGMP: The source address is set to the IPv4 address assigned 283 to the proxy's upstream interface. 285 IGMP and MLD Reports having an unspecified source address (0.0.0.0 or 286 ::) are handled differently. In MLD, they are dropped ([RFC3810] 287 section 5.2.13). In IGMP, they are accepted ([RFC3376] section 288 4.2.13). This means that translating 0.0.0.0 to :: and vice-versa 289 would change the router's behaviour: it would accept a message that 290 should have been dropped, and vice-versa. To eliminate this 291 ambiguity, the translator MUST drop IGMP and MLD reports having an 292 unspecified source address. 294 5.1.2. Router-Alert Option 296 IGMP messages are sent with a Router Alert IPv4 option [RFC2113] 297 while MLD message are sent with a Router Alert option in a Hop-By-Hop 298 IPv6 extension header [RFC2711]. The translator needs to convert 299 between these two. In particular, a Router Alert option MUST be sent 300 on output if and only if it was received on input. The value MUST be 301 set to zero unconditionally because the IPv4 and IPv6 value spaces 302 are not identical. 304 5.2. IGMP/MLD Translation 306 5.2.1. Message Type Equivalences 308 The IGMP/MLD messages to be handled by the translator belong to the 309 proxy's upstream interface, on which the proxy acts as a listener. 310 This means that translation will be applied to IGMP/MLD Reports and 311 Leave/Done messages sent from the proxy as well as to to IGMP/MLD 312 Queries received from routers. 314 Upon reception of an IGMP message with a type field containing one of 315 the values listed in Table 2, the translator will intercept the 316 message and produce an equivalent MLDv2 message corresponding to an 317 ICMPv6 message with the listed type number in the same row. The 318 translator will perform the reverse operation upon reception of an 319 MLDv2 message. 321 +-----------------------+--------------------+ 322 | IGMP type number | ICMPv6 type number | 323 +-----------------------+--------------------+ 324 | 17 IGMPv1/v2/v3 Query | 130 MLDv1/v2 Query | 325 | 18 IGMPv1 Report | 131 MLDv1 Report | 326 | 22 IGMPv2 Report | 131 MLDv1 Report | 327 | 23 IGMPv2 Leave | 132 MLDv1 Done | 328 | 34 IGMPv3 Report | 143 MLDv2 Report | 329 +-----------------------+--------------------+ 331 Table 2: IGMP/MLD Message Type Equivalences 333 5.2.2. The "Translated" Bit 335 Experience IPv6 transition in general and translation in particular 336 has shown that it is often useful, for various reasons, most often of 337 an operational nature, that can not necessarily be anticipated at the 338 time a specification gets written, to include a mechanism allowing 339 the identification of translated traffic. 341 This specification tries to anticipate that need by assigning a 342 reserved bit in both IGMPv3 and MLDv2 for such a purpose. When set 343 to 1, it indicates a message that has been translated according to 344 this specification at least once. When set to 0, it indicates that 345 no translation has been performed. 347 A translator conforming to this specification MUST set the Translated 348 bit to 1 on output. The bit is ignored on input by default, meaning 349 that a message could be translated twice or more. This will often be 350 undesirable, but is allowed by this specification. 352 In an IGMPv3 Query, bit number 64 is the Translated bit, as shown in 353 Figure 4. 355 In an IGMPv3 Report, bit number 32 is the Translated bit, as shown in 356 Figure 5. 358 In an MLDv2 Query, bit number 192 is the Translated bit, as shown in 359 Figure 6. 361 In an MLDv2 Report, bit number 32 is the Translated bit, as shown in 362 Figure 7. 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Type = 0x11 | Max Resp Code | Checksum | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Group Address | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 |T|Resv |S| QRV | QQIC | Number of Sources (N) | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Source Address [1] | 374 +- -+ 375 | Source Address [2] | 376 +- . -+ 377 . . . 378 . . . 379 +- -+ 380 | Source Address [N] | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 Figure 4: "Translated" bit in an IGMPv3 Query (identified by the 384 letter T) 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Type = 0x22 | Reserved | Checksum | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 |T| Reserved | Number of Group Records (M) | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | | 394 . . 395 . Group Record [1] . 396 . . 397 | | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | | 400 . . 401 . Group Record [2] . 402 . . 403 | | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | . | 406 . . . 407 | . | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | | 410 . . 411 . Group Record [M] . 412 . . 413 | | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 Figure 5: "Translated" bit in an IGMPv3 Report (identified by the 417 letter T) 419 0 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Type = 130 | Code | Checksum | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Maximum Response Code | Reserved | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | | 427 * * 428 | | 429 * Multicast Address * 430 | | 431 * * 432 | | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 |T|Resv |S| QRV | QQIC | Number of Sources (N) | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | | 437 * * 438 | | 439 * Source Address [1] * 440 | | 441 * * 442 | | 443 +- -+ 444 | | 445 * * 446 | | 447 * Source Address [2] * 448 | | 449 * * 450 | | 451 +- . -+ 452 . . . 453 . . . 454 +- -+ 455 | | 456 * * 457 | | 458 * Source Address [N] * 459 | | 460 * * 461 | | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 Figure 6: "Translated" bit in an MLDv2 Query (identified by the 465 letter T) 467 0 1 2 3 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Type = 143 | Reserved | Checksum | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 |T| Reserved |Nr of Mcast Address Records (M)| 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | | 475 . . 476 . Multicast Address Record [1] . 477 . . 478 | | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | | 481 . . 482 . Multicast Address Record [2] . 483 . . 484 | | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | . | 487 . . . 488 | . | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | | 491 . . 492 . Multicast Address Record [M] . 493 . . 494 | | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 Figure 7: "Translated" bit in an MLDv2 Report (identified by the 498 letter T) 500 5.2.3. Maximum Response {Delay,Time} 502 IGMPv2 and IGMPv3 queries contain a field specifying the Maximum 503 Response Time (MRT), which is the maximum time allowed before sending 504 a Report, expressed in units of 1/10 seconds. Similarly, MLDv1 and 505 MLDv2 queries contain a field specifying the Maximum Response Delay 506 (MRD), expressed in units of milliseconds. 508 IGMPv2 (resp. MLDv1) encode the MRT (resp. MRD) value directly as a 509 binary integer. IGMPv3 (resp. MLDv2) allows a floating-point 510 encoding as well. 512 IGMPv2 and IGMPv3 uses an 8-bit field while MLDv1 and MLDv2 use a 16- 513 bit field. 515 The conversion algorithm is as follows: 517 IGMPv2 to MLDv1: MRD = 100 * MRT 519 All values that can be represented in IGMPv2 can be equivalently 520 represented in MLDv1 without loss of precision. 522 IGMPv3 to MLDv2: MRD = 100 * MRT 524 All values that can be represented in IGMPv3 can be equivalently 525 represented in MLDv2 without loss of precision. 527 If MRT < 128, both MRT and MRD will be encoded as binary integers. 529 If 128 <= MRT < 336, MRT will be encoded as a floating-point value 530 while MRD will be encoded as a binary integer. 532 If 336 <= MRT, both MRT and MRD will be encoded as floating-point 533 values. 535 MLDv1 to IGMPv2: MRT = min(255, round(MRD / 100)) 537 The MRD is divided by 100, rounded to the nearest integer, then 538 capped at 255 (the largest MRT value representable in IGMPv2). 539 There is both precision and range loss. 541 MLDv2 to IGMPv3: MRT = min(31744, round(MRD / 100)) 543 The MRD is divided by 100, rounded to the nearest integer, then 544 capped at 31744 (the largest MRT value representable in IGMPv3). 545 There is both precision and range loss. 547 If MRD < 12800, both MRD and MRT will be encoded as binary 548 integers. 550 If 12800 <= MRD < 32768, MRD will be encoded as a binary integer 551 while MRT will be encoded as a floating-point value. 553 If 32768 <= MRD, both MRD and MRT will be encoded as binary 554 integers. 556 5.2.4. Multicast Group Address 558 The multicast group address is mapped between IPv4 and IPv6 as 559 described in [I-D.boucadair-64-multicast-address-format]. 561 5.2.5. Source Addresses 563 Source addresses, if any, are mapped as follows: 565 IGMP to MLD: IPv4 source addresses are mapped as described in 566 [RFC6052] section 2.2. 568 MLD to IGMP: An IPv4 address is extracted from an IPv6 source 569 address as described in [RFC6052] section 2.2. MLD messages 570 containing a source address outside the IPv4-Embedded IPv6 Prefix 571 are dropped unless there exists an applicable statically 572 configured mapping. 574 5.2.6. Additional and Auxiliary Data 576 All IGMPv3 and MLDv2 messages can contain Additional Data, as defined 577 in [RFC3376] sections 4.1.10 and 4.2.11 and [RFC3810] sections 5.1.12 578 and 5.2.11. 580 In addition, IGMPv3 and MLDv2 Reports can contain Auxiliary Data, as 581 defined in [RFC3376] section 4.2.10 and [RFC3810] section 5.2.10. 583 A translator MUST preserve Additional and Auxiliary Data. This is 584 accomplished by treating such data an an opaque blob and setting the 585 appropriate IPv4 or ICMPv6 length fields appropriately. 587 5.3. MTU Considerations 589 MTU issues should be handled at the application layer, not at the IP 590 layer. That is, the translator MUST split large Report messages into 591 smaller pieces that fit into an interface's MTU after translation, as 592 described in [RFC3810] section 5.2.15 and [RFC3376] section 4.2.16.. 594 6. Data Transfer 596 Note: Should this section be removed? We could say nothing about 597 the data plane and instead focus exclusively on the signalling. 598 Thoughts? 600 The IGMP/MLD translator is configured either to translate the headers 601 of multicast packets or to encapsulate/decapsulate them. This 602 applies to regular multicast traffic, not to IGMP/MLD signalling. 604 Translation is performed according to [RFC6145], with the address 605 mapping specified in [I-D.boucadair-64-multicast-address-format]. 606 IPv6 packets with a source or destination address outside MPREFIX64 607 are dropped unless there exists an applicable statically configured 608 mapping. 610 Encapsulation/decapsulation might be preferable when joining two IPvX 611 islands across an IPvY network. Interfaces on which encapsulation/ 612 decapsulation takes place are configured into the translator. When 613 encapsulating, the original packet is not modified. If it is an IPv6 614 packet, it gets encapsulated in an IPv4 packet, and vice-versa. The 615 addresses of the encapsulating packet are obtained by mapping those 616 of the original packet according to 617 [I-D.boucadair-64-multicast-address-format]. When decapsulating, the 618 original packet is obtained from the encapsulating packet's payload 619 and is forwarded as-is. Refer to [RFC2473] for details. 621 7. IANA Considerations 623 TODO 625 8. Security Considerations 627 TODO 629 9. Acknowledgements 631 The authors wish to thank the following people for their feedback: 632 Behcet Sarikaya, Dino Farinacci, Stig Venaas, and Tom Taylor. 634 10. Normative References 636 [I-D.boucadair-64-multicast-address-format] 637 Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and 638 M. Xu, "IPv4-Embedded IPv6 Multicast Address Format", 639 draft-boucadair-64-multicast-address-format-00 (work in 640 progress), January 2012. 642 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 643 February 1997. 645 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 646 Requirement Levels", BCP 14, RFC 2119, March 1997. 648 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 649 IPv6 Specification", RFC 2473, December 1998. 651 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 652 RFC 2711, October 1999. 654 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 655 Thyagarajan, "Internet Group Management Protocol, Version 656 3", RFC 3376, October 2002. 658 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 659 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 661 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 662 "Internet Group Management Protocol (IGMP) / Multicast 663 Listener Discovery (MLD)-Based Multicast Forwarding 664 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 666 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 667 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 668 October 2010. 670 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 671 Algorithm", RFC 6145, April 2011. 673 Authors' Addresses 675 Simon Perreault 676 Viagenie 677 246 Aberdeen 678 Quebec, QC G1R 2E1 679 Canada 681 Phone: +1 418 656 9254 682 Email: simon.perreault@viagenie.ca 683 URI: http://viagenie.ca 685 Tina Tsou 686 Huawei Technologies (USA) 687 2330 Central Expressway 688 Santa Clara, CA 95050 689 USA 691 Phone: +1 408 330 4424 692 Email: tina.tsou.zouting@huawei.com