Internet Engineering Task Force Q. Wang Internet-Draft China Telecom Intended status: Standards Track J. Qin Expires: April 28, 2011 P. Sun ZTE M. Boucadair C. Jacquenet France Telecom October 25, 2010 Multicast Extensions to DS-Lite in Broadband Deployments draft-qin-softwire-dslite-multicast-01 Abstract The DS-Lite technique enables service providers to deliver IPv4 unicast services following IPv4 address exhaustion by combining two mechanisms: NAT and IPv4-in-IPv6 encapsulation. This document describes extensions to DS-Lite to support IPv4 multicast delivery. 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 April 28, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the 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 Wang, et al. Expires April 28, 2011 [Page 1] Internet-Draft DS-Lite Multicast October 2010 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Wang, et al. Expires April 28, 2011 [Page 2] Internet-Draft DS-Lite Multicast October 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Context and Overview . . . . . . . . . . . . . . . . . . . . . 5 3.1. Overview: IPTV-centric View . . . . . . . . . . . . . . . 5 3.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Mitigation Alternatives . . . . . . . . . . . . . . . . . 7 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Location of the Multicast AFTR . . . . . . . . . . . . . . 8 4.3. Multicast AFTR vs. Unicast AFTR . . . . . . . . . . . . . 10 4.4. IPv4-Embedded IPv6 Address Prefixes . . . . . . . . . . . 10 4.5. Multicast Distribution Tree . . . . . . . . . . . . . . . 11 4.6. Multicast Forwarding . . . . . . . . . . . . . . . . . . . 11 5. Address Mapping . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 12 5.2. Text Representation . . . . . . . . . . . . . . . . . . . 12 6. Multicast B4 . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. IGMP-MLD Interworking . . . . . . . . . . . . . . . . . . 13 6.2. Firewalling . . . . . . . . . . . . . . . . . . . . . . . 13 6.3. Address Mapping . . . . . . . . . . . . . . . . . . . . . 13 6.4. De-capsulation and Forwarding . . . . . . . . . . . . . . 13 6.5. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 14 7. Multicast AFTR . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Processing PIM/MLD Join Messages . . . . . . . . . . . . . 14 7.2. Reliability . . . . . . . . . . . . . . . . . . . . . . . 14 7.3. Routing Considerations . . . . . . . . . . . . . . . . . . 14 7.4. TTL/Scope . . . . . . . . . . . . . . . . . . . . . . . . 15 7.5. Encapsulation and forwarding . . . . . . . . . . . . . . . 15 7.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 15 8. Multicast Traffic Optimization . . . . . . . . . . . . . . . . 15 8.1. Co-existence with native IPv6 multicast . . . . . . . . . 15 8.2. Optimization . . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 Appendix A. Translation vs. Encapsulation . . . . . . . . . . . . 18 A.1. Translation . . . . . . . . . . . . . . . . . . . . . . . 18 A.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Wang, et al. Expires April 28, 2011 [Page 3] Internet-Draft DS-Lite Multicast October 2010 1. Introduction DS-Lite [I-D.ietf-softiwre-dual-stack-lite] is a technique to rationalize the use of the remaining IPv4 addresses during the transition period. The current design of DS-Lite covers unicast services exclusively. If DS-Lite is used for IPv4 multicast, AFTR devices must work as the multicast replication point where all the IGMP reports are processed. In particular, DS-Lite designs where the AFTR capability is centralized is likely to affect the multicast traffic forwarding efficiency by losing the benefits of deterministic replication of the data as close to the receivers as possible. As a consequence, the downstream bandwidth will be vastly consumed. In practice, a similar issue exists in native IPv4 networks for multicast. To deal with it, mechanisms like IGMP snooping, IGMP proxying, multicast VLAN etc., are introduced into distributed Access Network Nodes (e.g., Aggregation Switches, xPON devices) which then behave as IGMP Querier devices and replicate multicast traffic. In this way, the multicast replication point can be moved downward closer to the subscribers, so the bandwidth consumption and the great pressure of the layer 3 gateway is reduced substantially. While in DS-Lite, these mechanisms for multicast traffic optimization do not work on Access Network Nodes due to the current tunnel encapsulation. In this document, we discuss the extension of the DS-Lite model to adapt it to the delivery of IPv4 multicast-based service offerings. The key characteristic of this proposal is exactly the same as DS- Lite: communications stay within their address family and no translation is enforced in the delivery path. Moreover, unlike unicast DS-Lite, the Multicast AFTR is stateless. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Terminology This document makes use of the following terms: o IPv4-Embedded IPv6 address: is an IPv6 address which embeds a 32 bit-encoded IPv4 address. Refer to [I-D.ietf-behave-address- format] for more details. Wang, et al. Expires April 28, 2011 [Page 4] Internet-Draft DS-Lite Multicast October 2010 o Multicast AFTR: is a functional entity which is part of both the IPv4 and IPv6 multicast distribution trees and which replicates IPv4 multicast streams into IPv4-in-IPv6 streams in the relevant branches of the IPv6 multicast distribution tree. o Multicast B4: is a functional entity embedded in a CPE or a host, which is able to enforce an IGMP-MLD interworking function together with a de-capsulation function of received multicast IPv4-in-IPv6 packets. 3. Context and Overview 3.1. Overview: IPTV-centric View The current design of DS-Lite covers unicast services exclusively, so for advanced services (e.g., IPTV), service providers may have to adopt various strategies for their delivery. o VoD (Video on Demand) or catch-up TV channels streams can be delivered via a DS-Lite AFTR since it is based on unicast. Enhancements to applications is encouraged to promote the usage of IPv6 whenever possible and therefore avoid the crossing of AFTR devices (e.g., propose an alternate IPv6 address in SDP [I-D.boucadair-mmusic-altc]). o Live TV broadcasting, In current operational deployments, is delivered through the IP multicast forwarding scheme by many service. Numerous players intervene in the delivery of this service: (1) Content providers: the content can be provided by the same provider as the one providing the connectivity service or by distinct providers (e.g., external paid channels); (2) Network provider: is responsible for carrying multicast flows from head- ends to receivers [I-D.ietf-mboned-multiaaa-framework]. For the sake of network simplification, the recommended solution for a service provider deploying DS-Lite technique is to upgrade its multicast-based services to be IPv6-enabled. In particular, the multicast content should be formatted and accessed in IPv6. Still, part of the IPTV contents that are currently available are likely to remain IPv4-formatted. And customers with legacy receivers (e.g., IPv4-only Set Top Boxes (STB)) MUST continue to access the service. his means that the traffic should be accessed over native IPv4. Note that some contract agreements prevent a network provider to alter the content as sent by the content provider, in particular for copyright, confidentiality and SLA assurance reasons. The streams should be delivered unaltered to requesting users. The solution Wang, et al. Expires April 28, 2011 [Page 5] Internet-Draft DS-Lite Multicast October 2010 proposed in this document only applies for contents that are allowed to be encapsulated by a network provider for transport purposes. The following cases should be covered to the forwarding of IPv4 multicast traffic in DS-Lite environments: (1) IPv4-only multicast receiver; (2) Dual-Stack multicast receiver. As for the content, two scenarios are considered as valid ones: (1) IPv4-only content; (2) Dual-Stack content (i.e., content formatted and reachable in both IPv4 and IPv6) (of course, incentives to inject the same content in both IPv4 and IPv6 may be questionable). The following cases are out of scope of this document: (1) IPv6-only receiver; (2) IPv6-only content. Figure 1 provides an overview of the main elements to be considered for the delivery of multicast content in a DS-Lite context. In reference to Figure 1: 1. The legacy IPv4 receiver can access content reachable over IPv4. No issue is raised by this scenario. Multicast flows will be delivered using native IPv4 transfer mode. No AFTR is involved in the path; 2. An IPv4-only receiver behind a DS-Lite CGN: Additional functions are required to deliver the content to the receiver; 3. A Dual-Stack receiver should access a IPv6-reachable content using IPv6. No extra function is required to implement this scenario; 4. A Dual-Stack receiver accessing IPv4-only content: This scenario is similar to the IPv4-only receiver accessing the IPv4-only content (2nd bullet). Additional functions are required. Wang, et al. Expires April 28, 2011 [Page 6] Internet-Draft DS-Lite Multicast October 2010 ^ +----------+ +----------+ Content | |Dual Stack| | IPv4 | Provider | | Content | | Content | | +----------+ +----------+ v ================= ^ Network | +----------+ +----------+ Provider | | Unicast | | Multicast| | | AFTR | | AFTR | | +----------+ +----------+ v ================= ^ | +----------+ +----------+ Customer | |Dual Stack| |Dual Stack| | | CPE | | CPE | | +----------+ +----------+ | | +----------+ +----------+ | |Dual Stack| | IPv4-only| | | Receiver | | Receiver | v +----------+ +----------+ Figure 1: Reference Environment 3.2. Scope This document focuses only on issues raised by a DS-Lite networking environment; in particular: subscription to a multicast group and the delivery of content to receivers. Pure IPv6-only devices, receivers or senders (i.e., devices that do not include an IPv4 stack) are out of the scope of this document. This document does not cover the case where an IPv4 host behind a DS- Lite AFTR can be the source of multicast traffic. 3.3. Mitigation Alternatives In order to prevent complications raised when multicast flows are to cross a unicast DS-Lite AFTR, Service Providers may opt for a separated addressing scheme for the delivery of multicast-based service offerings. Service-specific IPv4 addresses are assigned to STBs to access a multicast-based service offering. In such case, no extra standardisation effort is required. The use of a private IPv4 addressing scheme to deliver multicast traffic is likely to yield additional management complexity (e.g., because of potentially Wang, et al. Expires April 28, 2011 [Page 7] Internet-Draft DS-Lite Multicast October 2010 overlapping addressing schemes), which is out of the scope of this document. For Service Providers who use a service-agnostic IP addressing scheme, dedicated solutions are to be specified to be able to deliver multicast content to DS-Lite serviced customers. This is the purpose of this document. 4. Solution Overview In the original DS-Lite specification, IPv4-in-IPv6 tunnel is used to carry the bidirectional IPv4 unicast traffic between B4 and AFTR. Within the context of this document, an IPv4-converted IPv6 multicast address is used as the destination of the encapsulated unidirectional IPv4-in-IPv6 multicast traffic from the Multicast AFTR to the subscribed Multicast B4. The IPv4 address of the multicast source will also be mapped into an IPv6 address by the Multicast AFTR when forwarding the encapsulated IPv4-in-IPv6 multicast flows in the IPv6 realm. 4.1. Rationale The solution proposed in this document defines two functional elements: o Multicast AFTR: responsible for replicating IPv4 multicast flows in IPv6 owing to a stateless IPv4-in-IPv6 encapsulation. The multicast AFTR does not undertake any NAT operation. Unlike unicast DS-Lite, a B4 does not need to discover a Multicast AFTR. o Multicast B4: is a functional entity embedded in a CPE responsible for the de-capsulation of the received IPv4-in-IPv6 packets and forwarding them to the appropriate IPv4 receivers. In order for this solution to work, B4 MUST be provisioned with an IPv6 prefix and an algorithm for building IPv4-Embedded IPv6 addresses [I-D.ietf-behave-address-format]. Multicast AFTR and B4 MUST use the same IPv6 prefix and algorithm for building IPv4-Embedded IPv6 addresses (for both source address and group address). 4.2. Location of the Multicast AFTR The Multicast AFTR can be located in various places in the network. If the Multicast AFTR is embedded in the first IP router reachable Wang, et al. Expires April 28, 2011 [Page 8] Internet-Draft DS-Lite Multicast October 2010 from a B4, the MLD Report message is processed by the AFTR where the IPv4-embedded (encapsulated) IPv6 multicast is forwarded based on the MLD membership information database. Please see Figure 2 belowGBPo +------------+ +-----------+ -------| v4 Router | | v6 Router |------- +------------+ +-----------+ \ / | \ / | \ / | +---------------+ | | First-Hop | | | Router with | | | AFTR | | +---------------+ | | | | Native | | | IPv6 Multicast IPv4-embedded | | | IPv6 Multicast | +----------+ | | | B4 | | | +----------+ | | / \ | V / \ V +------+ +------+ | v4 | | v6 | | Host | | Host | +------+ +------+ Figure 2: Multicast AFTR embedded in the first IP router If the Multicast AFTR is not embedded in the router which receives MLD Report message from a multicast B4, multicast routing mechanisms are enabled to build the IPv6 multicast distribution tree for delivering the subscribed traffic to a receiver. We assume that the PIM-SM is used in this case. Please see Figure 3 belowGBPo Wang, et al. Expires April 28, 2011 [Page 9] Internet-Draft DS-Lite Multicast October 2010 +----------+ +-----------+ -------|Multciast | | v6 Router |------- | AFTR | | | +----------+ +-----------+ | \ / | | \ / | | \ / | | +-----------+ | | | First-Hop | | | |IPv6 Router| | | +-----------+ | IPv4-embedded | | | Native IPv6 Multicast | | | IPv6 Multicast | | | | +----------+ | | | B4 | | | +----------+ | | / \ | V / \ V +------+ +------+ | v4 | | v6 | | Host | | Host | +------+ +------+ Figure 3: Multicast AFTR far from the multicast B4 4.3. Multicast AFTR vs. Unicast AFTR Unlike an unicast AFTR, the Multicast AFTR does not perform any NAT when delivering multicast traffic. A Multicast AFTR is responsible for encapsulating in a stateless manner the IPv4 multicast content into IPv6 identified by a specific group address. Further elaboration is provided in the following sub- sections about the behaviour of the Multicast AFTR and Multicast B4. Unicast AFTR and Multicast AFTR are two functional elements that can be co-located in the same device or be separated. 4.4. IPv4-Embedded IPv6 Address Prefixes One special IPv6 multicast prefix (called mPrefix64) is needed for constructing IPv6 multicast addresses, with IPv4 multicast address embedded. Meanwhile, the address of the IPv4 multicast source (or the RP address in a shared tree environment) should be mapped to IPv6 addresses, so an IPv6 unicast prefix (called uPrefix64) is needed for constructing IPv6 unicast addresses with IPv4 unicast address embedded (the multicast source address or an RP's address). Wang, et al. Expires April 28, 2011 [Page 10] Internet-Draft DS-Lite Multicast October 2010 The same multicast prefix must be used by B4 and Multicast AFTR. 4.5. Multicast Distribution Tree Suppose that an IPv4 receiver has acquired the address of IPv4 multicast group which it is interested in, then the receiver will send an IGMP Report to the Multicast B4 joining that group. After receiving the IGMP Report message, the B4 performs the IGMP-MLD Interworking function in addition to a proxy function as described in [RFC4605]. B4 converts the IGMP message into a MLD Report message which will then be forwarded to the MLD Querier located upstream in the network. In the MLD message, the IPv6 address of the multicast group to be joined is constructed using the preconfigured mPrefix64 and an algorithm, with IPv4 multicast address embedded. If source-specific multicast is deployed, the IPv6 address of the multicast source can be constructed in the same way (using uPrefix64, with IPv4 multicast source embedded). Receiving this MLD membership report on the first IP router will trigger the PIM Join message up to the RP or the multicast source. Make sure the calculated RPF interface for sending PIM Join be on the path up to a Multicast AFTR. Please refer to the Figure 3 above. Or the Multicast AFTR may be embedded in the first IP router where the MLD membership report is processed. Please refer to the Figure 2 above. When the AFTR receives a PIM or MLD Join for an IPv6 group in the range of mPrefix64 from the IPv6 network, it will need to join the corresponding IPv4 multicast group in the IPv4 network. It MUST behave as an IPv4 PIM router and send an IPv4 PIM join. The IPv4 group address can be obtained from the IPv4-Embedded IPv6 address according to a preconfigured algorithm (e.g., the last 32 bits of the IPv4-embedded IPv6 group address). For Source-Specific Multicast the AFTR would in addition check if the source in the Join message belongs to uPrefix64. If so, it can then send a PIM (S, G) Join message directly towards the IPv4 source using the last 32 bits as the IPv4 source. Till now, the multicast distribution tree is established. 4.6. Multicast Forwarding Whenever an IPv4 multicast packet is received on a Multicast AFTR, it will be encapsulated into an IPv6 packet using the IPv4-Embedded IPv6 multicast address as the destination address and an IPv4-Embedded IPv6 unicast address as the source of the IPv4-in-IPv6 packet. The Wang, et al. Expires April 28, 2011 [Page 11] Internet-Draft DS-Lite Multicast October 2010 new IPv6 multicast packet will then be sent through the out interface of the matching entry in the multicast routing table and forwarded down the IPv6 multicast distribution tree towards the B4. When receiving the IPv6 multicast packet sent to this multicast group , B4 should de-capsulate the IPv4-in-IPv6 packet and forward the original IPv4 multicast packet to the IPv4 receiver. 5. Address Mapping 5.1. Prefix Assignment In order to map the addresses of IPv4 multicast traffic to IPv6 multicast addresses, an IPv6 multicast prefix (mPrefix64) and an IPv6 unicast prefix (uPrefix64) are provided to Multicast AFTR and B4 elements. To simplify the implementation, it is recommended to assign prefixes with the length of 96 (could be prefix + suffix set to 0), the address format being left to the responsibility of the service provider [I-D.ietf-behave-address-format]. These two prefixes can be configured onto B4 through some control protocol, such as DHCPv6 or some out-of-band mechanism. Two candidates DHCPv6 options are identified in [I-D.korhonen-behave- nat64-learn-analysis]. 5.2. Text Representation Group address mapping example when a /96 is used: +----------------------+--------------+-----------------------------+ | mPrefix64 | IPv4 address | IPv4-Embedded IPv6 address | +----------------------+--------------+-----------------------------+ | ffxx:abc::/96 | 230.1.2.3 | ffxx:abc::230.1.2.3 | +----------------------+--------------+-----------------------------+ Source address mapping example when a /96 is used: +----------------------+--------------+-----------------------------+ | uPrefix64 | IPv4 address | IPv4-Embedded IPv6 address | +----------------------+--------------+-----------------------------+ | 2001:db8::/96 | 192.1.2.3 | 2001:db8::192.1.2.3 | +----------------------+--------------+-----------------------------+ Wang, et al. Expires April 28, 2011 [Page 12] Internet-Draft DS-Lite Multicast October 2010 6. Multicast B4 6.1. IGMP-MLD Interworking We combine the IGMP/MLD proxying function specified in [RFC4605] and the IGMP-MLD Interworking function. This interworking function is not complex since MLD is a translation of IGMP for IPv6 semantics. Then B4 will perform the router portion of the IGMP protocol on each downstream interface and perform the host portion of the MLD protocol on the upstream interface. Meanwhile, the IGMP-MLD Interworking is performed in between by the B4. The output of the operation is a set of membership information which is maintained separately on each downstream interface. In addition, the membership information on each downstream interface is merged into the membership database on which the IPv4 multicast packets are forwarded by B4. +------+ IGMP +-------+ MLD +--------+ | IPv4 |--------| CPE |---------| Access | | Host | | B4 | | Router | +------+ +-------+ +--------+ Figure 4: IGMP-MPD Interworking Outbound multicast control messages are sent in native IPv6 without any encapsulation. 6.2. Firewalling This document assumes that the CPE is configured to accept incoming MLD messages and traffic forwarded to multicast groups subscribed by receivers located in the customer premises. Considerations on security policy configuration will be elaborated in the next version. 6.3. Address Mapping When an IGMP Report message is received from a receivers to subscribe to multicast group G (e.g., 230.1.2.3) (and optionally a source 192.1.2.3 if SSM mode is used), B4 MUST send an MLD message to subscribe to ffxx:abc::230.1.2.3 (and optionally source 2001:db8:: 192.1.2.3 if SSM mode is used.). 6.4. De-capsulation and Forwarding When B4 receives an IPv6 multicast packet, it checks whether the group address is in the range of mPrefix64. If so, B4 should de- Wang, et al. Expires April 28, 2011 [Page 13] Internet-Draft DS-Lite Multicast October 2010 capsulate the IPv4-in-IPv6 packets to extract the original IPv4 multicast packet. To simplify the implementation, the B4 may join the corresponding IPv6 multicast group to trigger the de-capsulation. Then the IPv4 multicast packet will be forwarded to downstream receivers based on information maintained by the B4 in the membership database. 6.5. Fragmentation Tunnelling IPv4 over IPv6 between Multicast AFTR and Multicast B4 reduces the effective MTU size by the size of an IPv6 header (assuming [RFC2473] encapsulation). To avoid fragmentation, a service provider may increase the MTU size by 40 bytes on the IPv6 network or multicast AFTR and B4 may use IPv6 Path MTU discovery. 7. Multicast AFTR 7.1. Processing PIM/MLD Join Messages After receiving the PIM Join for an IPv6 group, a Multicast AFTR should get the (*, G) entry in the IPv6 multicast routing table and add the IPv6 interface receiving the Join message into the Out- Interface-List of that entry. If the entry does not exist, a new one should be created, as per typical PIM machinery [RFC4601]. The AFTR should check whether the IPv6 group address is inside the mPrefix64, if so, the AFTR will need to extract the IPv4 group address from IPv4-Embedded IPv6 address and get the corresponding (*, G) entry in the IPv4 multicast routing table then add the Tunnel interface into the Out-Interface-List of that entry. If the entry does not exist, a new one should be created and PIM join for the IPv4 group will be sent towards the source connected to the IPv4 network. The initialization of the Tunnel interface on the Multicast AFTR is out of the scope of this document. 7.2. Reliability For robustness, reliability and load distribution purposes, several nodes in the network can embed a Multicast AFTR function. In such case, the same IPv6 prefix and algorithm to build IPv4-Embedded IPv6 addresses MUST be configured on those nodes. 7.3. Routing Considerations Except the need for the multicast AFTR to belong to IPv4 multicast distribution trees and to be on the reverse path towards the source Wang, et al. Expires April 28, 2011 [Page 14] Internet-Draft DS-Lite Multicast October 2010 when performing RPF checks, no further routing constraint is to be taken into account. 7.4. TTL/Scope When Multicast AFTR is deployed for the delivery of multicast-based services to residential customers for instance, the tweaking of the Scope field in the corresponding replicated IPv4-in-IPv6 address SHOULD be global. 7.5. Encapsulation and forwarding When receiving an IPv4 multicast packet, a lookup of IPv4 multicast routing table is performed. If the Tunnel interface is found in the Out-Interface-List of the matching entry, the encapsulation operation is triggered. The multicast AFTR encapsulates in a stateless fashion the IPv4 multicast packet into IPv6. It should use the pre- provisioned mPrefix64 together with an algorithm for building IPv4- Embedded IPv6 address. As an illustration, if a packet is received from 192.1.2.3 and destined to 230.1.2.3, the Multicast AFTR will encapsulate it in an IPv6 packets using ffxx:abc::230.1.2.3 as a destination IPv6 address and 2001:db8::192.1.2.3 as the multicast source address. Then a lookup of IPv6 multicast routing table is performed based on the IPv4-Embedded IPv6 address. If a matching entry is found and there exist IPv6 interfaces in the Out-Interface-List, the IPv6 packet will be sent out through these interfaces and forwarded down the multicast distribution tree towards the Multicast B4s. 7.6. Fragmentation Tunnelling IPv4 over IPv6 between Multicast AFTR and Multicast B4 reduces the effective MTU size by the size of an IPv6 header (assuming [RFC2473] encapsulation). To avoid fragmentation, a service provider may increase the MTU size by 40 bytes on the IPv6 network or multicast AFTR and B4 may use IPv6 Path MTU discovery. 8. Multicast Traffic Optimization 8.1. Co-existence with native IPv6 multicast To be added ... Wang, et al. Expires April 28, 2011 [Page 15] Internet-Draft DS-Lite Multicast October 2010 8.2. Optimization To be added ... 9. Acknowledgements The authors would like to thank Dan Wing for his guidance in the early discussions which initiated this work. We also appreciate Jie Hu, Qiong Sun, Lizhong Jin for their valuable input. 10. IANA Considerations This document includes no request to IANA. 11. Security Considerations To be added ... 12. References 12.1. Normative References [I-D.ietf-behave-address-format] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", draft-ietf-behave-address-format-10 (work in progress), August 2010. [I-D.ietf-mboned-multiaaa-framework] Satou, H., Ohta, H., Hayashi, T., Jacquenet, C., and H. He, "AAA and Admission Control Framework for Multicasting", draft-ietf-mboned-multiaaa-framework-12 (work in progress), August 2010. [I-D.ietf-softwire-dual-stack-lite] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work in progress), August 2010. [I-D.korhonen-behave-nat64-learn-analysis] Korhonen, J. and T. Savolainen, "Analysis of solution proposals for hosts to learn NAT64 prefix", draft-korhonen-behave-nat64-learn-analysis-00 (work in Wang, et al. Expires April 28, 2011 [Page 16] Internet-Draft DS-Lite Multicast October 2010 progress), October 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006. [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. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [TR-101] Broadband Forum, "TR-101: Migration to Ethernet-Based DSL Aggregation", 2006. 12.2. Informative References [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. Wang, et al. Expires April 28, 2011 [Page 17] Internet-Draft DS-Lite Multicast October 2010 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source- Specific Multicast", RFC 4604, August 2006. [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. [RFC4608] Meyer, D., Rockell, R., and G. Shepherd, "Source-Specific Protocol Independent Multicast in 232/8", BCP 120, RFC 4608, August 2006. Appendix A. Translation vs. Encapsulation In order to deliver IPv4 multicast flows to DS-Lite serviced receivers, two options can be considered: A.1. Translation For IPv4 content, introduce IPv4-IPv6 translation capabilities in the network. Multicast streams will then be delivered to the receivers using IPv6 until the CPE. A second level of NAT can then be enforced if the receiver is IPv4-only. o Analysis: This solution may require two translation levels, can impact the overall performance of the CPE, may alter the perceived quality of experience, etc. This solution may be the source of service disruption (especially for live TV broadcasting). This is not desirable. For IPv6 content, all streams are delivered to the DS-Lite CPE using IPv6; an IPv4-IPv6 translator can be enabled in the CPE to forward the streams to an IPv4-only receiver. o Analysis: The IPv4-IPv6 translation function may impact the performance of the CPE. A.2. Encapsulation To access IPv4 content from an IPv4-only or dual-stack receiver: introduce a new function called Multicast DS-Lite AFTR in the network. Multicast streams are forwarded to a receiver by using an IPv4-in-IPv6 encapsulation scheme. The encapsulation/de- capsulation Wang, et al. Expires April 28, 2011 [Page 18] Internet-Draft DS-Lite Multicast October 2010 function is stateless owing to the use of IPv4-Embedded IPv6 address [I-D.ietf-behave-address-format]. MTU and fragmentation should be carefully taken care of to avoid service degradation. To access IPv6 content from a dual-stack receiver: no new function is required. Multicast IPv6 can be used. Authors' Addresses Qian Wang China Telecom No.118, Xizhimennei Beijing, 100035 China Phone: +86 10 5855 2177 Email: wangqian@ctbri.com.cn Jacni Qin ZTE Shanghai, China Phone: +86 1391 8619 913 Email: jacniq@gmail.com Peng Sun ZTE Shanghai, China Phone: +86 21 6889 7101 Email: sun.peng@zte.com.cn Mohamed Boucadair France Telecom Rennes, 35000 France Phone: Email: mohamed.boucadair@orange-ftgroup.com Wang, et al. Expires April 28, 2011 [Page 19] Internet-Draft DS-Lite Multicast October 2010 Christian Jacquenet France Telecom Rennes, 35000 France Phone: Email: christian.jacquenet@orange-ftgroup.com Wang, et al. Expires April 28, 2011 [Page 20]