Softwire WG Q. Wang Internet-Draft China Telecom Intended status: Standards Track J. Qin Expires: July 11, 2011 P. Sun ZTE M. Boucadair C. Jacquenet France Telecom Y. Lee Comcast January 7, 2011 Multicast Extensions to DS-Lite Technique in Broadband Deployments draft-qin-softwire-dslite-multicast-02 Abstract This document proposes a solution for the delivery of multicast service offerings to DS-Lite serviced customers. The proposed solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme and does not require performing any NAT operation along the path used to deliver multicast traffic. 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 July 11, 2011. Copyright Notice Copyright (c) 2011 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 Wang, et al. Expires July 11, 2011 [Page 1] Internet-Draft DS-Lite Multicast January 2011 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Context and Scope . . . . . . . . . . . . . . . . . . . . . . 4 3.1. IPTV-centric View . . . . . . . . . . . . . . . . . . . . 4 3.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Mitigation Alternatives . . . . . . . . . . . . . . . . . 5 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. IPv4-embedded IPv6 Address Prefixes . . . . . . . . . . . 7 4.3. Multicast Distribution Tree . . . . . . . . . . . . . . . 8 4.4. Multicast Forwarding . . . . . . . . . . . . . . . . . . . 9 4.5. Multicast DS-Lite vs. Unicast DS-Lite . . . . . . . . . . 9 5. Address Mapping . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 9 5.2. Text Representation Examples . . . . . . . . . . . . . . . 10 6. Multicast B4 (mB4) . . . . . . . . . . . . . . . . . . . . . . 10 6.1. IGMP-MLD Interworking function . . . . . . . . . . . . . . 10 6.2. De-capsulation and Forwarding . . . . . . . . . . . . . . 11 6.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 11 7. Multicast AFTR (mAFTR) . . . . . . . . . . . . . . . . . . . . 11 7.1. Routing Considerations . . . . . . . . . . . . . . . . . . 11 7.2. Processing PIM/MLD Join Messages . . . . . . . . . . . . . 12 7.3. Reliability . . . . . . . . . . . . . . . . . . . . . . . 12 7.4. ASM Mode: Building Shared Trees . . . . . . . . . . . . . 12 7.4.1. IPv4 Side . . . . . . . . . . . . . . . . . . . . . . 12 7.4.2. IPv6 Side . . . . . . . . . . . . . . . . . . . . . . 13 7.5. TTL/Scope . . . . . . . . . . . . . . . . . . . . . . . . 14 7.6. Encapsulation and forwarding . . . . . . . . . . . . . . . 14 8. Optimization in L2 Access Networks . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9.1. Firewall Configuration . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Wang, et al. Expires July 11, 2011 [Page 2] Internet-Draft DS-Lite Multicast January 2011 1. Introduction DS-Lite [I-D.ietf-softwire-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 customers access IPv4 multicast-based service offerings through a DS-Lite environment, AFTR (Address Family Transition Router) devices have to process all the IGMP reports [RFC2236] [RFC3376] received within IPv4-in-IPv6 tunnels and behave as a replication point for downstream multicast traffic. That is likely to severely 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 while the AFTR capability may become rapidly overloaded, in particular if the AFTR capability is deployed in a centralized manner. This document discusses an extension to the DS-Lite model to be used for the delivery of IPv4 multicast-based service offerings. 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. An IPv4-embedded IPv6 address can be unicast or multicast. o mPrefix64: is a dedicated multicast IPv6 prefix for constructing IPv4-embedded IPv6 multicast address [I-D.boucadair-behave-64-multicast-address-format]. mPrefix64 can be of two types: ASM_mPrefix64 used in ASM mode or SSM_mPrefix64 used in SSM mode [RFC4607]. o uPrefix64: is a dedicated unicast IPv6 prefix for constructing IPv4-embedded IPv6 unicast address [RFC6052]. o Multicast AFTR (mAFTR for short): is a functional entity which is part of both the IPv4 and IPv6 multicast distribution trees and Wang, et al. Expires July 11, 2011 [Page 3] Internet-Draft DS-Lite Multicast January 2011 which replicates IPv4 multicast streams into IPv4-in-IPv6 streams in the relevant branches of the IPv6 multicast distribution tree. o Multicast B4 (mB4 for short): is a functional entity embedded in a CPE, which is able to enforce an IGMP-MLD interworking function ( refer to Section 6.1) together with a de-capsulation function of received multicast IPv4-in-IPv6 packets. 3. Context and Scope 3.1. IPTV-centric View IPTV generally includes two categories of service offerings: 1. VoD (Video on Demand) or Catch-up TV channels streams that are delivered using unicast mode to receivers. 2. Live TV Broadcast services that are generally multicast to receivers. Numerous players intervene in the delivery of this service: o Content Providers: the content can be provided by the same provider as the one providing the connectivity service or by distinct providers; o Network Provider: the one providing network connectivity service (e.g., responsible for carrying multicast flows from head-ends to receivers). Refer to [I-D.ietf-mboned-multiaaa-framework]. Many of the current IPTV contents are likely to remain IPv4-formatted and out of control of the network providers. Additionally, there are numerous legacy receivers (e.g., IPv4-only Set Top Boxes (STB)) that can't be upgraded or be easily replaced. As a consequence, IPv4 service continuity must be guaranteed during the transition period, including the delivery of multicast-based services such as Live TV Broadcasting. The dilemma is the same as in the transition of unicast-based Internet services where the customer premises and global Internet are out of control of the service providers even if they would like to promote the use of IPv6. The DS-Lite design tries to eliminate this issue by decoupling the IPv6 deployments in service provider networks from that in global Internet and in customer devices and applications. DS-Lite can be seen as a catalyst for IPv6 deployment while preserving customer's Quality of Experience (QoE). This is also the design goal of the solution proposed in this document for DS-Lite Wang, et al. Expires July 11, 2011 [Page 4] Internet-Draft DS-Lite Multicast January 2011 serviced customers who have subscribed to a multicast-based service offering. 3.2. Scope This document focuses only on issues raised by a DS-Lite networking environment: subscription to an IPv4 multicast group and the delivery of IPv4-formatted content to IPv4 receivers. In particular, only the following case is covered: 1. An IPv4 receiver accessing IPv4 content (i.e., content formatted and reachable in IPv4) This document does not cover the case where an IPv4 host connected to a CPE served by a DS-Lite AFTR can be the source of multicast traffic. 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. 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 separate IPv4 addressing scheme for the delivery of multicast-based service offerings. Service-specific IPv4 addresses are then assigned to multicast receivers to access a multicast-based service offering. In such case, no extra complication is raised for this deployment scenario. This approach is out of scope of this document. For Service Providers who use a service-agnostic IP addressing scheme (i.e., only one IP address is assigned to access all subscribed services), dedicated solutions are to be specified to deliver multicast content to DS-Lite serviced customers. This document focuses on this scenario. 4. Solution Overview In the original DS-Lite specification [I-D.ietf-softwire-dual-stack-lite], an IPv4-in-IPv6 tunnel is used to carry the bidirectional IPv4 unicast traffic between B4 and AFTR. This document defines an IPv4-in-IPv6 encapsulation scheme to deliver multicast traffic. Within the context of this document, an IPv4 derived IPv6 multicast address is used as the destination of the encapsulated unidirectional IPv4-in-IPv6 multicast traffic from the Wang, et al. Expires July 11, 2011 [Page 5] Internet-Draft DS-Lite Multicast January 2011 mAFTR to the mB4. The IPv4 address of the source of the multicast content is represented in the IPv6 realm with an IPv4-embedded IPv6 address as well. See following sections for the multicast distribution tree establishment (Section 4.3) and the multicast traffic forwarding (Section 4.4). Note that IPv4-in-IPv6 encapsulated multicast flows are treated in an IPv6 realm like any other IPv6 multicast flow. Upon completion of the establishment of a multicast distribution tree, no extra function is required to be defined to forward IPv4-in-IPv6 multicast traffic in the IPv6 network. 4.1. Rationale This document introduces two new functional elements (Figure 1): 1. The mAFTR: responsible for replicating IPv4 multicast flows in the IPv6 domain owing to a stateless IPv4-in-IPv6 encapsulation function. The mAFTR does not undertake any NAT operation. The mAFTR is a demarcation point which connects to both the IPv4 and IPv6 multicast networks. 2. The mB4: is a functional entity embedded in a CPE responsible for the de-capsulation of the received IPv4-in-IPv6 multicast packets and forwarding them to the appropriate IPv4 receivers. Wang, et al. Expires July 11, 2011 [Page 6] Internet-Draft DS-Lite Multicast January 2011 +-----------+ | IPv4 | | Source | +-----------+ | ------------ / \ | IPv4 network | \ / ------------ | +-------------+ | mAFTR | +-------------+ | ------------ / \ | IPv6 network | \ / ------------ | +-----------+ | mB4 | +-----------+ | +-----------+ | IPv4 | | Receiver | +-----------+ Figure 1: Functional Architecture 4.2. IPv4-embedded IPv6 Address Prefixes A dedicated IPv6 multicast prefix (mPrefix64) is needed for forming IPv6 multicast addresses, with IPv4 multicast address embedded. The mPrefix64 can be of two types: ASM_mPrefix64 (an mPrefix64 used in ASM mode) or SSM_mPrefix64 (an mPrefix64 used in SSM mode), and MUST be derived from the corresponding IPv6 multicast address space [I-D.boucadair-behave-64-multicast-address-format]. In addition, the address of the IPv4 multicast source should be mapped to IPv6 addresses in the IPv6 realm: an IPv6 unicast prefix (uPrefix64) is therefore needed for forming IPv6 unicast addresses with IPv4 unicast address embedded. The uPrefix64 MUST be derived from the IPv6 unicast address space [RFC6052]. The mAFTR and mB4 MUST use the same mPrefixe64 and uPrefix64, and the Wang, et al. Expires July 11, 2011 [Page 7] Internet-Draft DS-Lite Multicast January 2011 same algorithm for building IPv4-embedded IPv6 addresses. Refer to Section 5 for more details on the IPv6 address format. 4.3. Multicast Distribution Tree Assume that an IPv4 receiver sends an IGMP Report towards the mB4 to join a given multicast group. After receiving the IGMP Report message, the mB4 converts the IGMP message into a MLD Report [RFC2710] message which will then be forwarded upstream towards the MLD Querier. The MLD Querier is likely to coexist with the PIM DR where the PIMv6 Join message will be triggered and sent up hop by hop along the PIMv6 routers. Note that the mAFTR is in the path to reach the IPv4 source; this is typically achieved by the underlying unicast IPv6 routing protocol that advertises the unicast IPv4-embedded IPv6 addresses: these addresses are used to represent IPv4 sources in the IPv6 multicast domain. Both the MLD and the PIMv6 Join messages convey the IPv6 address of the multicast group to be joined. The corresponding IPv6 multicast group address is constructed by using the pre-configured mPrefix64 and an algorithm so that the IPv4 multicast group address is embedded accordingly. When source-specific multicast is deployed, the IPv6 address of the multicast source should be constructed in the same way (using uPrefix64, with IPv4 multicast source embedded). Refer to Section 6.1 for more details of the mB4 function. o If the mAFTR is embedded in the MLD Querier/PIMv6 DR, it should process the received MLD Report message for the IPv4-embedded IPv6 group and send the corresponding IPv4 PIM Join message. o If the mAFTR is embedded in some upstream PIMv6 router more than one hop away from the mB4, it should process the received PIMv6 Join message for the IPv4-embedded IPv6 group and send the corresponding IPv4 PIM Join message. In both cases, an entry for an IPv6 multicast group address is created by the mAFTR in its multicast Routing Information Base and is used to forward multicast IPv4-in-IPv6 datagrams. Refer to Section 7.1 for more details about the mAFTR function. A branch of the multicast distribution tree is then established, comprising both an IPv4 part (from the mAFTR upstream) and an IPv6 part (between the mB4 and the mAFTR). Wang, et al. Expires July 11, 2011 [Page 8] Internet-Draft DS-Lite Multicast January 2011 4.4. Multicast Forwarding Whenever an IPv4 multicast packet is received on a mAFTR (this assumes the RPF Check has passed Section 7.1), 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 new IPv6 multicast packet will then be sent through the outgoing interface of the matching entry in the multicast routing table and forwarded down the IPv6 multicast distribution tree towards the mB4. When receiving the packet, the mB4 should de-capsulate it and forward the original IPv4 multicast packet to the appropriate receiver. If mB4 does not have any route to forward the packet (e.g., change of the IPv4 address without cleaning MLD states), the encapsulated IPv4 datagram is silently dropped. 4.5. Multicast DS-Lite vs. Unicast DS-Lite Unlike a unicast AFTR, a mAFTR does not perform any NAT for delivering IPv4 multicast traffic. Unlike unicast DS-Lite, a mB4 does not need to discover a mAFTR. mAFTR is responsible for encapsulating in a stateless manner the IPv4 multicast traffic into IPv6 datagrams. mB4 is responsible for de- capsulating in a stateless manner the IPv4-in-IPv6 multicast traffic. Further elaboration is provided in the following sections about the behaviour of the mAFTR and the mB4. The corresponding multicast DS-Lite and the unicast DS-Lite functional elements can be co-located in the same device or separated. 5. Address Mapping 5.1. Prefix Assignment In order to map the addresses of IPv4 multicast traffic with IPv6 multicast addresses, an IPv6 multicast prefix (mPrefix64) and an IPv6 unicast prefix (uPrefix64) are provided to mAFTR and mB4 elements. The address format to be used is being left to the responsibility of the service provider as indicated in [RFC6052] and [I-D.boucadair-behave-64-multicast-address-format]. The mPrefix64 and uPrefix64 together with the address format to be Wang, et al. Expires July 11, 2011 [Page 9] Internet-Draft DS-Lite Multicast January 2011 used can be configured in the mB4 through a dedicated provisioning protocol, such as DHCPv6 or another protocol. Two candidate DHCPv6 options are identified in [I-D.korhonen-behave-nat64-learn-analysis]. 5.2. Text Representation Examples 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 | +----------------------+--------------+-----------------------------+ 6. Multicast B4 (mB4) 6.1. IGMP-MLD Interworking function IGMP-MLD Interworking function combines the IGMP/MLD Proxying function specified in [RFC4605] and the IGMP/MLD adaptation function which is meant to reflect the contents of IGMP messages into MLD messages. Then mB4 performs the router portion of the IGMP protocol on each downstream interface and performs the host portion of the MLD protocol on the upstream interface (Figure 2). The output of the operation is a set of membership information which is maintained separately on each downstream interface (e.g., Wifi and Wired Ethernet). In addition, the membership information on each downstream interface is merged into the membership database on which the IPv4 multicast packets are forwarded by mB4. Wang, et al. Expires July 11, 2011 [Page 10] Internet-Draft DS-Lite Multicast January 2011 +----------+ IGMP +-------+ MLD +---------+ | IPv4 |---------| CPE |---------| MLD | | Receiver | | mB4 | | Querier | +----------+ +-------+ +---------+ Figure 2: IGMP-MLD Interworking When an IGMP Report message is received from a receiver to subscribe to a given multicast group G (e.g., 230.1.2.3) (and optionally associated to a source 192.1.2.3 if SSM mode is used), the mB4 MUST send an MLD Report message to subscribe to the corresponding IPv6 group identified by an IPv4-embedded IPv6 multicast address using a pre-configured prefix and algorithm (e.g., ffxx:abc::230.1.2.3 (and optionally source 2001:db8::192.1.2.3 if SSM mode is used)). The MLD Report message is sent through the upstream interface natively (i.e., without any encapsulation). 6.2. De-capsulation and Forwarding When the mB4 receives an IPv6 multicast packet, it checks whether the group address is in the range of mPrefix64 and the source address is in the range of uPrefix64. If it is true, the mB4 MUST de-capsulate the IPv4-in-IPv6 packets to extract the original IPv4 multicast packets. Then the IPv4 multicast packet will be forwarded to downstream receivers based on information maintained by the mB4 in the membership database. If no route is found, the packet is silently dropped. 6.3. Fragmentation Encapsulating IPv4 over IPv6 from mAFTR to mB4 for data forwarding 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 mAFTR and mB4 may use IPv6 Path MTU discovery. 7. Multicast AFTR (mAFTR) 7.1. Routing Considerations Except the need for the mAFTR to belong to IPv4 multicast distribution trees and to be on the reverse path towards the source when performing RPF checks on PIMv6 routers, no further routing constraint is to be taken into account. Wang, et al. Expires July 11, 2011 [Page 11] Internet-Draft DS-Lite Multicast January 2011 Having the mAFTR in the reverse path ensures PIM Join sent to the source (e.g., SSM mode or SPT mode in ASM) will be intercepted by the mAFTR. 7.2. Processing PIM/MLD Join Messages Upon receipt of the PIM/MLD Join for an IPv6 group (e.g., ffxx:abc:: 230.1.2.3), the mAFTR checks the corresponding entry in the IPv6 multicast routing table and adds the IPv6 interface through which the Join message has been received into the Out-Interface-List of that entry. If the entry does not exist, a new one will be created, as per typical PIM machinery [RFC4601]. The mAFTR should check whether the IPv6 group address belongs to the mPrefix64 (e.g., ffxx: abc::/96). If so, the mAFTR will need to extract the IPv4 group address (e.g., 230.1.2.3) from the IPv4-embedded IPv6 address (e.g., according to [I-D.boucadair-behave-64-multicast-address-format]) and check the corresponding 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 entry should be created and a PIM join message for that IPv4 group will be sent towards the RP or source connected to the IPv4 network. When SSM is deployed, the mAFTR would in addition check if the source (e.g., 2001:db8::192.1.2.3) described in the PIMv6 Join message belongs to uPrefix64 (e.g., 2001:db8::/96). If so, it can then send a PIM (S, G) Join message directly towards the IPv4 source (e.g., 192.1.2.3). The initialization of the tunnel interface (used for encapsulation purposes) on the mAFTR is out of the scope of this document. 7.3. Reliability For robustness, reliability and load distribution purposes, several nodes in the network can embed the mAFTR function. In such case, the same IPv6 prefixes (i.e., mPrefix64 and uPrefix64) and algorithm to build IPv4-embedded IPv6 addresses MUST be configured on those nodes. 7.4. ASM Mode: Building Shared Trees 7.4.1. IPv4 Side For a given Rendezvous Point (RP) used in the IPv4 realm, there is no new requirement. Like any other IPv4 PIM router, the RP of each IPv4 multicast groups is configured to the mAFTR or discovered using some appropriate means. Moreover, PIM-SM registration procedure [RFC4601] in the IPv4 realm is not impacted. Wang, et al. Expires July 11, 2011 [Page 12] Internet-Draft DS-Lite Multicast January 2011 Shared IPv4 multicast trees are built using the procedure defined in [RFC4601] for instance. 7.4.2. IPv6 Side In the IPv6 side, the RP of IPv4-embedded IPv6 multicast groups is configured to all IPv6 PIM routers or discovered using appropriate means. For the sake of simplicity, it is RECOMMENDED to configure an mAFTR as the RP for IPv4-embedded IPv6 multicast groups. [Note 1: If some other IPv6 multicast router wants to become the RP of the IPv4-embedded IPv6 multicast groups, it may require an mAFTR to emulate the PIM Source Register procedure on behalf of IPv4-embedded IPv6 sources with the RP. The PIM Source Register procedure in the IPv4 domain is not altered.] [Note 2: How the mAFTR is aware about the sources? This can be considered as deployment-specific: (i) By configuration: mAFTR can be configured to join a set of IPv4 multicast groups and to initiate a registration procedure on behalf of a set of sources to the RP in the v6 domain; (ii) Dynamic: this assumes that mAFTR is configured to join a set of IPv4 multicast groups. The source address of received flows will be used as a trigger to initiate the registration procedure to the RP in the IPv6 domain. There is a special case where mAFTR is the RP of the IPv4 group in the IPv4 domain: The registration procedure should then be relayed to the RP in the IPv6 domain. ] Shared IPv6 multicast trees are built using the procedure defined in [RFC4601] for instance. Switching from a shared tree to source-based tree can be accommodated since the mAFTR is in the path to join the source. The mAFTR will graft to the IPv4 shared tree either because it has been configured with the list of IPv4 multicast groups that will be subscribed by the DS-Lite serviced receivers downstream or upon receipt of a PIMv6 Join message. An example of the exchange of PIM messages is illustrated in Figure 3. Wang, et al. Expires July 11, 2011 [Page 13] Internet-Draft DS-Lite Multicast January 2011 ------------ / \ | IPv4 network | \ / ------------ : | ^ IPv4 Multicast : | : PIMv4 Join v | : +-------------+ | mAFTR | +-------------+ |:| | ^ IPv6 Multicast |:| | : (PIMv6 Join, PIMv6 Routers in between) (IPv4 embedded) |.| ... . ------------ / \ | IPv6 network | \ / ------------ |:| | : MLD Report |v| | : +-----------+ | mB4 | +-----------+ : | ^ IPv4 Multicast : | : IGMP Report v | : +-----------+ | IPv4 | | Receiver | +-----------+ Figure 3: Procedure Overview 7.5. TTL/Scope The Scope field of IPv4-in-IPv6 multicast addresses can be valued to "E" (Global scope) or to "8" (Organization-local scope). This is left to service providers taste. 7.6. Encapsulation and forwarding When receiving an IPv4 multicast packet, a lookup of the IPv4 multicast routing table is performed by the PIMv4 router that embeds the mAFTR capability. If an interface used for IPv4-in-IPv6 encapsulation is found in the Out-Interface-List of the matching entry, the encapsulation operation is triggered. The mAFTR encapsulates in a stateless fashion the IPv4 multicast packet into an Wang, et al. Expires July 11, 2011 [Page 14] Internet-Draft DS-Lite Multicast January 2011 IPv6 multicast datagram. It MUST use the pre-provisioned mPrefix64/ uPrefix64 together with an algorithm for building the IPv4-embedded IPv6 multicast address that identifies the multicast group, as well as the IPv6 source address that represents the IPv4 source in the IPv6 network. As an illustration, if a packet is received from source 192.1.2.3 and forwarded to group 230.1.2.3, the mAFTR encapsulates it into an IPv6 multicast packet using ffxx:abc::230.1.2.3 as the destination IPv6 address and 2001:db8::192.1.2.3 as the multicast source address. Then a lookup of the IPv6 multicast routing table is performed by the PIMv6 router that embeds the mAFTR capability, 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 multicast packet will be sent out through these interfaces and forwarded down the multicast distribution tree towards the mB4 devices. 8. Optimization in L2 Access Networks The approach specified in this document is compatible with a Layer-2 infrastructure which may be involved for deterministic multicast replication. The IPv4-in-IPv6 encapsulated multicast flows destined to IPv4- embedded IPv6 group addresses are treated as any IPv6 multicast flow, and can be replicated within Multicast VLANs. Additionally, mechanisms such as MLD Snooping, MLD Proxying, etc., can be introduced into the distributed Access Network Nodes (e.g., Aggregation Switches, xPON devices) which then could behave as MLD Querier and replicate multicast flows as appropriate. Thus, the multicast replication point is moved downward closer to the receivers, so that bandwidth consumption is optimized. 9. Security Considerations This document does not introduce any new security concern in addition to what is discussed in Section 5 of [RFC6052], Section 10 of [RFC3810] and Section 6 of [RFC4601]. 9.1. Firewall Configuration The CPE should be configured to accept incoming MLD messages and traffic forwarded to multicast groups subscribed by receivers located in the customer premises. Wang, et al. Expires July 11, 2011 [Page 15] Internet-Draft DS-Lite Multicast January 2011 10. 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. 11. IANA Considerations This document includes no request to IANA. 12. References 12.1. Normative References [I-D.boucadair-behave-64-multicast-address-format] Boucadair, M., Qin, J., and Y. Lee, "IPv4-Embedded IPv6 Multicast Address Format", draft-boucadair-behave-64-multicast-address-format-00 (work in progress), December 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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Wang, et al. Expires July 11, 2011 [Page 16] Internet-Draft DS-Lite Multicast January 2011 Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006. [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. 12.2. Informative References [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.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 progress), October 2010. [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. [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. [RFC4608] Meyer, D., Rockell, R., and G. Shepherd, "Source-Specific Protocol Independent Multicast in 232/8", BCP 120, RFC 4608, August 2006. Wang, et al. Expires July 11, 2011 [Page 17] Internet-Draft DS-Lite Multicast January 2011 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 Christian Jacquenet France Telecom Rennes, 35000 France Phone: Email: christian.jacquenet@orange-ftgroup.com Wang, et al. Expires July 11, 2011 [Page 18] Internet-Draft DS-Lite Multicast January 2011 Yiu L. Lee Comcast U.S.A. Phone: Email: yiu_lee@cable.comcast.com URI: http://www.comcast.com Wang, et al. Expires July 11, 2011 [Page 19]