BEHAVE Working Group Y. Lee Internet-Draft Comcast Intended status: Informational J. Qin Expires: August 25, 2011 ZTE February 21, 2011 IPv4/IPv6 Multicast Translation Framework draft-lee-behave-v4v6-mcast-fwk-00 Abstract The note describes a framework for IPv4/IPv6 translation of multicast traffic. This note discusses various multicast scenarios while transitioning IPv4 multicast to IPv6 multicast. 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 August 25, 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 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. Lee & Qin Expires August 25, 2011 [Page 1] Internet-Draft MCast Translation Framework February 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Translation Objectives . . . . . . . . . . . . . . . . . . . . 3 4. Scenarios Overview . . . . . . . . . . . . . . . . . . . . . . 4 4.1. From the IPv4 source to the IPv6 receiver . . . . . . . . 4 4.2. From the IPv6 source to the IPv4 receiver . . . . . . . . 4 5. Location of the Multicast Translator . . . . . . . . . . . . . 5 5.1. Scenario 1: mXlate46 is not the DR of the IPv4 source . . 6 5.2. Scenario 2: mXlate is the DR of the IPv4 source . . . . . 7 5.3. Scenario 3: mXlate is the MLD Querier . . . . . . . . . . 8 5.4. Scenario 4: mXlate is not the DR of the IPv6 source . . . 8 5.5. Scenario 5: mXlate is the DR of the IPv6 source . . . . . 9 5.6. Scenario 6: mXlate is the IGMP Querier . . . . . . . . . . 10 6. Translation Components . . . . . . . . . . . . . . . . . . . . 10 6.1. Address Translation . . . . . . . . . . . . . . . . . . . 10 6.2. Multicast Translator (mXlate) . . . . . . . . . . . . . . 11 6.2.1. mXlate in ASM . . . . . . . . . . . . . . . . . . . . 11 6.2.2. mXlate in SSM . . . . . . . . . . . . . . . . . . . . 12 6.2.3. Interchanging ASM and SSM . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Lee & Qin Expires August 25, 2011 [Page 2] Internet-Draft MCast Translation Framework February 2011 1. Introduction [I-D.ietf-behave-v6v4-framework] describes the framework for IPv4/ IPv6 translation of unicast. This document is a companion note to describe the framework for IPv4/IPv6 translation of multicast. 2. Terminology 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 [RFC2119]. In addition, this note uses the terminology defined in [I-D.ietf-behave-v6v4-framework]. 3. Translation Objectives Similar to unicast translation, the objective of multicast translation is enabling the source in one address family to deliver multicast packets to the receiver in a different address family. For multicast applications, there is usaully one source with one or more receivers. In Any-Source Multicast (ASM), the receivers join the multicast distribution tree only depending on the multicast group address. The multicast streams delivered by any source to that multicast group address will be accepted by the receivers. In Source-Specific Multicast (SSM), the receivers join the multicast distribution tree depending on the mulitcast group address and source address pair. Only mulitcast streams delivered by that given source to that multicast group address will be accepted by the receivers. Sometimes, multicast is used for local service discovery (e.g., OSPF Multicast addresses); however, we argue that this type of multicast should not be translated. Multicast is also used for media delivery such as broadcast videos and live events. In this memo, these are the primary services for translation. To enable multicast translation, both multicast protocols (e.g., IGMP, PIM, etc.) and multicast packets are required to be translated. When designing solutions, the existing multicast protocols should be utilized as much as possible. In addition, the framework should ensure the packet replication of multicast packets happens at the edge of the network close to the multicast receivers. Lee & Qin Expires August 25, 2011 [Page 3] Internet-Draft MCast Translation Framework February 2011 4. Scenarios Overview Since the multicast data stream is unidirectional and is forwarded from the source to the receivers, there are generally two categories of IPv4/IPv6 translation scenarios per multicast stream: 1. From the IPv4 source to the IPv6 receivers. 2. From the IPv6 source to the IPv4 receivers. Note that a receiver of given multicast stream may become the source of another multicast stream. As such, a multicast receiver may turn the received stream (i.e. which may pass through the translator too) and become the source of another receiver. In the context of this document, they should be treated as two independent multicast streams. 4.1. From the IPv4 source to the IPv6 receiver There is a requirement for the legacy IPv4 multicast source to provide services to the IPv6 receivers. +-----------+ +------------+ +----------+ | IPv6 | ...... | Multicast | ...... | IPv4 | | Receivers | | Translator | | Source | +-----------+ +------------+ +----------+ Figure 1 In this case, the multicast traffic is IPv4 framed. The IPv4- formatted multicast is translated to IPv6-formatted by a Multicast Translator (mXlate) and forwarded to the IPv6 receivers. The procedures of multicast data subscribing and forwarding are different according to the different locations of the Multicast Translator. Refer to following sections for details. 4.2. From the IPv6 source to the IPv4 receiver This scenario applies to the environment where the IPv6 multicast source may still need to provide services to the IPv4 receivers. Lee & Qin Expires August 25, 2011 [Page 4] Internet-Draft MCast Translation Framework February 2011 +-----------+ +------------+ +----------+ | IPv4 | ...... | Multicast | ...... | IPv6 | | Receivers | | Translator | | Source | +-----------+ +------------+ +----------+ Figure 2 In this case, the multicast traffic is IPv6 framed. The IPv6- formatted multicast is translated to IPv4-formatted by a Multicast Translator (mXlate) and forwarded to the IPv4 receivers. The procedures of multicast data subscribing and forwarding are different according to the different locations of the Multicast Translator. Refer to following sections for details. 5. Location of the Multicast Translator In general, the scheme provisioning multicast can be represented as Figure 3 +--------+ | Source | +--------+ | +------+ | DR | +------+ | ------------ / Multicast \ The tree may consist of both IPv4 | Distribution | segment and IPv6 segment joining at \ Tree / the point of the "translator". ------------ | +----------+ | IGMP/MLD | | Querier | +----------+ / \ / \ +----------+ +----------+ | Receiver | | Receiver | +----------+ +----------+ Lee & Qin Expires August 25, 2011 [Page 5] Internet-Draft MCast Translation Framework February 2011 Figure 3 The Multicast Translator (mXlate) places a special rule in the translation. It joins both the IPv4 multicast distribution tree and IPv6 multicast distribution tree. The mXlate is responsible for translating the multicast protocols then utilizing the multicast distribution tree to distribute the translated packets. In this memo, we consider both Any-Source Multicast (ASM) and Source-Specific Multicast (SSM). Depending on the variable locations of the mXlate, each of the two translation scenarios (i.e. v4 source to v6 receivers; v6 source to v4 receivers) can be further divided into three scenarios. For IPv4->IPv6 (mXlate S4R6) Scenario 1: mXlate is not the DR of the IPv4 source Scenario 2: mXlate is the DR of the IPv4 source Scenario 3: mXlate is the MLD Querier For IPv6->IPv4 (mXlate S6R4) Scenario 4: mXlate is not the DR of the IPv6 source Scenario 5: mXlate is the DR of the IPv6 source Scenario 6: mXlate is the ICMP Querier 5.1. Scenario 1: mXlate46 is not the DR of the IPv4 source In this scenario, the access network is an IPv6-only network, the multicast source is still IPv4 and it is in the IPv4 regime. The mXlate will be deployed between the IPv4 and IPv6 regimes. The mXlate is not directly connected to the source as such it is not the Designated Router of the IPv4 multicast source group. Lee & Qin Expires August 25, 2011 [Page 6] Internet-Draft MCast Translation Framework February 2011 ------- // \\ ----------- / \ // \\ / +------+ \ R6===MR IPv6 |mXlate| IPv4 (S4/RP) | Network +------+ Network / \ / \\ // RP = Rendezvous Point \\ // ----------- S4 = v4 Multicast Source -------- MR = Multicast Router ----> ------------> ------------> R6 = v6 Receiver MLD PIMv6-Join PIMv4-Join <=========== <=========== IPv6 Mcast IPv4 Mcast Figure 4 This is typical transition scenario in the early phase. The access network is IPv6-only, but the multicast source is located in an IPv4 network. The mXlate is centralized in the network which can be used to serve multiple regions. This scenario is suitable for early transition where there are not many IPv6 receivers requesting IPv4 multicast sources. 5.2. Scenario 2: mXlate is the DR of the IPv4 source In this scenario, the access network is an IPv6-only network, the multicast source is still IPv4. The mXlate and the IPv4 multicast source is on the same network, and the mXlate is also the Designated Router. ------- // \\ / \ | / +------+ | R6 = v6 Receiver R6===MR IPv6 |mXlate|----| MR = Multicast Router | Network +------+ |- S4 S4 = v4 Multicast Source \ / | \\ // -------- ----> ------------> MLD PIMv6-Join <============= IPv6 Mcast Lee & Qin Expires August 25, 2011 [Page 7] Internet-Draft MCast Translation Framework February 2011 Figure 5 This could happen if the network and multicast receivers have migrated to IPv6; however, the multicast source have yet to migrate to IPv6. mXlate is directly connected to the multicast source and responsible for translating the IPv4 multicast packets to IPv6 multicast packets to the IPv6 receivers. 5.3. Scenario 3: mXlate is the MLD Querier In this scenario, the entire network is stll IPv4; however, the receiver is IPv6-only. The mXlate is the immediate multicast router of the IPv6-only receiver. ------- // \\ ----------- / \ // \\ +------+ +----+ \ R6==|mXlate|========| MR | IPv4 (S4/RP) +------+ IPv4 +----+ Network / \ Network / \\ // \\ // ----------- RP = Rendezvous Point -------- S4 = v4 Multicast Source ----> -------------> ------------> MR = Multicast Router MLD ICMP PIMv4-Join R6 = v6 Receiver <====== <============================= IPv6 Mcast IPv4 Mcast Figure 6 This scenario is a typical setup for ISPs which face a real shortage of IPv4 addresses for the new devices but not yet finished the entire network upgrade to IPv6 to support multicast. IPv6 will be deployed between the edge router (e.g. BNG) and home. 5.4. Scenario 4: mXlate is not the DR of the IPv6 source In this scenario, an IPv4 multicast network with receivers is connected through mXlate to an IPv4 multicast network where the source is located. The mXlate translates the IPv6 formatted mulitcast source to IPv4 and distributes translated packets through the multicast distribution tree in the IPv4 network. Lee & Qin Expires August 25, 2011 [Page 8] Internet-Draft MCast Translation Framework February 2011 ------- // \\ ----------- / \ // \\ / +------+ \ R4===MR IPv4 |mXlate| IPv6 (S6/RP) | Network +------+ Network / \ / \\ // RP = Rendezvous Point \\ // ----------- S6 = v6 Multicast Source -------- MR = Multicast Router ----> ------------> ------------> R4 = v4 Receiver ICMP PIMv4-Join PIMv6-Join <=========== <=========== IPv4 Mcast IPv6 Mcast Figure 7 This could happen when the multicast source and majority of the network have been migrated to IPv6. However, there are few IPv4 islands left which still want to receive multicast packets from the IPv6 source. 5.5. Scenario 5: mXlate is the DR of the IPv6 source In this scenario, the access network is IPv4-only network, the multicast source has been migrated to IPv6. The mXlate and the IPv6 source is on the same network, and the mXlate is also the Designated Router. ------- // \\ / \ | / +------+ | R4 = v4 Receiver R4===MR IPv4 |mXlate|----| MR = Multicast Router | Network +------+ |- S6 S6 = v6 Multicast Source \ / | \\ // -------- ----> ------------> MLD PIMv4-Join <============= IPv4 Mcast Figure 8 Lee & Qin Expires August 25, 2011 [Page 9] Internet-Draft MCast Translation Framework February 2011 This could happen if there are still IPv4-only networks left after the source has been migrated to IPv6. The mXlate behaves as DR connected to the IPv4 source and translate the multicast packets to IPv4 formatted which are then distributed in the IPv4 multicast network. 5.6. Scenario 6: mXlate is the IGMP Querier In this scenario, the entire network is IPv6. The multicast source is also IPv6-only. However, there are some legacy IPv4 receivers which want to receive packets from the IPv6-only source. ------- // \\ ----------- / \ // \\ +------+ +----+ \ R4==|mXlate|========| MR | IPv6 (S6/RP) +------+ IPv6 +----+ Network / \ Network / \\ // \\ // ----------- RP = Rendezvous Point -------- S6 = Multicast Source ----> ------------> ------------> MR = Multicast Router MLD ICMP PIMv4-Join R4 = v4 Receiver <====== <============================ IPv6 Mcast IPv4 Mcast Figure 9 This scenario could happen after the operator has completely migrated to IPv6, but few IPv4-only receivers have yet to retire or to migrate to IPv6. These IPv4-only receivers can be connected by mXlate which locates in the IGMP Querier. 6. Translation Components 6.1. Address Translation It is important for the mXlate to specify how an IPxX address is translated to an IPvY for the operations of mXlate. Scenario 1, 2, and 3 require to translate an IPv4 multicast group to an IPv6 multicast group. This can be achieved by following the mechanisms defined in [I-D.boucadair-behave-64-multicast-address-format]. The mXlate creates a stateless mapping table of IPv4->IPv6 group addresses indicated by the IPv4-embedded IPv6 addresses and Lee & Qin Expires August 25, 2011 [Page 10] Internet-Draft MCast Translation Framework February 2011 translates the IPv4 multicast packets into multicast packets based on the mapping table. Scenario 4, 5, and 6 require to translate an IPv6 multicast group to an IPv4 multicast group. Since the IPv6 multicast group has much large address space than IPv4 multicast group, it is impossible to achieve an one-to-one mapping. In fact, this creates a tough challenge to define an algorithm to translate an IPv6 multicast group to an IPv4 multicast group. In practice, the mXlate can create a stateful mapping table of IPv6->IPv4 group addresses. These entries are probably defined by the operators and each operator may have different definitions of the table. As such, inter-domain multicast translation will require coordination. 6.2. Multicast Translator (mXlate) mXlate plays two roles in the multicast translation. It is responsible for translating the multicast control protocol from IPvX to IPvY (e.g., IGMP<->MLD) and translating the actual multicast data packets from IPvX to IPvY. Depending on the deployment models (ASM vs. SSM), there are different considerations. 6.2.1. mXlate in ASM 6.2.1.1. mXlate Location In ASM deployment model, mXlate must be the "root" of the multicast distribution tree of the translated multicast group. This is important because the mXlate maintains the mapping information to translate the IPvX to IPvY. 6.2.1.2. Source Registration Source Registration happens when the source starts sourcing multicast packets. The DR will send the Source Registration to the RP. In the shared tree model, the RP will start replicate the packets to the interfaces where received the PIM-Join of the multicast group. Consider Scenario 1 and 4 where mXlate is not the DR of the multicast source. If a receiver sends a PIMvX-Join of the translated multicast group to the RPvX, the RPvX will not know where the source is, so it will wait until it receives the Source Registration coming from mXlate. Unfortunately the mXlate will never send the Source Registration because it is not the "DR" and the DRvY never knows that there is a RP of another address family waiting for the Source Registration. In order to solve this problem, there are two ways: Lee & Qin Expires August 25, 2011 [Page 11] Internet-Draft MCast Translation Framework February 2011 1. Configure the mXlate to become the RP of all the translated multicast addresses. 2. Configure the mXlate to join all the known IPvY-translated IPvY multicast groups to the RPvY and IPvY Sources send Source Registration to the RPvX regardless whether any receiver has asked to join the groups. This problem is unique to Scenario 1 and 4. The reminding scenarios will not suffer from the same problem because the mXlate is the DR of the source in Scenario 2 and 5, and the mXlate is a simple MLD<->ICMP translator in Scenario 3 and 6. 6.2.2. mXlate in SSM 6.2.2.1. mXlate Location In SSM deployment model, mXlate must be the source of the SSM group of the translated multicast address group. When the mXlate receives the PIMvX-Join, it would translate this to a PIMvY-Join to upstream multicast router. The IPvX Source to IPvY Source mapping information is stateful and stored in the mXlate. 6.2.3. Interchanging ASM and SSM mXlate is the bridging point of two multicast trees. It is possible that the mXlate runs SSM in the IPvX domain and ASM in the IPvY domain or vice versa. For example: In Scenario 1, if the IPv6 network runs SSM and the IPv4 runs ASM, this could potentially solve the problem of Source Registration described in Section 6.2.1.2. 7. IANA Considerations This document has no requirement to IANA. 8. Security Considerations TBD 9. Acknowledgements TBD 10. References Lee & Qin Expires August 25, 2011 [Page 12] Internet-Draft MCast Translation Framework February 2011 10.1. Normative References [I-D.ietf-behave-v6v4-framework] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", draft-ietf-behave-v6v4-framework-10 (work in progress), August 2010. 10.2. Informative References [I-D.boucadair-behave-64-multicast-address-format] Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and M. Xu, "IPv4-Embedded IPv6 Multicast Address Format", draft-boucadair-behave-64-multicast-address-format-01 (work in progress), February 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Yiu L. Lee Comcast Email: yiu_lee@cable.comcast.com URI: http://www.comcast.com Jacni Qin ZTE Email: jacniq@gmail.com URI: http://www.zte.com.cn Lee & Qin Expires August 25, 2011 [Page 13]