idnits 2.17.1 draft-sarikaya-softwire-dslite6rdmulticast-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 == 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 (March 7, 2011) is 4791 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 417, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 420, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) ** Downref: Normative reference to an Informational RFC: RFC 5569 == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-07 ** Downref: Normative reference to an Informational draft: draft-ietf-multimob-pmipv6-base-solution (ref. 'I-D.ietf-multimob-pmipv6-base-solution') Summary: 3 errors (**), 0 flaws (~~), 5 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 March 7, 2011 5 Expires: September 8, 2011 7 Multicast Support for Dual Stack Lite and 6RD 8 draft-sarikaya-softwire-dslite6rdmulticast-00.txt 10 Abstract 12 This memo specifies modifications required to DS-Lite and 6RD so that 13 both IPv4/ IPv6 hosts can receive multicast data from IPv4/ IPv6 14 servers. 16 The DS-Lite solution is based on DS-Lite Basic Bridging BroadBand 17 element (B4) proxying IGMP and then tunneling IGMP messages to DS- 18 Lite Address Family Transition Router element (AFTR). IPv4 multicast 19 data received at AFTR is tunneled to B$ and then delivered to the 20 hosts. IPv6 multicast and MLD can be supported in a similar way. 22 The 6RD protocol is based on proxying MLD at the 6RD Customer Edge 23 and then tunneling MLD messages to 6RD Border Relays where IPv6 24 multicast routing is supported. Multicast data received at 6RD 25 Border Relay is tunneled to 6RD Customer Edge node and then delivered 26 to the hosts. We show that IPv4 multicast and IGMP can be supported 27 in a similar way. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 8, 2011. 46 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 5. DS-Lite Multicast Operation . . . . . . . . . . . . . . . . . 5 68 5.1. Tunnel Interface Considerations . . . . . . . . . . . . . 7 69 5.2. Supporting IPv6 Multicast in DS-Lite . . . . . . . . . . . 7 70 6. 6RD Multicast Operation . . . . . . . . . . . . . . . . . . . 7 71 6.1. Tunnel Interface Considerations . . . . . . . . . . . . . 9 72 6.2. Supporting IPv4 Multicast in 6RD . . . . . . . . . . . . . 9 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 78 10.2. Informative references . . . . . . . . . . . . . . . . . . 11 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 With IPv4 address depletion on the horizon, many techniques are being 84 standardized for IPv6 migration including DS-Lite 85 [I-D.ietf-softwire-dual-stack-lite] and 6RD [RFC5969]. DS-Lite 86 enables IPv4 hosts to communicate with external hosts using IPv6 only 87 network and moves the traditional NAT to the network. B4 element's 88 LAN side is dual stack and WAN side is IPv6 only. B4 tunnels IPv4 89 packets received from the LAN side to AFTR element after 90 encapsulating IPv4 packet in an IPv6 packet. AFTR decapsulates the 91 packet, does a NAT operation and then sends the packet out to IPv4 92 public internet. 94 6RD enables IPv6 hosts to communicate with external hosts using IPv4 95 only legacy ISP network. 6RD Customer Edge (CE) device's LAN side is 96 dual stack and WAN side is IPv4 only. CE tunnels IPv6 packets 97 received from the LAN side to 6RD Border Relays (BR) after 98 encapsulating IPv6 packet in an IPv4 packet. BRs have anycast IPv4 99 addresses and receive encapsulated packets from CEs over a virtual 100 interface. 6RD operation is stateless. Packets are received/ sent 101 independent of each other and no state needs to be maintained. 103 DS-Lite as defined in [I-D.ietf-softwire-dual-stack-lite] is unicast 104 only, it does not support multicast. In this document we specify how 105 multicast from home IPv4 users can be supported in DS-Lite. We also 106 show how IPv6 multicast can be supported for home IPv6 users in DS- 107 Lite. 109 6RD as defined in [RFC5969] and [RFC5569] is unicast only. It does 110 not support multicast. In this document we specify how multicast 111 from home IPv6 users can be supported in 6RD. We also show how IPv4 112 multicast can be supported for home IPv4 users. Both solutions use 113 IPv6 and IPv4 multicast addressing and do not require any new 114 multicast address prefixes such as IPv4-embedded IPv6 multicast 115 addresses to be allocated. 117 2. Terminology 119 This document uses the terminology defined in [RFC5969], [RFC5569], 120 [RFC3810] and [RFC3376]. 122 3. Requirements 124 This section states requirements on DS-Lite and 6RD multicast support 125 protocol. 127 DS-Lite B4 MUST support IGMP Proxy as defined in [RFC4605]. DS-Lite 128 B4 MAY support MLD Proxy. 130 DS-Lite AFTR MUST support IGMP Querrier. DS-Lite AFTR MAY support 131 MLD Querrier. 133 6RD CE MUST support MLD Proxy as defined in [RFC4605]. 6RD CE MAY 134 support IGMP Proxy. 136 6RD BR MUST support MLD Querrier. 6RD CE MAY support IGMP Querrier. 138 Both any source multicast (ASM) and source specific multicast (SSM) 139 MUST be supported. 141 4. Architecture 143 In DS-Lite, there are hosts (possibly IPv4/ IPv6 dual stack) served 144 by B4 element. B4 is dual stack facing the hosts and IPv6 only 145 facing the network or WAN side. At the boundary of the network there 146 is AFTR. AFTR receives IPv4 packets tunneled in IPv6 from B4 and 147 decapsulates them and sends them out to IPv4 network. 149 In order to support multicast B4 implements IGMP Proxy function 150 [RFC4605]. IPv4 hosts send their join requests (IGMP Membership 151 Report messages) to B4. B4 as a proxy sends aggregated Report 152 messages upstream towards AFTR. 154 AFTR is the default multicast querier for B4. AFTR implements 155 multicast router function or it could be another IGMP proxy. 157 All the elements of DS-Lite multicast support system are shown in 158 Figure 1. 160 Dual Stack Hosts IPv4 161 +----+ Network 162 | H1 | IPv6 163 +----+ +-----+ only +-------+ + 164 +----+ | B4 | network -- | AFTR | 165 | H2 | ---| IGMP|--- | IGMP | IPv6 166 +----+ |Proxy| |Querier| Network 167 +----+ +-----+ +-------+ 168 | H3 | 169 +----+ 171 Figure 1: Architecture of DS-Lite Multicast Protocol 173 In 6RD, there are hosts (possibly IPv4/ IPv6 dual stack) served by 174 6RD Customer Edge device. CE is dual stack facing the hosts and IPv4 175 only facing the network or WAN side. At the boundary of the network 176 there is 6RD Border Relay. BR receives IPv6 packets tunneled in IPv4 177 from CE and decapsulates them and sends them out to IPv6 network. 179 In order to support multicast CE implements MLD Proxy function 180 [RFC4605]. IPv6 hosts send their join requests (MLD Membership 181 Report messages) to CE. CE as a proxy sends aggregated Report 182 messages upstream towards BR. 184 Dual Stack Hosts IPv4 185 +----+ Network 186 | H1 | IPv4 187 +----+ +-----+ only +-------+ + 188 +----+ | CE | network -- | BR | 189 | H2 | ---| MLD |--- | MLD | IPv6 190 +----+ |Proxy| |Querier| Network 191 +----+ +-----+ +-------+ 192 | H3 | 193 +----+ 195 Figure 2: Architecture of 6RD Multicast Protocol 197 BR is the default multicast querier for CE. BR implements multicast 198 router function or it could be another MLD proxy. 200 All the elements of 6RD multicast support system are shown in 201 Figure 2. 203 5. DS-Lite Multicast Operation 205 In this section we specify how the host can subscribe and receive 206 IPv4 multicast data from IPv4 content providers based on the 207 architecture defined in Section 4. 209 The hosts will send their subscription requests for IPv4 multicast 210 groups upstream to the default router, i.e. B4 Element. After 211 subscribing to the group, the host can receive multicast data from 212 the B4. The host implements IGMP protocol's host part. 214 B4 Element is IGMP Proxy. After receiving the first IGMP Report 215 message requesting subscription to an IPv4 multicast group, B4 216 establishes a tunnel interface with a AFTR. The tunnel is IPv6 based 217 but it will carry IP traffic, IGMP messages back and forth and IPv4 218 multicast data messages downstream. This is similar to 219 [I-D.ietf-multimob-pmipv6-base-solution] but the operation is much 220 simpler. In DS-Lite environment there is no requirement to handle 221 host mobility. B4 does not have to keep more than one tunnel 222 interfaces, a single interface is sufficient. IGMP Proxy at the B4 223 does not have to have more than one proxy instances, a single 224 instance is sufficient. 226 B4 is regular IGMP proxy and it keeps IGMP proxy membership database. 227 B4 inserts multicast forwarding state on the incoming interface, and 228 merges state updates into the IGMP proxy membership database. B4 229 updates or removes elements from the database as required. B4 will 230 then send an aggregated Report via the upstream tunnel to the AFTR 231 when the membership database changes. 233 B4 answers IGMP queries from AFTR based on the membership database. 234 B4's downstream link follows the traditional multipoint channel 235 forwarding and does not pose any specific problems. 237 B4 receives IPv4 multicast data from the AFTR tunneled over the 238 tunnel interface. B4 decapsulates the packet and then forwards it 239 downstream. Each member host receives the data packet based on Layer 240 2 multicast interface. No packet duplication is necessary. 242 AFTR acts as the as the default multicast querier for all B4s that 243 have established an IPv6 tunnel with it. In order to keep a 244 consistent multicast state between a B4 and AFTR, once a B4 is 245 connected it will stay connected until the state becomes empty. 246 After that point, the B4 may continue to use the tunnel for IPv4 247 unicast traffic. 249 According to aggregated IGMP reports received from a B4, AFTR 250 establishes group/source-specific multicast forwarding states at its 251 corresponding downstream tunnel interfaces. After that, AFTR 252 maintains or removes the state as required by the aggregated reports 253 received from B4. 255 At the upstream interface, AFTR procures for aggregated multicast 256 membership maintenance. Based on the multicast-transparent 257 operations of the B4s, the AFTR treats its tunnel interfaces as 258 multicast enabled downstream links, serving zero to many listening 259 nodes. 261 Multicast traffic arriving at the AFTR is transparently forwarded 262 according to its multicast forwarding information base. Multicast 263 data is first replicated and then forwarded in IPv4-in-IPv6 tunnel 264 from AFTR to the corresponding B4. 266 5.1. Tunnel Interface Considerations 268 Legacy IPv4 in IPv6 tunneling is performed as in [RFC2473]. 269 Considerations specified in [I-D.ietf-softwire-dual-stack-lite] 270 apply. Packets upstream from B4 carry only IGMP signaling messages 271 and they are not expected to fragmentation. However packets 272 downstream, i.e. multicast data to B4 may be subject to 273 fragmentation. 275 5.2. Supporting IPv6 Multicast in DS-Lite 277 IPv6 multicast can be supported in a way similar to IPv4 as described 278 in Section 5. B4 Element has MLD Proxy function. Proxy operation 279 for MLD [RFC3810] is described in [RFC4605]. 281 B4 receives MLD join requests from the hosts and then sends 282 aggregated MLD Report messages upstream in an IPv6 in IPv6 tunnel. 283 Tunnel addressing is in IPv6 and is as described in 284 [I-D.ietf-softwire-dual-stack-lite]. Multicast membership database 285 is maintained for all active IPv6 multicast groups the hosts 286 subscribe. 288 AFTR is MLD querier or another MLD Proxy. It serves all B4s 289 downstream and treats its tunnel interfaces as multicast enabled 290 downstream links, serving zero to many listening nodes. Multicast 291 membership database is maintained based on the aggregated Reports 292 received from downstream tunnel interfaces. 294 IPv6 multicast data received from the multicast Single Source 295 Multicast or Any Source Multicast sources are replicated according to 296 the multicast membership database and the data packets are tunneled 297 to the B4s that have one or more members of this multicast group. 299 B4s receive multicast data upstream in the B4-AFTR tunnel and 300 decapsulate it and then forward the packet downstream. Each member 301 host receive IPv6 multicast data packet from its Layer 2 interface. 303 6. 6RD Multicast Operation 305 In this section we specify how the host can subscribe and receive 306 IPv6 multicast data from IPv6 content providers based on the 307 architecture defined in Section 4. 309 The hosts will send their subscription requests for IPv6 multicast 310 groups upstream to the default router, i.e. Costumer Edge device. 311 After subscribing the group, the host can receive multicast data from 312 the CE. The host implements MLD protocol's host part. 314 Customer Edge device is MLD Proxy. After receiving the first MLD 315 Report message requesting subscription to an IPv6 multicast group, CE 316 establishes a tunnel interface with a Border Relay. The tunnel is 317 IPv4 based but it will carry IP traffic, MLD messages back and forth 318 and IPv6 multicast data messages downstream. This is similar to 319 [I-D.ietf-multimob-pmipv6-base-solution] but the operation is much 320 simpler. In 6RD environment there is no requirement to handle host 321 mobility. CE does not have to keep more than one tunnel interfaces, 322 a single interface is sufficient. MLD Proxy at the CE does not have 323 to have more than one proxy instances, a single instance is 324 sufficient. 326 CE is regular MLD proxy and it keeps MLD proxy membership database. 327 CE inserts multicast forwarding state on the incoming interface, and 328 merges state updates into the MLD proxy membership database. CE 329 updates or remove elements from the database as required. CE will 330 then send an aggregated Report via the upstream tunnel to the BR when 331 the membership database changes. 333 CE answers MLD queries from BR based on the membership database. 334 CE's downstream link follows the traditional multipoint channel 335 forwarding and does not pose any specific problems. 337 CE receives IPv6 multicast data from the BR tunneled over the tunnel 338 interface. CE decapsulates the packet and then forwards it 339 downstream. Each member host receives the data packet based on Layer 340 2 multicast interface. No packet duplication is necessary. 342 Border Relay acts as the as the default multicast querier for all CEs 343 that have established an IPv4 tunnel with it. In order to keep a 344 consistent multicast state between a CE and BR, once a CE is 345 connected it will stay connected until the state becomes empty. 346 After that point, the CE may establish another tunnel to a different 347 BR. 349 According to aggregated MLD reports received from a CE, BR 350 establishes group/source-specific multicast forwarding states at its 351 corresponding downstream tunnel interfaces. After that, BR maintains 352 or removes the state as required by the aggregated reports received 353 from CE. 355 At the upstream interface, BR procures for aggregated multicast 356 membership maintenance. Based on the multicast-transparent 357 operations of the CEs, the BR treats its tunnel interfaces as 358 multicast enabled downstream links, serving zero to many listening 359 nodes. 361 Multicast traffic arriving at the BR is transparently forwarded 362 according to its multicast forwarding information base. Multicast 363 data is first replicated and then forwarded in IPv6-in-IPv4 tunnel 364 from BR to the corresponding CE. 366 6.1. Tunnel Interface Considerations 368 IPv6 in IPv4 tunneling is performed as specified in [RFC4213]. 369 Considerations specified in [RFC5969] apply. Packets upstream from 370 CE carry only MLD signaling messages and they are not expected to 371 fragmentation. However packets downstream, i.e. multicast data to CE 372 may be subject to fragmentation. 374 6.2. Supporting IPv4 Multicast in 6RD 376 IPv4 multicast can be supported in a way similar to IPv6 as described 377 in Section 6. 6RD Customer Edge device has IGMP Proxy function. 378 Proxy operation for IGMP [RFC3376] is described in [RFC4605]. 380 CE receives IGMP join requests from the hosts and then sends 381 aggregated IGMP Report messages upstream in an IPv4 in IPv4 tunnel. 382 Tunnel addressing is in IPv4 and is as described in [RFC5969]. 383 Multicast membership database is maintained for all active IPv4 384 multicast groups the hosts subscribe. 386 6RD Border Relay is IGMP querier or another IGMP Proxy. It serves 387 all CEs downstream and treats its tunnel interfaces as multicast 388 enabled downstream links, serving zero to many listening nodes. 389 Multicast membership database is maintained based on the aggregated 390 Reports received from downstream tunnel interfaces. 392 IPv4 multicast data received from the multicast Single Source 393 Multicast or Any Source Multicast sources are replicated according to 394 the multicast membership database and the data packets are tunneled 395 to the CEs that have one or more members of this multicast group. 397 CEs receive multicast data upstream in the CE-BR tunnel and 398 decapsulate it and then forward the packet downstream. Each member 399 host receive IPv4 multicast data packet from its Layer 2 interface. 401 7. Security Considerations 403 TBD. 405 8. IANA Considerations 407 TBD. 409 9. Acknowledgements 411 TBD. 413 10. References 415 10.1. Normative References 417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 418 Requirement Levels", BCP 14, RFC 2119, March 1997. 420 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 421 June 1999. 423 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 424 "Internet Group Management Protocol (IGMP) / Multicast 425 Listener Discovery (MLD)-Based Multicast Forwarding 426 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 428 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 429 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 431 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 432 Thyagarajan, "Internet Group Management Protocol, Version 433 3", RFC 3376, October 2002. 435 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 436 Infrastructures (6rd)", RFC 5569, January 2010. 438 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 439 Infrastructures (6rd) -- Protocol Specification", 440 RFC 5969, August 2010. 442 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 443 IPv6 Specification", RFC 2473, December 1998. 445 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 446 for IPv6 Hosts and Routers", RFC 4213, October 2005. 448 [I-D.ietf-softwire-dual-stack-lite] 449 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 450 Stack Lite Broadband Deployments Following IPv4 451 Exhaustion", draft-ietf-softwire-dual-stack-lite-07 (work 452 in progress), March 2011. 454 [I-D.ietf-multimob-pmipv6-base-solution] 455 Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 456 Deployment for Multicast Listener Support in PMIPv6 457 Domains", draft-ietf-multimob-pmipv6-base-solution-07 458 (work in progress), December 2010. 460 10.2. Informative references 461 Author's Address 463 Behcet Sarikaya 464 Huawei USA 465 1700 Alma Dr. Suite 500 466 Plano, TX 75075 468 Phone: +1 972-509-5599 469 Email: sarikaya@ieee.org