idnits 2.17.1 draft-sarikaya-softwire-dslitemulticast-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == 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 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: DS-Lite multicast solution MUST integrate with DS-Lite unicast solution, it MUST not introduce additional mechanisms to the existing B4 to AFTR communication. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: DS-Lite multicast solution MUST not require additional capabilities in IPv6 network connecting B4 to AFTR other than what unicast DS-Lite solution requires. -- The document date (June 21, 2012) is 4325 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 312, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 315, but no explicit reference was found in the text == Unused Reference: 'RFC4286' is defined on line 347, but no explicit reference was found in the text == Unused Reference: 'RFC4541' is defined on line 350, but no explicit reference was found in the text == Unused Reference: 'RFC3810' is defined on line 355, 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 6224 Summary: 3 errors (**), 0 flaws (~~), 11 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 June 21, 2012 5 Expires: December 23, 2012 7 Multicast Support for Dual Stack Lite 8 draft-sarikaya-softwire-dslitemulticast-01.txt 10 Abstract 12 This memo specifies modifications required to Dual-Stack Lite (DS- 13 Lite) so that both IPv4 hosts can receive multicast data from IPv4 14 servers. 16 The DS-Lite solution is based on DS-Lite Basic Bridging BroadBand 17 element (B4) proxying Internet Group Management Protocol (IGMP) and 18 then tunneling IGMP messages over IPv4-in-IPv6 softwire to DS-Lite 19 Address Family Transition Router element (AFTR). IPv4 multicast data 20 received at AFTR is tunneled over IPv4-in-IPv6 softwire to B4 and 21 then delivered to the hosts. This solution integrates well with DS- 22 Lite unicast solution by using IPv4-in-IPv6 softwire and works with 23 unicast IPv6 network connecting B4 with AFTR. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 23, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 5. DS-Lite Multicast Operation . . . . . . . . . . . . . . . . . 4 64 5.1. Tunnel Interface Considerations . . . . . . . . . . . . . 6 65 6. Multicast Support for Host-Based Architecture . . . . . . . . 7 66 7. Avalanche Problem . . . . . . . . . . . . . . . . . . . . . . 7 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 71 10.2. Informative references . . . . . . . . . . . . . . . . . . 8 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Introduction 76 With IPv4 address depletion on the horizon, many techniques are being 77 standardized for IPv6 migration including DS-Lite [RFC6333] and 6rd 78 [RFC5969]. DS-Lite enables IPv4 hosts to communicate with external 79 hosts using IPv6 only network and moves the traditional NAT to the 80 network. B4 element's LAN side is dual stack and WAN side is IPv6 81 only. B4 tunnels IPv4 packets received from the LAN side to AFTR 82 element after encapsulating IPv4 packet in an IPv6 packet. AFTR 83 decapsulates the packet, does a NAT operation and then sends the 84 packet out to IPv4 public internet. 86 DS-Lite as defined in [RFC6333] is unicast only, it does not support 87 multicast. In this document we specify multicast extensions to DS- 88 Lite in order to provide IP multicast communication to home IPv4 89 users in DS-Lite. 91 2. Terminology 93 This document uses the terminology defined in [RFC6333] and 94 [RFC3376]. 96 3. Requirements 98 This section states requirements on DS-Lite multicast support 99 protocol. 101 DS-Lite multicast solution MUST integrate with DS-Lite unicast 102 solution, it MUST not introduce additional mechanisms to the existing 103 B4 to AFTR communication. 105 DS-Lite multicast solution MUST not require additional capabilities 106 in IPv6 network connecting B4 to AFTR other than what unicast DS-Lite 107 solution requires. 109 DS-Lite B4 MUST support IGMP Proxy as defined in [RFC4605]. DS-Lite 110 B4 MAY support MLD Proxy. 112 DS-Lite AFTR MUST support IGMP Querrier. DS-Lite AFTR MAY support 113 MLD Querrier. 115 Both any source multicast (ASM) and source specific multicast (SSM) 116 MUST be supported. 118 4. Architecture 120 In DS-Lite, there are hosts (possibly IPv4/ IPv6 dual stack) served 121 by B4 element. B4 is dual stack facing the hosts and IPv6 only 122 facing the network or WAN side. At the boundary of the network there 123 is AFTR. AFTR receives IPv4 packets tunneled in IPv6 from B4 and 124 decapsulates them and sends them out to IPv4 network. 126 In order to support multicast communication B4 implements IGMP Proxy 127 function [RFC4605]. IPv4 hosts send their join requests (IGMP 128 Membership Report messages) to B4. B4 as a proxy sends aggregated 129 Report messages upstream towards AFTR. 131 AFTR is the default multicast querier for B4. AFTR implements 132 multicast router function or it could be another IGMP proxy. 134 All the elements of DS-Lite multicast support system are shown in 135 Figure 1. 137 Dual Stack Hosts IPv4 138 +----+ Network 139 | H1 | IPv6 140 +----+ +-----+ only +-------+ + 141 +----+ | B4 | network -- | AFTR | 142 | H2 | ---| IGMP|--- IPv4-in- | IGMP | IPv6 143 +----+ |Proxy| IPv6 |Querier| Network 144 +----+ +-----+ tunnel +-------+ 145 | H3 | 146 +----+ 148 Figure 1: Architecture of DS-Lite Multicast Protocol 150 5. DS-Lite Multicast Operation 152 In this section we specify how the host can subscribe and receive 153 IPv4 multicast data from IPv4 content providers based on the 154 architecture defined in Section 4. 156 The hosts will send their subscription requests for IPv4 multicast 157 groups upstream to the default router, i.e. B4 Element. After 158 subscribing to the group, the host can receive multicast data from 159 the B4. The host implements IGMP protocol's host part. 161 In order to support SSM, IGMPv3 MUST be supported by the host, B4 and 162 AFTR. 164 B4 Element is IGMP Proxy. After receiving the first IGMP Report 165 message requesting subscription to an IPv4 multicast group, B4 166 establishes a tunnel interface with a AFTR. The tunnel is IPv6 based 167 but it will carry IPv4 traffic, IGMP messages back and forth and IPv4 168 multicast data messages downstream. This is similar to [RFC6224] 169 Section 4.4 but the operation is much simpler. In DS-Lite 170 environment there is no requirement to handle host mobility. B4 does 171 not have to keep more than one tunnel interfaces, a single interface 172 is sufficient. IGMP Proxy at the B4 does not have to have more than 173 one proxy instances, a single instance is sufficient. 175 B4 is regular IGMP proxy and it keeps IGMP proxy membership database. 176 B4 inserts multicast forwarding state on the incoming interface, and 177 merges state updates into the IGMP proxy membership database. B4 178 updates or removes elements from the database as required. B4 will 179 then send an aggregated Report via the upstream tunnel to the AFTR 180 when the membership database changes. 182 B4 answers IGMP queries from AFTR based on the membership database. 183 B4's downstream link follows the traditional multipoint channel 184 forwarding and does not pose any specific problems. 186 B4 receives IPv4 multicast data from the AFTR tunneled over the 187 tunnel interface. B4 decapsulates the packet and then forwards it 188 downstream. Each member host receives the data packet based on Layer 189 2 multicast interface. No packet duplication is necessary. 191 AFTR acts as the as the default multicast querier for all B4s that 192 have established an IPv6 tunnel with it. In order to keep a 193 consistent multicast state between a B4 and AFTR, once a B4 is 194 connected it will stay connected until the state becomes empty. 195 After that point, the B4 may continue to use the tunnel for IPv4 196 unicast traffic. 198 According to aggregated IGMP reports received from a B4, AFTR 199 establishes group/source-specific multicast forwarding states at its 200 corresponding downstream tunnel interfaces. After that, AFTR 201 maintains or removes the state as required by the aggregated reports 202 received from B4. 204 At the upstream interface, AFTR procures for aggregated multicast 205 membership maintenance. Based on the multicast-transparent 206 operations of the B4s, the AFTR treats its tunnel interfaces as 207 multicast enabled downstream links, serving zero to many listening 208 nodes. 210 Multicast traffic arriving at the AFTR is transparently forwarded 211 according to its multicast forwarding information base. Multicast 212 data is first replicated and then forwarded in IPv4-in-IPv6 tunnel 213 from AFTR to the corresponding B4. 215 5.1. Tunnel Interface Considerations 217 Legacy IPv4 in IPv6 tunneling is performed as in [RFC2473] and 218 [RFC4213]. Considerations specified in [RFC6333] apply. Packets 219 upstream from B4 carry only IGMP signaling messages and they are not 220 expected to fragmentation. However packets downstream, i.e. 221 multicast data to B4 may be subject to fragmentation. 223 Source and destination addresses of IGMP messages in IPv4-in-IPv6 224 softwire from B4 is as follows: 226 Source address of IPv6 header is B4 IPv6 address, e.g. 227 2001:db8:0:1::1, destination address is AFTR address, e.g. 2001:db8: 228 0:2::1. 230 Source address of IGMP messages is B4's IPv4 interface address, e.g. 231 192.0.0.2, destination address is the all-systems multicast address 232 of 224.0.0.1 for IGMP Query, all IGMPv3-capable multicast routers of 233 224.0.0.22 for IGMPv3 Report, the multicast group specified in the 234 Group Address field of the Report for IGMPv1 or IGMPv2 Report. 236 Source and destination addresses of IGMP messages in IPv4-in-IPv6 237 softwire from AFTR is as follows: 239 Source address of IPv6 header is AFTR address, e.g. 2001:db8:0:2::1, 240 destination address is B4 IPv6 address, e.g. 2001:db8:0:1::1. 242 Source address of IGMP messages is AFTR's IPv4 interface address, 243 e.g. 192.0.2.1, destination address is the all-systems multicast 244 address of 224.0.0.1 for IGMP Query, all IGMPv3-capable multicast 245 routers of 224.0.0.22 for IGMPv3 Report, the multicast group 246 specified in the Group Address field of the Report for IGMPv1 or 247 IGMPv2 Report. 249 Source and destination addresses of multicast data messages in IPv4- 250 in-IPv6 softwire is as follows: 252 Source address of IPv6 header is AFTR address, e.g. 2001:db8:0:2::1, 253 destination address is B4 IPv6 address, e.g. 2001:db8:0:1::1. 255 Source address of IPv4 multicast data is unicast IPv4 address of the 256 multicast source, e.g. the content provider, destination address is 257 IPv4 multicast group address. 259 AFTR decapsulates datagrams carrying IGMP messages from B4's and then 260 IGMP router processing takes over. Network Address Translation (NAT) 261 is not applied on IGMP messages. 263 6. Multicast Support for Host-Based Architecture 265 In this section we specify multicast support for Host-Based DS-Lite 266 architecture described in Appendix B2 of [RFC6333]. 268 In host-based DS-Lite, the host accesses the service provider network 269 directly with an IPv6 global address. Host sends its IPv4 datagrams 270 in IPv6 using an IPv4-in-IPv6 softwire tunnel to an AFTR, i.e. it 271 implements DS-Lite B4. Source address of all IPv4 datagrams is the 272 pre-configured well-known IPv4 non-routable address. 274 For multicast, there are two choices: the host could implement host 275 side of IGMP protocol or for mobile router type of hosts, the host 276 implements IGMP proxy as in Section 5. 278 Host encapsulates IGMP messages as described in Section 5.1 and sends 279 them to AFTR. AFTR does not perform IPv4-IPv4 NAT translations on 280 IGMP datagrams instead they are processed by IGMP router at the AFTR. 282 Multicast data received from AFTR for a multicast group that the host 283 has subscribed is decapsulated by the host, if the host is IGMP 284 client, it processes the data. If the host is IGMP proxy, it 285 consults multicast state for the group and forwards the data 286 downstream so that the members can receive the data. 288 7. Avalanche Problem 290 When multicast datagrams are received at the AFTR, AFTR consults its 291 memebership database and duplicates the packets for each member B4 292 interface and then these datagrams are forwarded in IPv4-in-IPv6 293 softwire downstream. This may cause an avalanche of downstream 294 packets if the number of member B4's is high. 296 Avalanche problem can be eased by network partitioning. AFTR can be 297 deployed closer to the users. For example in broadband networks, 298 AFTR can be deployed at the Broadband Network Gateway (BNG) nodes. 300 8. IANA Considerations 302 None. 304 9. Acknowledgements 306 TBD. 308 10. References 310 10.1. Normative References 312 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 313 Requirement Levels", BCP 14, RFC 2119, March 1997. 315 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 316 June 1999. 318 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 319 "Internet Group Management Protocol (IGMP) / Multicast 320 Listener Discovery (MLD)-Based Multicast Forwarding 321 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 323 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 324 Thyagarajan, "Internet Group Management Protocol, Version 325 3", RFC 3376, October 2002. 327 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 328 IPv6 Specification", RFC 2473, December 1998. 330 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 331 for IPv6 Hosts and Routers", RFC 4213, October 2005. 333 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 334 Deployment for Multicast Listener Support in Proxy Mobile 335 IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 337 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 338 Stack Lite Broadband Deployments Following IPv4 339 Exhaustion", RFC 6333, August 2011. 341 10.2. Informative references 343 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 344 Infrastructures (6rd) -- Protocol Specification", 345 RFC 5969, August 2010. 347 [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", 348 RFC 4286, December 2005. 350 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 351 "Considerations for Internet Group Management Protocol 352 (IGMP) and Multicast Listener Discovery (MLD) Snooping 353 Switches", RFC 4541, May 2006. 355 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 356 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 358 Author's Address 360 Behcet Sarikaya 361 Huawei USA 362 5340 Legacy Drive Building 175 363 Plano, TX 75074 365 Phone: 366 Email: sarikaya@ieee.org