Network Working Group B. Sarikaya Internet-Draft Huawei USA Intended status: Standards Track March 7, 2011 Expires: September 8, 2011 Multicast Support for Dual Stack Lite and 6RD draft-sarikaya-softwire-dslite6rdmulticast-00.txt Abstract This memo specifies modifications required to DS-Lite and 6RD so that both IPv4/ IPv6 hosts can receive multicast data from IPv4/ IPv6 servers. The DS-Lite solution is based on DS-Lite Basic Bridging BroadBand element (B4) proxying IGMP and then tunneling IGMP messages to DS- Lite Address Family Transition Router element (AFTR). IPv4 multicast data received at AFTR is tunneled to B$ and then delivered to the hosts. IPv6 multicast and MLD can be supported in a similar way. The 6RD protocol is based on proxying MLD at the 6RD Customer Edge and then tunneling MLD messages to 6RD Border Relays where IPv6 multicast routing is supported. Multicast data received at 6RD Border Relay is tunneled to 6RD Customer Edge node and then delivered to the hosts. We show that IPv4 multicast and IGMP can be supported in a similar way. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 8, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the Sarikaya Expires September 8, 2011 [Page 1] Internet-Draft Multicast Support for DS-Lite - 6RD March 2011 document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. DS-Lite Multicast Operation . . . . . . . . . . . . . . . . . 5 5.1. Tunnel Interface Considerations . . . . . . . . . . . . . 7 5.2. Supporting IPv6 Multicast in DS-Lite . . . . . . . . . . . 7 6. 6RD Multicast Operation . . . . . . . . . . . . . . . . . . . 7 6.1. Tunnel Interface Considerations . . . . . . . . . . . . . 9 6.2. Supporting IPv4 Multicast in 6RD . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10.2. Informative references . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Sarikaya Expires September 8, 2011 [Page 2] Internet-Draft Multicast Support for DS-Lite - 6RD March 2011 1. Introduction With IPv4 address depletion on the horizon, many techniques are being standardized for IPv6 migration including DS-Lite [I-D.ietf-softwire-dual-stack-lite] and 6RD [RFC5969]. DS-Lite enables IPv4 hosts to communicate with external hosts using IPv6 only network and moves the traditional NAT to the network. B4 element's LAN side is dual stack and WAN side is IPv6 only. B4 tunnels IPv4 packets received from the LAN side to AFTR element after encapsulating IPv4 packet in an IPv6 packet. AFTR decapsulates the packet, does a NAT operation and then sends the packet out to IPv4 public internet. 6RD enables IPv6 hosts to communicate with external hosts using IPv4 only legacy ISP network. 6RD Customer Edge (CE) device's LAN side is dual stack and WAN side is IPv4 only. CE tunnels IPv6 packets received from the LAN side to 6RD Border Relays (BR) after encapsulating IPv6 packet in an IPv4 packet. BRs have anycast IPv4 addresses and receive encapsulated packets from CEs over a virtual interface. 6RD operation is stateless. Packets are received/ sent independent of each other and no state needs to be maintained. DS-Lite as defined in [I-D.ietf-softwire-dual-stack-lite] is unicast only, it does not support multicast. In this document we specify how multicast from home IPv4 users can be supported in DS-Lite. We also show how IPv6 multicast can be supported for home IPv6 users in DS- Lite. 6RD as defined in [RFC5969] and [RFC5569] is unicast only. It does not support multicast. In this document we specify how multicast from home IPv6 users can be supported in 6RD. We also show how IPv4 multicast can be supported for home IPv4 users. Both solutions use IPv6 and IPv4 multicast addressing and do not require any new multicast address prefixes such as IPv4-embedded IPv6 multicast addresses to be allocated. 2. Terminology This document uses the terminology defined in [RFC5969], [RFC5569], [RFC3810] and [RFC3376]. 3. Requirements This section states requirements on DS-Lite and 6RD multicast support protocol. Sarikaya Expires September 8, 2011 [Page 3] Internet-Draft Multicast Support for DS-Lite - 6RD March 2011 DS-Lite B4 MUST support IGMP Proxy as defined in [RFC4605]. DS-Lite B4 MAY support MLD Proxy. DS-Lite AFTR MUST support IGMP Querrier. DS-Lite AFTR MAY support MLD Querrier. 6RD CE MUST support MLD Proxy as defined in [RFC4605]. 6RD CE MAY support IGMP Proxy. 6RD BR MUST support MLD Querrier. 6RD CE MAY support IGMP Querrier. Both any source multicast (ASM) and source specific multicast (SSM) MUST be supported. 4. Architecture In DS-Lite, there are hosts (possibly IPv4/ IPv6 dual stack) served by B4 element. B4 is dual stack facing the hosts and IPv6 only facing the network or WAN side. At the boundary of the network there is AFTR. AFTR receives IPv4 packets tunneled in IPv6 from B4 and decapsulates them and sends them out to IPv4 network. In order to support multicast B4 implements IGMP Proxy function [RFC4605]. IPv4 hosts send their join requests (IGMP Membership Report messages) to B4. B4 as a proxy sends aggregated Report messages upstream towards AFTR. AFTR is the default multicast querier for B4. AFTR implements multicast router function or it could be another IGMP proxy. All the elements of DS-Lite multicast support system are shown in Figure 1. Dual Stack Hosts IPv4 +----+ Network | H1 | IPv6 +----+ +-----+ only +-------+ + +----+ | B4 | network -- | AFTR | | H2 | ---| IGMP|--- | IGMP | IPv6 +----+ |Proxy| |Querier| Network +----+ +-----+ +-------+ | H3 | +----+ Sarikaya Expires September 8, 2011 [Page 4] Internet-Draft Multicast Support for DS-Lite - 6RD March 2011 Figure 1: Architecture of DS-Lite Multicast Protocol In 6RD, there are hosts (possibly IPv4/ IPv6 dual stack) served by 6RD Customer Edge device. CE is dual stack facing the hosts and IPv4 only facing the network or WAN side. At the boundary of the network there is 6RD Border Relay. BR receives IPv6 packets tunneled in IPv4 from CE and decapsulates them and sends them out to IPv6 network. In order to support multicast CE implements MLD Proxy function [RFC4605]. IPv6 hosts send their join requests (MLD Membership Report messages) to CE. CE as a proxy sends aggregated Report messages upstream towards BR. Dual Stack Hosts IPv4 +----+ Network | H1 | IPv4 +----+ +-----+ only +-------+ + +----+ | CE | network -- | BR | | H2 | ---| MLD |--- | MLD | IPv6 +----+ |Proxy| |Querier| Network +----+ +-----+ +-------+ | H3 | +----+ Figure 2: Architecture of 6RD Multicast Protocol BR is the default multicast querier for CE. BR implements multicast router function or it could be another MLD proxy. All the elements of 6RD multicast support system are shown in Figure 2. 5. DS-Lite Multicast Operation In this section we specify how the host can subscribe and receive IPv4 multicast data from IPv4 content providers based on the architecture defined in Section 4. The hosts will send their subscription requests for IPv4 multicast groups upstream to the default router, i.e. B4 Element. After subscribing to the group, the host can receive multicast data from the B4. The host implements IGMP protocol's host part. Sarikaya Expires September 8, 2011 [Page 5] Internet-Draft Multicast Support for DS-Lite - 6RD March 2011 B4 Element is IGMP Proxy. After receiving the first IGMP Report message requesting subscription to an IPv4 multicast group, B4 establishes a tunnel interface with a AFTR. The tunnel is IPv6 based but it will carry IP traffic, IGMP messages back and forth and IPv4 multicast data messages downstream. This is similar to [I-D.ietf-multimob-pmipv6-base-solution] but the operation is much simpler. In DS-Lite environment there is no requirement to handle host mobility. B4 does not have to keep more than one tunnel interfaces, a single interface is sufficient. IGMP Proxy at the B4 does not have to have more than one proxy instances, a single instance is sufficient. B4 is regular IGMP proxy and it keeps IGMP proxy membership database. B4 inserts multicast forwarding state on the incoming interface, and merges state updates into the IGMP proxy membership database. B4 updates or removes elements from the database as required. B4 will then send an aggregated Report via the upstream tunnel to the AFTR when the membership database changes. B4 answers IGMP queries from AFTR based on the membership database. B4's downstream link follows the traditional multipoint channel forwarding and does not pose any specific problems. B4 receives IPv4 multicast data from the AFTR tunneled over the tunnel interface. B4 decapsulates the packet and then forwards it downstream. Each member host receives the data packet based on Layer 2 multicast interface. No packet duplication is necessary. AFTR acts as the as the default multicast querier for all B4s that have established an IPv6 tunnel with it. In order to keep a consistent multicast state between a B4 and AFTR, once a B4 is connected it will stay connected until the state becomes empty. After that point, the B4 may continue to use the tunnel for IPv4 unicast traffic. According to aggregated IGMP reports received from a B4, AFTR establishes group/source-specific multicast forwarding states at its corresponding downstream tunnel interfaces. After that, AFTR maintains or removes the state as required by the aggregated reports received from B4. At the upstream interface, AFTR procures for aggregated multicast membership maintenance. Based on the multicast-transparent operations of the B4s, the AFTR treats its tunnel interfaces as multicast enabled downstream links, serving zero to many listening nodes. Multicast traffic arriving at the AFTR is transparently forwarded Sarikaya Expires September 8, 2011 [Page 6] Internet-Draft Multicast Support for DS-Lite - 6RD March 2011 according to its multicast forwarding information base. Multicast data is first replicated and then forwarded in IPv4-in-IPv6 tunnel from AFTR to the corresponding B4. 5.1. Tunnel Interface Considerations Legacy IPv4 in IPv6 tunneling is performed as in [RFC2473]. Considerations specified in [I-D.ietf-softwire-dual-stack-lite] apply. Packets upstream from B4 carry only IGMP signaling messages and they are not expected to fragmentation. However packets downstream, i.e. multicast data to B4 may be subject to fragmentation. 5.2. Supporting IPv6 Multicast in DS-Lite IPv6 multicast can be supported in a way similar to IPv4 as described in Section 5. B4 Element has MLD Proxy function. Proxy operation for MLD [RFC3810] is described in [RFC4605]. B4 receives MLD join requests from the hosts and then sends aggregated MLD Report messages upstream in an IPv6 in IPv6 tunnel. Tunnel addressing is in IPv6 and is as described in [I-D.ietf-softwire-dual-stack-lite]. Multicast membership database is maintained for all active IPv6 multicast groups the hosts subscribe. AFTR is MLD querier or another MLD Proxy. It serves all B4s downstream and treats its tunnel interfaces as multicast enabled downstream links, serving zero to many listening nodes. Multicast membership database is maintained based on the aggregated Reports received from downstream tunnel interfaces. IPv6 multicast data received from the multicast Single Source Multicast or Any Source Multicast sources are replicated according to the multicast membership database and the data packets are tunneled to the B4s that have one or more members of this multicast group. B4s receive multicast data upstream in the B4-AFTR tunnel and decapsulate it and then forward the packet downstream. Each member host receive IPv6 multicast data packet from its Layer 2 interface. 6. 6RD Multicast Operation In this section we specify how the host can subscribe and receive IPv6 multicast data from IPv6 content providers based on the architecture defined in Section 4. Sarikaya Expires September 8, 2011 [Page 7] Internet-Draft Multicast Support for DS-Lite - 6RD March 2011 The hosts will send their subscription requests for IPv6 multicast groups upstream to the default router, i.e. Costumer Edge device. After subscribing the group, the host can receive multicast data from the CE. The host implements MLD protocol's host part. Customer Edge device is MLD Proxy. After receiving the first MLD Report message requesting subscription to an IPv6 multicast group, CE establishes a tunnel interface with a Border Relay. The tunnel is IPv4 based but it will carry IP traffic, MLD messages back and forth and IPv6 multicast data messages downstream. This is similar to [I-D.ietf-multimob-pmipv6-base-solution] but the operation is much simpler. In 6RD environment there is no requirement to handle host mobility. CE does not have to keep more than one tunnel interfaces, a single interface is sufficient. MLD Proxy at the CE does not have to have more than one proxy instances, a single instance is sufficient. CE is regular MLD proxy and it keeps MLD proxy membership database. CE inserts multicast forwarding state on the incoming interface, and merges state updates into the MLD proxy membership database. CE updates or remove elements from the database as required. CE will then send an aggregated Report via the upstream tunnel to the BR when the membership database changes. CE answers MLD queries from BR based on the membership database. CE's downstream link follows the traditional multipoint channel forwarding and does not pose any specific problems. CE receives IPv6 multicast data from the BR tunneled over the tunnel interface. CE decapsulates the packet and then forwards it downstream. Each member host receives the data packet based on Layer 2 multicast interface. No packet duplication is necessary. Border Relay acts as the as the default multicast querier for all CEs that have established an IPv4 tunnel with it. In order to keep a consistent multicast state between a CE and BR, once a CE is connected it will stay connected until the state becomes empty. After that point, the CE may establish another tunnel to a different BR. According to aggregated MLD reports received from a CE, BR establishes group/source-specific multicast forwarding states at its corresponding downstream tunnel interfaces. After that, BR maintains or removes the state as required by the aggregated reports received from CE. At the upstream interface, BR procures for aggregated multicast membership maintenance. Based on the multicast-transparent Sarikaya Expires September 8, 2011 [Page 8] Internet-Draft Multicast Support for DS-Lite - 6RD March 2011 operations of the CEs, the BR treats its tunnel interfaces as multicast enabled downstream links, serving zero to many listening nodes. Multicast traffic arriving at the BR is transparently forwarded according to its multicast forwarding information base. Multicast data is first replicated and then forwarded in IPv6-in-IPv4 tunnel from BR to the corresponding CE. 6.1. Tunnel Interface Considerations IPv6 in IPv4 tunneling is performed as specified in [RFC4213]. Considerations specified in [RFC5969] apply. Packets upstream from CE carry only MLD signaling messages and they are not expected to fragmentation. However packets downstream, i.e. multicast data to CE may be subject to fragmentation. 6.2. Supporting IPv4 Multicast in 6RD IPv4 multicast can be supported in a way similar to IPv6 as described in Section 6. 6RD Customer Edge device has IGMP Proxy function. Proxy operation for IGMP [RFC3376] is described in [RFC4605]. CE receives IGMP join requests from the hosts and then sends aggregated IGMP Report messages upstream in an IPv4 in IPv4 tunnel. Tunnel addressing is in IPv4 and is as described in [RFC5969]. Multicast membership database is maintained for all active IPv4 multicast groups the hosts subscribe. 6RD Border Relay is IGMP querier or another IGMP Proxy. It serves all CEs downstream and treats its tunnel interfaces as multicast enabled downstream links, serving zero to many listening nodes. Multicast membership database is maintained based on the aggregated Reports received from downstream tunnel interfaces. IPv4 multicast data received from the multicast Single Source Multicast or Any Source Multicast sources are replicated according to the multicast membership database and the data packets are tunneled to the CEs that have one or more members of this multicast group. CEs receive multicast data upstream in the CE-BR tunnel and decapsulate it and then forward the packet downstream. Each member host receive IPv4 multicast data packet from its Layer 2 interface. 7. Security Considerations TBD. Sarikaya Expires September 8, 2011 [Page 9] Internet-Draft Multicast Support for DS-Lite - 6RD March 2011 8. IANA Considerations TBD. 9. Acknowledgements TBD. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010. [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [I-D.ietf-softwire-dual-stack-lite] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Sarikaya Expires September 8, 2011 [Page 10] Internet-Draft Multicast Support for DS-Lite - 6RD March 2011 Exhaustion", draft-ietf-softwire-dual-stack-lite-07 (work in progress), March 2011. [I-D.ietf-multimob-pmipv6-base-solution] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment for Multicast Listener Support in PMIPv6 Domains", draft-ietf-multimob-pmipv6-base-solution-07 (work in progress), December 2010. 10.2. Informative references Sarikaya Expires September 8, 2011 [Page 11] Internet-Draft Multicast Support for DS-Lite - 6RD March 2011 Author's Address Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Phone: +1 972-509-5599 Email: sarikaya@ieee.org Sarikaya Expires September 8, 2011 [Page 12]