idnits 2.17.1 draft-sarikaya-softwire-map-multicast-04.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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 4 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 == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 8, 2015) is 3239 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) == Unused Reference: 'RFC2119' is defined on line 512, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 515, but no explicit reference was found in the text == Unused Reference: 'RFC1112' is defined on line 518, but no explicit reference was found in the text == Unused Reference: 'RFC3307' is defined on line 539, but no explicit reference was found in the text == Unused Reference: 'RFC2491' is defined on line 542, but no explicit reference was found in the text == Unused Reference: 'RFC2765' is defined on line 549, but no explicit reference was found in the text == Unused Reference: 'RFC4213' is defined on line 563, but no explicit reference was found in the text == Unused Reference: 'RFC6145' is defined on line 579, but no explicit reference was found in the text == Unused Reference: 'RFC6275' is defined on line 590, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 642, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) ** Obsolete normative reference: RFC 3171 (Obsoleted by RFC 5771) ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) ** Downref: Normative reference to an Informational RFC: RFC 3022 ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) ** Downref: Normative reference to an Experimental draft: draft-ietf-softwire-4rd (ref. 'I-D.ietf-softwire-4rd') == Outdated reference: A later version (-15) exists of draft-ietf-softwire-multicast-prefix-option-08 == Outdated reference: A later version (-18) exists of draft-ietf-softwire-dslite-multicast-09 Summary: 7 errors (**), 0 flaws (~~), 16 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sarikaya 3 Internet-Draft Huawei USA 4 Intended status: Standards Track H. Ji 5 Expires: December 10, 2015 China Telecom 6 June 8, 2015 8 Multicast Support for Mapping of Address and Port Protocol and Light 9 Weight 4over6 10 draft-sarikaya-softwire-map-multicast-04 12 Abstract 14 This memo specifies multicast component for MAP and Light Weight 15 4over6 so that IPv4 hosts can receive multicast data from IPv4 16 servers over an IPv6 network. The solution developed is based on 17 translation. In the Translation Multicast solution for MAP (MAP-E 18 and MAP-T) and lw4o6, IGMP messages are translated into MLD messages 19 and sent to the network in IPv6. MAP Border Relay/lwAFTR does the 20 reverse translation and joins IPv4 multicast group for the hosts. 21 Border Relay/lwAFTR as multicast router receives IPv4 multicast data 22 and translates the packet into IPv6 multicast data and sends 23 downstream on the multicast tree. Member CEs/lwB4s receive multicast 24 data, translate it back to IPv4 and transmit to the hosts. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 10, 2015. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. MAP-T and 4rd Translation Architecture . . . . . . . . . 4 64 4. MAP-T and 4rd Translation Multicast Operation . . . . . . . . 7 65 4.1. Address Translation . . . . . . . . . . . . . . . . . . . 7 66 4.2. Protocol Translation . . . . . . . . . . . . . . . . . . 9 67 4.3. Learning Multicast Prefixes for IPv4-embedded IPv6 68 Multicast Addresses . . . . . . . . . . . . . . . . . . . 10 69 4.4. Supporting IPv4 Multicast at CE Router and lwB4 . . . . . 11 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 75 8.2. Informative references . . . . . . . . . . . . . . . . . 14 76 Appendix A. Group Membership Message Translation Details . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 79 1. Introduction 81 With IPv4 address depletion on the horizon, many techniques are being 82 standardized for IPv6 migration including Mapping of Address and Port 83 (MAP) - Encapsulation, - Translation and 4rd [I-D.ietf-softwire-map], 84 [I-D.ietf-softwire-map-t], [I-D.ietf-softwire-4rd]. MAP/4rd enables 85 IPv4 hosts to communicate with external hosts using IPv6 only ISP 86 network. MAP/4rd Customer Edge (CE) device's LAN side is dual stack 87 and WAN side is IPv6 only. CE tunnels/translates IPv4 packets 88 received from the LAN side to 4rd Border Relays (BR). BRs have 89 anycast IPv6 addresses and receive encapsulated/translated packets 90 from CEs over a virtual interface. MAP/4rd operation is stateless. 91 Packets are received/ sent independent of each other and no state 92 needs to be maintained except for NAT44 operation on IPv4 packets 93 received from the user. 95 Light Weight 4 Over 6 (lw4o6) is a variant of Dual Stack Lite where 96 carrier grade NAT is moved from AFTR to B4 element, i.e. NAPT is done 97 locally at each B4 called light weight B4 or lwB4. Unicast lw4o6 98 takes user IPv4 packets from the local LAN and lwB4 does a NAPT and 99 then tunnels the packets in an IPv4-in-IPv6 tunnel to lwAFTR which 100 decapsulates the packet and then sends it to IPv4 network. Incoming 101 packets follow reverse route and are encapsulated at lwAFTR and sent 102 to lwB4 which decapsulates and after NAPT operation transmits to the 103 destination. 105 It should be noted that there is no depletion problem for IPv4 106 address space allocated for any source multicast and source specific 107 multicast [RFC3171]. This document is not motivated by the depletion 108 of IPv4 multicast addresses. 110 MAP-E, MAP-T, 4rd and lw4o6 are unicast only. They do not support 111 multicast. In this document we specify how multicast from home IPv4 112 users can be supported in MAP-E (as well as MAP-T and 4rd) and lw4o6. 114 In case IPv6 network is multicast enabled, MAP-T/4rd can provide 115 multicast service to the hosts using MAP-T/4rd Multicast Translation 116 based solution. A Multicast Translator can be used that receives 117 IPv4 multicast group management messages in IGMP and generates 118 corresponding IPv6 group management messages in MLD and sends them to 119 IPv6 network towards MAP-T/4rd Border Relay. We use 120 [I-D.ietf-softwire-map-t] or [I-D.ietf-softwire-4rd] for sending IPv4 121 multicast data in IPv6 to the CE routers. At MAP-T/4rd CE router 122 another translator is needed to translate IPv6 multicast data into 123 IPv4 multicast data. 125 It should be noted that if IPv6 network is multicast enabled the 126 translation multicast solution presented in Section 4 can also be 127 used for MAP-E. 129 In this document we address MAP-E (and MAP-T/4rd) and lw4o6 multicast 130 problem and propose the architecture of Multicast Translation based 131 solution. Section 2 is on terminology, Section 3 is on architecture, 132 Section 4 is on multicast translation protocol, and Section 5 states 133 security considerations. 135 2. Terminology 137 This document uses the terminology defined in 138 [I-D.ietf-softwire-map], [I-D.ietf-softwire-lw4over6], 139 [I-D.ietf-softwire-map-t], [I-D.ietf-softwire-4rd], [RFC3810] and 140 [RFC3376]. 142 3. Architecture 144 In MAP-E, MAP-T and 4rd, there are hosts (possibly IPv4/ IPv6 dual 145 stack) served by MAP-E, MAP-T and 4rd Customer Edge device. CE is 146 dual stack facing the hosts and IPv6 only facing the network or WAN 147 side. MAP-E, MAP-T and 4rd CE may be local IPv4 Network Address and 148 Port Translation (NAPT) box [RFC3022] by assigning private IPv4 149 addresses to the hosts. MAP-E, MAP-T and 4rd CEs in the same domain 150 may use shared public IPv4 addresses on their WAN side and if they do 151 they should avoid ports outside of the allocated port set for NAPT 152 operation. At the boundary of the network there is MAP-E, MAP-T and 153 4rd Border Relay. BR receives IPv4 packets tunneled in IPv6 from CE 154 and decapsulates them and sends them out to IPv4 network. 156 Unicast MAP-E, MAP-T and 4rd are stateless except for the local NAPT 157 at the CE. Each IPv4 packet sent by CE treated separately and 158 different packets from the same CE may go to different BRs or CEs. 159 CE encapsulates IPv4 packet in IPv6 with destination address set to 160 BR address (usually anycast IPv6 address). BR receives the 161 encapsulated packet and decapsulates and send it to IPv4 network. 162 CEs are configured with Rule IPv4 Prefixes, Rule IPv6 Prefixes and 163 with an BR IPv6 anycast address. BR receives IPv4 packets addressed 164 to this ISP and from the destination address it extracts the 165 destination host's IPv4 address and uses this address as destination 166 address and encapsulates the IPv4 packet in IPv6 and sends it to 167 IPv6-only network. 169 Unicast Lightweight 4over6 (lw4o6) is a variation of Dual-Stack Lite 170 (DS-Lite) [RFC6333] which moves carrier-grade IPv4-IPv4 NAT from the 171 Address Family Transition Router (AFTR) element to the Basic Bridging 172 BroadBand (B4) element [I-D.ietf-softwire-lw4over6]. The resulting 173 elements are called lwAFTR and lwB4 with NAPT, respectively. Lw4o6 174 also adopts some features from MAP-E. A+P scheme of public IPv4 175 address sharing is used by lwB4's in assigning WAN side IPv4 public 176 addresses with a distinct port set. As in MAP-E, encapsulation of 177 IPv4 packets in IPv6 and decapsulation is according to [RFC2473]. 179 3.1. MAP-T and 4rd Translation Architecture 181 In case IPv6 only network is multicast enabled, translation multicast 182 architecture can be used. CE implements IGMP Proxy function 183 [RFC4605] towards the LAN side and MLD Proxy on its WAN interface. 184 IPv4 hosts send their join requests (IGMP Membership Report messages) 185 to CE. CE as a MLD proxy sends aggregated MLD Report messages 186 upstream towards BR. CE replies MLD membership query messages with 187 MLD membership report messages based on IGMP membership state in the 188 IGMP/MLD proxy. 190 BR is MLD querier on its WAN side. On its interface to IPv4 network 191 BR may either have IGMP client or PIM. PIM being able to support 192 both IPv4 and IPv6 multicast should be preferred. BR receives MLD 193 join requests, extracts IPv4 multicast group address and then joins 194 the group upstream, possibly by issuing a PIM join message. 196 IPv4 multicast data received by the BR as a leaf node in IPv4 197 multicast distribution tree is translated into IPv6 multicast data by 198 the translator using [I-D.ietf-softwire-map-t], 199 [I-D.ietf-softwire-4rd] and then sent downstream to the IPv6 part of 200 the multicast tree to all downstream routers that are members. IPv6 201 data packet eventually gets to the CE. At the CE, a reverse 202 [I-D.ietf-softwire-map-t], [I-D.ietf-softwire-4rd] operation takes 203 place by the translator and then IPv4 multicast data packet is sent 204 to the member hosts on the LAN interface. [I-D.ietf-softwire-map-t], 205 [I-D.ietf-softwire-4rd] are modified to handle multicast addresses. 207 In order to support SSM, IGMPv3 MUST be supported by the host, CE and 208 BR. For ASM, BR MUST be the Rendezvous Point (RP). 210 MAP-T and 4rd Translation Multicast solution uses the multicast 46 211 translator in not one but two places in the architecture: at the CE 212 router and at the Border Relay. IPv4 multicast data received at 4rd 213 BR goes through a [I-D.ietf-softwire-4rd] header-mapping into IPv6 214 multicast data at the BR and another [I-D.ietf-softwire-4rd] header- 215 mapping back to IPv4 multicast data at the CE router. Encapsulation 216 variant of [I-D.ietf-softwire-4rd] is not used. In case of MAP-T, 217 IPv4 data packet is translated using v4 to v6 header translation 218 using multicast addresses instead of the mapping algorithm used in 219 [I-D.ietf-softwire-map-t]. 221 All the elements of MAP-T and 4rd translation-based multicast support 222 system are shown in Figure 1. 224 Dual Stack Hosts IPv4 225 +----+ Network 226 | H1 | +----------+ IPv6 +-------------+ 227 | | | CE | | BR | 228 +----+ |Translator| only | Translator | 229 |MAP-T/4rd | | MAP-T/4rd | 230 +----+ | | network | |IGMP| + 231 | H2 | ---|IGMP-MLD |--------- -- |MLD | or | IPv6 232 +----+ | Proxy | |Querier |PIM | Network 233 +----+ +----------+ +-------------+ 234 | H3 | 235 +----+ 237 Figure 1: Architecture of MAP-T and 4rd Translation Multicast 239 In case IPv6 only network is multicast enabled, translation multicast 240 architecture can also be used for lw4o6 multicast. lwB4 implements 241 IGMP Proxy function [RFC4605] towards the LAN side and MLD Proxy on 242 its WAN interface. IPv4 hosts send their join requests (IGMP 243 Membership Report messages) to lwB4. lwB4 as a MLD proxy sends 244 aggregated MLD Report messages upstream towards lwAFTR. lwB4 replies 245 MLD membership query messages with MLD membership report messages 246 based on IGMP membership state in the IGMP/MLD proxy. 248 lwAFTR is MLD querier on its WAN side. On its interface to IPv4 249 network lwAFTR may either have IGMP client or PIM. PIM being able to 250 support both IPv4 and IPv6 multicast should be preferred. lwAFTR 251 receives MLD join requests, extracts IPv4 multicast group address and 252 then joins the group upstream, possibly by issuing a PIM join 253 message. 255 For multicast data, [I-D.ietf-softwire-dslite-multicast] uses 256 encapsulation of IPv4 multicast data in IPv6 multicast data packet 257 but in this document we use translation. IPv4 multicast data 258 received by the lwAFTR as a leaf node in IPv4 multicast distribution 259 tree is translated into IPv6 multicast data by the translator and 260 then sent downstream to the IPv6 part of the multicast tree to all 261 downstream routers that are members. IPv6 data packet eventually 262 gets to the lwB4. At the lwB4, a reverse translation operation takes 263 place by the translator and then IPv4 multicast data packet is sent 264 to the member hosts on the LAN interface. The translation algorithm 265 in [I-D.ietf-softwire-map-t], [I-D.ietf-softwire-4rd] are modified to 266 handle multicast addresses. 268 In order to support SSM, IGMPv3 MUST be supported by the host, lwB4 269 and lwAFTR. For ASM, lwAFTR MUST be the Rendezvous Point (RP). 271 MAP-T and 4rd Translation Multicast solution uses the multicast 46 272 translator in not one but two places in the architecture: at the lwB4 273 router and at the lwAFTR. IPv4 data packet is translated using v4 to 274 v6 header translation using multicast addresses instead of the 275 mapping algorithm used in [I-D.ietf-softwire-map-t]. 277 All the elements of lw4o6 translation-based multicast support system 278 are shown in Figure 2. 280 IPv4 281 +-------+ IPv4 Network 282 | |Multicast 283 | | +--------------+ +--------------+ + 284 | | | lwB4 NAPT |IPv6 | lwAFTR | 285 | IPv4 |----->| IGMP MLD |----->|IGMP | IGMP | IPv6 286 | LAN |<-----| Proxy Proxy |------|Router| PIM | Network 287 | | +--------------+ +--------------+ 288 | | 289 +-------+ 291 Figure 2: Architecture of lw4o6 Multicast Translation 293 4. MAP-T and 4rd Translation Multicast Operation 295 In this section we specify how the host can subscribe and receive 296 IPv4 multicast data from IPv4 content providers based on the 297 architecture defined in Figure 1 in two parts: address translation 298 and protocol translation. Translation details are given in 299 Appendix A. 301 4.1. Address Translation 303 IPv4-only host, H1 will join IPv4 multicast group by sending IGMP 304 Membership Report message upstream towards the IGMP Proxy in 305 Figure 1. MLD Proxy first creates a synthesized IPv6 address of IPv4 306 multicast group address using IPv4-embedded IPv6 multicast address 307 format [I-D.ietf-mboned-64-multicast-address-format]. ASM_MPREFIX64 308 for any source multicast groups and SSM_MPREFIX64 for source specific 309 multicast groups are used. Both are /96 prefixes. 311 SSM_MPREFIX64 is set to ff3x:0:8000::/96, with 'x' set to any valid 312 scope. ASM_MPREFIX64 values are formed as shown in Figure 3. Flag 313 field 1 (ff1) field is defined in [RFC7371] bits M bit MUST BE set to 314 1. "scop" field is defined in [RFC3956]. Flag field 2 (ff2) is a set 315 of 4 flags rrrM where r bits MUST be set to zero. M bit is set to 1 316 to indicate that a multicast IPv4 address is embedded in the low- 317 order 32 bits of the multicast IPv6 address. "sub-group-id" field 318 MUST follow the recommendations specified in [RFC3306] if unicast- 319 based prefix is used or the recommendations specified in [RFC3956] if 320 embedded-RP is used. The default value is all zeros. 322 | 8 | 4 | 4 | 4 | 76 | 32 | 323 +--------+----+----+----+------------------------------+----------+ 324 |11111111|ff1 |scop|ff2 | sub-group-id |v4 address| 325 +--------+----+----+----+-----------------------------------------+ 327 Figure 3: ASM_MPREFIX64 Formation 329 Each translator in the upstream BR is assigned a unique ASM_MPREFIX64 330 prefix. CE (MLD Proxy in CE) can learn this value by means out of 331 scope with this document. With this, CE can easily create an IPv6 332 multicast address from the IPv4 group address a.b.c.d that the host 333 wants to join. 335 Source-Specific Multicast (SSM) can also be supported similar to the 336 Any Source Multicast (ASM) described above. In case of SSM, IPv4 337 multicast addresses use 232.0.0.0/8 prefix. IPv6 SSM_MPREFIX64 is 338 set to FF3x:0:8000::/96 where 'x' is any valid scope. 340 Since SSM translation requires a unique address for each IPv4 341 multicast source, an IPv6 unicast prefix must be configured to the 342 translator in the upstream BR to represent IPv4 sources. This prefix 343 is prepended to IPv4 source addresses in translated packets. 345 The join message from the host for the group ASM_MPREFIX64:a.b.c.d or 346 SSM_MPREFIX64:a.b.c.d or an aggregate join message will be received 347 by MLD querier at the BR. BR as multicast anchor checks the group 348 address and recognizes ASM_MPREFIX64 or SSM_MPREFIX64 prefix. It 349 next checks the last 32 bits is an IPv4 multicast address in range 350 224/8 - 239/8. If all checks succeed, IGMPv4 Client joins a.b.c.d 351 using IGMP on its IPv4 interface. 353 Joining IPv4 groups can also be done using PIM since PIM supports 354 both IPv4 and IPv6. The advantage of using PIM is that there is no 355 need to enable IGMP support in neighboring IPv4 routers. The 356 advantage of using IGMP is that IGMP is a simpler protocol and it is 357 supported by a wider range of routers. The use of PIM or IGMP is 358 left as an implementation choice. 360 Address translation described above for MAP-T applies to lw4over6 361 multicast translation where the entities involved are lwB4 replaces 362 Customer Edge device and lwAFTR replaces BR Figure 2. 364 4.2. Protocol Translation 366 The hosts will send their subscription requests for IPv4 multicast 367 groups upstream to the default router, i.e. Costumer Edge device. 368 After subscribing the group, the host can receive multicast data from 369 the CE. The host implements IGMP protocol's host part. 371 Customer Edge device is IGMP Proxy facing the LAN interface. After 372 receiving the first IGMP Report message requesting subscription to an 373 IPv4 multicast group, a.b.c.d, MLD Proxy in the CE's WAN interface 374 synthesizes an IPv6 multicast group address corresponding to a.b.c.d 375 and sends an MLD Report message upstream to join the group. 377 When MAP-T or 4rd BR receives IPv4 multicast data for an IPv4 group 378 a.b.c.d it [I-D.ietf-softwire-4rd] translates/encapsulates IPv4 379 packet into IPv6 multicast packet and sends it to IPv6 synthesized 380 address corresponding to a.b.c.d using ASM_MPREFIX64 or 381 SSM_MPREFIX64. The header mapping described in 382 [I-D.ietf-softwire-4rd] Section 4.2 (using Table 1) is used except 383 for mapping the source and destination addresses. In this document 384 we use the multicast address translation described in Section 4.1 and 385 propose it as a complementary enhancement to the translation 386 algorithm in [I-D.ietf-softwire-4rd]. 388 The IP/ICMP translation translates IPv4 packets into IPv6 using 389 minimum MTU size of 1280 bytes (Section 4.3 in 390 [I-D.ietf-softwire-4rd]) but this can be changed for multicast. Path 391 MTU discovery for multicast is possible in IPv6 so 4rd BR can perform 392 path MTU discovery for each ASM group and use these values instead of 393 1280. For SSM, a different MTU value MUST be kept for each SSM 394 channel. Because of this 8 bytes added by IPv6 fragment header in 395 each data packet can be tolerated. 397 Since multicast address translation does not preserve checksum 398 neutrality, [I-D.ietf-softwire-4rd] translator/encapsulator at 4rd BR 399 must however modify the UDP checksum to replace the IPv4 addresses 400 with the IPv6 source and destination addresses in the pseudo-header 401 which consists of source address, destination address, protocol and 402 UDP length fields before calculating the new checksum. 404 IPv6 multicast data must be translated back to IPv4 at the 4rd CE 405 (e.g. using Table 2 in Section 4.3 of [I-D.ietf-softwire-4rd]). Such 406 a task is much simpler than the translation at 4rd BR because IPv6 407 header is much simpler than IPv4 header and IPv4 link on the LAN side 408 of 4rd CE is a local link. The packet is sent on the local link to 409 IPv4 group address a.b.c.d for IPv6 group address of 410 ASM_MPREFIX64:a.b.c.d or SSM_MPREFIX64:a.b.c.d. 412 In case an IPv4 multicast source sends multicast data with the don't 413 fragment (DF) flag set to 1, [I-D.ietf-softwire-4rd] header mapping 414 sets the D bit in IPv6 fragment header before sending the packet 415 downstream as in Fig. 3 in Section 4.3 of [I-D.ietf-softwire-4rd]. 416 This feature of [I-D.ietf-softwire-4rd] preserves the semantics of DF 417 flag at the BR and CE. 419 Because MAP-T/4rd is stateless, Multicast MAP-T/4rd should stay 420 faithful to this as much as possible. Border Relay acts as the 421 default multicast querier for all CEs that have established multicast 422 communication with it. In order to keep a consistent multicast state 423 between a CE and BR, CE MUST use the same IPv6 multicast prefixes 424 (ASM_MPREFIX64/SSM_REFIX64) until the state becomes empty. After 425 that point, the CE may obtain different values for these prefixes, 426 effectively changing to a different 4rd BR. 428 Protocol translation described above for MAP-T applies to lw4over6 429 multicast translation where the entities involved are lwB4 replaces 430 Customer Edge device and lwAFTR replaces BR Figure 2. 432 4.3. Learning Multicast Prefixes for IPv4-embedded IPv6 Multicast 433 Addresses 435 CE can be pre-configured with Multicast Prefix64 of ASM_MPREFIX64 and 436 SSM_MPREFIX64 that are supported in their network. However 437 automating this process is also desired. 439 A new router advertisement option, a Multicast ASM Translation Prefix 440 option, can be defined for this purpose. The option contains IPv6 441 ASM multicast translation prefix, ASM_MPREFIX64. A new router 442 advertisement option, a Multicast SSM Translation Prefix option, can 443 be defined for this purpose. The option contains IPv6 SSM multicast 444 prefix translation prefix SSM_MPREFIX64. 446 After the host gets the multicast prefixes, when an application in 447 the host wishes to join an IPv4 multicast group the host MUST use 448 ASM_MPREFIX64 or SSM_MPREFIX64 and then obtain the synthesized IPv6 449 group address before sending MLD join message. 451 Source-specific multicast (SSM) group membership message payloads in 452 IGMPv3 and MLDv2 contain address literals and their translation 453 requires another multicast translation prefix option. IPv4 source 454 addresses in IGMPv3 Membership Report message are unicast addresses 455 of IPv4 sources and they have to be translated into unicast IPv6 456 source addresses in MLDv2 Membership Report message. A new router 457 advertisement option, a Multicast Translation Unicast Prefix option 458 can be defined for this purpose. The option contains IPv6 unicast 459 Network-Specific Prefix U_PREFIX64. The host can be configured by 460 its default router using router advertisements containing the 461 prefixes [I-D.sarikaya-softwire-6man-raoptions]. 64:ff9b::/96 is the 462 global value called well-known prefix that is assigned to U_PREFIX64 463 [RFC6052]. Organization specific values called Network-Specific 464 Prefixes can also be used. Since multicast is potentially inter- 465 domain, the use of well-known prefix for U_PREFIX64 is recommended. 466 DHCP servers can also configure hosts with ASM_MPREFIX64, 467 SSM_MPREFIX64 and U_PREFIX64 as in 468 [I-D.ietf-softwire-multicast-prefix-option]. 470 Note that U_PREFIX64 is also used in multicast data packet address 471 translation. Source-specific multicast source address in multicast 472 data packets coming from SSM sources MUST be translated using 473 U_PREFIX64. 475 4.4. Supporting IPv4 Multicast at CE Router and lwB4 477 When MAP-E CE router is a NAT or NAPT box assigning private IPv4 478 addresses to the hosts, IP Multicast requirements for a Network 479 Address Translator (NAT) and a Network Address Port Translator (NAPT) 480 stated in [RFC5135] apply to IGMP messages and IPv4 multicast data 481 packets. The same applies to lwB4s in lw4over6. 483 On receiving multicast data packets, lwB4 or CE router MUST NOT 484 modify destination IP address or destination port of the packets. 485 Multicast UDP datagrams MUST be forwarded to the local LAN towards 486 the host that is a member of this group. 488 IGMP membership reports received at lwB4 or CE router may be sent 489 upstream individually for any source multicast but for source 490 specific multicast, e.g. IGMPv3, membership reports MUST be sent 491 after IGMP aggregation. 493 5. Security Considerations 495 Multicast control and data message security can be provided by the 496 security architecture, mechanisms, and services described in 497 [RFC4301], [RFC4302] and [RFC4303]. and in [RFC4607] for source 498 specific multicast. 500 6. IANA Considerations 502 TBD. 504 7. Acknowledgements 506 TBD. 508 8. References 510 8.1. Normative References 512 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 513 Requirement Levels", BCP 14, RFC 2119, March 1997. 515 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 516 June 1999. 518 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 519 RFC 1112, August 1989. 521 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 522 1997. 524 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 525 RFC 2711, October 1999. 527 [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, 528 "IANA Guidelines for IPv4 Multicast Address Assignments", 529 RFC 3171, August 2001. 531 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 532 "Internet Group Management Protocol (IGMP) / Multicast 533 Listener Discovery (MLD)-Based Multicast Forwarding 534 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 536 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 537 IP", RFC 4607, August 2006. 539 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 540 Addresses", RFC 3307, August 2002. 542 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 543 over Non-Broadcast Multiple Access (NBMA) networks", RFC 544 2491, January 1999. 546 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 547 IPv6 Specification", RFC 2473, December 1998. 549 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 550 (SIIT)", RFC 2765, February 2000. 552 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 553 Address Translator (Traditional NAT)", RFC 3022, January 554 2001. 556 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 557 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 559 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 560 Thyagarajan, "Internet Group Management Protocol, Version 561 3", RFC 3376, October 2002. 563 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 564 for IPv6 Hosts and Routers", RFC 4213, October 2005. 566 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 567 Internet Protocol", RFC 4301, December 2005. 569 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 570 2005. 572 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 573 4303, December 2005. 575 [RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a 576 Network Address Translator (NAT) and a Network Address 577 Port Translator (NAPT)", BCP 135, RFC 5135, February 2008. 579 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 580 Algorithm", RFC 6145, April 2011. 582 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 583 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 584 October 2010. 586 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 587 Stack Lite Broadband Deployments Following IPv4 588 Exhaustion", RFC 6333, August 2011. 590 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 591 in IPv6", RFC 6275, July 2011. 593 [RFC7371] Boucadair, M. and S. Venaas, "Updates to the IPv6 594 Multicast Addressing Architecture", RFC 7371, September 595 2014. 597 [I-D.ietf-softwire-map] 598 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 599 Murakami, T., and T. Taylor, "Mapping of Address and Port 600 with Encapsulation (MAP)", draft-ietf-softwire-map-13 601 (work in progress), March 2015. 603 [I-D.ietf-softwire-lw4over6] 604 Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and 605 I. Farrer, "Lightweight 4over6: An Extension to the DS- 606 Lite Architecture", draft-ietf-softwire-lw4over6-13 (work 607 in progress), November 2014. 609 [I-D.ietf-softwire-map-t] 610 Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and 611 T. Murakami, "Mapping of Address and Port using 612 Translation (MAP-T)", draft-ietf-softwire-map-t-08 (work 613 in progress), December 2014. 615 [I-D.ietf-softwire-4rd] 616 Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and 617 M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless 618 Solution (4rd)", draft-ietf-softwire-4rd-10 (work in 619 progress), December 2014. 621 [I-D.ietf-mboned-64-multicast-address-format] 622 Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and 623 M. Xu, "IPv6 Multicast Address With Embedded IPv4 624 Multicast Address", draft-ietf-mboned-64-multicast- 625 address-format-06 (work in progress), September 2014. 627 [I-D.ietf-softwire-multicast-prefix-option] 628 Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 629 Option for IPv4-Embedded Multicast and Unicast IPv6 630 Prefixes", draft-ietf-softwire-multicast-prefix-option-08 631 (work in progress), March 2015. 633 8.2. Informative references 635 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 636 Multicast Addresses", RFC 3306, August 2002. 638 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 639 Point (RP) Address in an IPv6 Multicast Address", RFC 640 3956, November 2004. 642 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 643 Architecture", RFC 4291, February 2006. 645 [I-D.ietf-softwire-dslite-multicast] 646 Qin, J., Boucadair, M., Jacquenet, C., Lee, Y., and Q. 647 Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients 648 over an IPv6 Multicast Network", draft-ietf-softwire- 649 dslite-multicast-09 (work in progress), March 2015. 651 [I-D.sarikaya-softwire-6man-raoptions] 652 Sarikaya, B., "IPv6 RA Options for Translation Multicast 653 Prefixes", draft-sarikaya-softwire-6man-raoptions-01 (work 654 in progress), February 2013. 656 [I-D.perreault-mboned-igmp-mld-translation] 657 Perreault, S. and T. Tsou, "Internet Group Management 658 Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based 659 Multicast Translation ("IGMP/MLD Translation")", draft- 660 perreault-mboned-igmp-mld-translation-01 (work in 661 progress), April 2012. 663 Appendix A. Group Membership Message Translation Details 665 IGMP Report messages (IGMP type number 0x12 and 0x16, in IGMPv1 and 666 IGMPv2 and 0x22 in IGMPv3) are translated into MLD Report messages 667 (MLDv1 ICMPv6 type number 0x83 and MLDv2 type number 0x8f). IGMP 668 Query message (IGMP type number 0x11) is translated into MLD Query 669 message (ICMPv6 type number 0x82) 670 [I-D.perreault-mboned-igmp-mld-translation]. 672 Destination address in ASM, i.e. IGMPv1, IGMPv2 and MLDv1, is the 673 multicast group address so the destination address in IGMP message is 674 translated into the destination address in MLD message using 675 [I-D.ietf-mboned-64-multicast-address-format]. 677 Destination address in SSM, i.e. IGMPv3 and MLDv2 is translated as 678 follows: it could be all nodes on link, which has the value of 679 224.0.0.1 (IGMPv3) and ff02::1 (MLDv2), all routers on link, which 680 has the value of 224.0.0.2 (IGMPv3) and ff02::2 (MLDv2), all IGMP/ 681 MLD-capable routers on link, which has the value of 224.0.0.22 682 (IGMPv3) and ff02::16 (MLDv2). 684 Source address of MLD message that CE sends is set to link-local IPv6 685 address of CE's WAN side interface. Source address of MLD message 686 that BR sends is set to link-local IPv6 address of BR's downstream 687 interface. 689 Multicast Address or Group Address field in IGMP message payloads is 690 translated using [I-D.ietf-mboned-64-multicast-address-format] as 691 described above into the corresponding field in MLD message. 693 Source Address in IGMPv3 message payloads is translated using 694 U_PREFIX64, the IPv6 unicast prefix to be used by SSM source. 695 [RFC6052] defines in Section 2.3 the address translation algorithm of 696 embedding an IPv4 source address and obtaining an IPv6 source address 697 using a network specific prefix like U_PREFIX64. At the BR on its 698 upstream interface or at the CE on its LAN interface, IPv4 addresses 699 are extracted from the IPv4-embedded IPv6 addresses. 701 Maximum Response Time (MRT) field in IGMPv2 and IGMPv3 queries are 702 translated into Maximum Response Delay (MRD) in MLDv1 and MLDv2 703 queries, respectively. In the corresponding MLD message, MRD is set 704 to 100 times the value of MRT. At the BR on its upstream interface 705 or at the CE on its LAN interface, MRT value is obtained by dividing 706 MRD into 100 and rounding it to the nearest integer. 708 IGMP messages are sent with a Router Alert IPv4 option [RFC2113]. 709 The translated MLD message are sent with a Router Alert option in a 710 Hop-By-Hop IPv6 extension header [RFC2711]. In both cases, 2-octet 711 value is set to 0. 713 Authors' Addresses 715 Behcet Sarikaya 716 Huawei USA 717 5340 Legacy Dr. Building 175 718 Plano, TX 75024 720 Email: sarikaya@ieee.org 722 Hui Ji 723 China Telecom 724 NO19.North Street 725 Beijing, Chaoyangmen,Dongcheng District 726 P.R. China 728 Email: jihui@chinatelecom.com.cn