--- 1/draft-ietf-mboned-v4v6-mcast-ps-00.txt 2012-11-08 10:15:09.217342910 +0100 +++ 2/draft-ietf-mboned-v4v6-mcast-ps-01.txt 2012-11-08 10:15:09.253342456 +0100 @@ -1,26 +1,26 @@ MBONED Working Group C. Jacquenet Internet-Draft M. Boucadair Intended status: Informational France Telecom Orange -Expires: November 12, 2012 Y. Lee +Expires: May 13, 2013 Y. Lee Comcast J. Qin Cisco Systems T. Tsou Huawei Technologies (USA) Q. Sun China Telecom - May 11, 2012 + November 09, 2012 IPv4-IPv6 Multicast: Problem Statement and Use Cases - draft-ietf-mboned-v4v6-mcast-ps-00 + draft-ietf-mboned-v4v6-mcast-ps-01 Abstract This document discusses issues and requirements raised by IPv4-IPv6 multicast interconnection and co-existence scenarios. It also discusses various multicast use cases which may occur during IPv6 transitioning. Requirements Language @@ -36,73 +36,70 @@ 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 November 12, 2012. + This Internet-Draft will expire on May 13, 2013. Copyright Notice Copyright (c) 2012 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. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 - 1.3. Organization of the Document . . . . . . . . . . . . . . . 6 - 2. Scope and Service Requirements . . . . . . . . . . . . . . . . 6 - 2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 2.2. Service Requirements . . . . . . . . . . . . . . . . . . . 7 - 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3. Organization of the Document . . . . . . . . . . . . . . . 5 + 2. Scope and Service Requirements . . . . . . . . . . . . . . . . 5 + 2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.2. Service Requirements . . . . . . . . . . . . . . . . . . . 6 + 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. IPv4 Receiver and Source Connected to an IPv6-Only - Network . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.2. IPv6 Receiver Connected to an IPv4 Source Through an - IPv4 Multicast-Disabled Access Network and an IPv6 - Multicast Network . . . . . . . . . . . . . . . . . . . . 10 - 3.3. IPv6 Receiver and Source Connected to an IPv4-Only - Network . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 3.4. IPv6 Receiver and IPv4 Source . . . . . . . . . . . . . . 14 - 3.5. IPv4 Receiver and IPv6 Source . . . . . . . . . . . . . . 16 - 3.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 18 - 4.1. Group and Source Discovery Considerations . . . . . . . . 18 - 4.2. Subscription . . . . . . . . . . . . . . . . . . . . . . . 19 - 4.3. Multicast Tree Computation . . . . . . . . . . . . . . . . 19 - 4.4. Multicast Adaptation Functions (AF) . . . . . . . . . . . 20 - 4.4.1. AF For Control Flows . . . . . . . . . . . . . . . . . 20 - 4.4.2. AF For Data Flows . . . . . . . . . . . . . . . . . . 21 - 4.4.3. Address Mapping . . . . . . . . . . . . . . . . . . . 21 - 4.5. Combination of ASM and SSM Modes . . . . . . . . . . . . . 22 - 5. What Is Expected From The IETF . . . . . . . . . . . . . . . . 22 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 24 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 + Network . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.2. IPv6 Receiver and Source Connected to an IPv4-Only + Network . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.3. IPv6 Receiver and IPv4 Source . . . . . . . . . . . . . . 11 + 3.4. IPv4 Receiver and IPv6 Source . . . . . . . . . . . . . . 13 + 3.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 15 + 4.1. Group and Source Discovery Considerations . . . . . . . . 15 + 4.2. Subscription . . . . . . . . . . . . . . . . . . . . . . . 16 + 4.3. Multicast Tree Computation . . . . . . . . . . . . . . . . 16 + 4.4. Multicast Adaptation Functions (AF) . . . . . . . . . . . 17 + 4.4.1. AF For Control Flows . . . . . . . . . . . . . . . . . 17 + 4.4.2. AF For Data Flows . . . . . . . . . . . . . . . . . . 18 + 4.4.3. Address Mapping . . . . . . . . . . . . . . . . . . . 18 + 4.5. Combination of ASM and SSM Modes . . . . . . . . . . . . . 19 + 5. What Is Expected From The IETF . . . . . . . . . . . . . . . . 19 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction Global IPv4 address depletion inevitably challenges service providers who must guarantee IPv4 service continuity during the forthcoming transition period. In particular, access to IPv4 contents that are multicast to IPv4 receivers becomes an issue when the forwarding of multicast data assumes the use of global IPv4 addresses. The rarefaction of global IPv4 addresses may indeed affect the @@ -223,27 +220,27 @@ 2.1. Scope Intra-domain only: The delivery of multicast services such as live TV broadcasting often relies upon walled garden designs that restrict the scope to the domain where such services can be subscribed. As a consequence, considerations about inter-domain multicast are out of the scope of this document. Multicast-enabled networks only: This document assumes that the - network is IP multicast-enabled. That is, whatever the IP address - family of the content, the latter will be multicast along - distribution trees that should be terminated as close to the + network is *IP multicast-enabled*. That is, whatever the IP + address family of the content, this content will be multicast + along distribution trees that should be terminated as close to the receivers as possible for the sake of bandwidth optimization. In - other words, considerations about forwarding multicast traffic - over unicast-only (access) networks is out of the scope of this - document. + other words, *considerations about forwarding multicast traffic + over unicast-only (access) networks are out of the scope of this + document.* Multicast to the receivers, not from the receivers: This document only covers the case where multicast traffic is forwarded by the service provider network to the receivers. This document does not cover the case where the receivers send multicast traffic to the network. 2.2. Service Requirements The delivery of multicast contents during the forthcoming transition @@ -394,129 +391,30 @@ at the boundary between the IPv6 network and the receiver network performs the reverse operation to deliver IPv4 packets. Given the current state-of-the-art where multicast content is likely to remain IPv4-formatted while receiver devices such as Set Top Boxes will also remain IPv4-only for quite some time, this scenario is prioritized by some service providers, including those that are deploying or will deploy DS-Lite CGN capabilities for the sake of IPv4 service continuity. -3.2. IPv6 Receiver Connected to an IPv4 Source Through an IPv4 - Multicast-Disabled Access Network and an IPv6 Multicast Network - - One major provider faces a complex transitional situation where the - receiver is IPv6, the CPE router is dual stack unmanaged router, and - the IPv4 access network is not multicast-enabled. This IPv4 unicast- - only access network connects to the IPv4 source via an IPv6 - multicast-enabled metro network. - - This scenario is denoted as the 6-4-6-4 scenario. - - Because the provider does not manage the CPE router, encapsulation of - IPv6 packets across the IPv4 network is unlikely. Figure 3 shows the - signalling path for this scenario. - - +------+ +-----+ +----+ +------+ - | Host | MLD | DS | IGMP | | PIM | DS | - | Rcvr |------| AF0 |------| PE | . . .| AF1 | - | | IPv6 |(CPE)| IPv4 | | IPv4 | (BG) | - +------+ +-----+ +----+ +------+ - / - -----------------<---------- - / MLD over IPv6 - +------+ +----+ +------+ - | MR | PIM | | PIM | DS | - | |------| MR | . . . | AF2 | - | (DR) | IPv6 | | IPv6 | (BG) | - +------+ +----+ +------+ - / - -----------------<------- - / PIM over IPv4 - +------+ +------+ - | MR | PIM | MR | - | | . . . . | | - | (BG) | IPv4 | (DR) | - +------+ +------+ - - -------------------------------------> - - Rcvr: Multicast receiver - DS : Dual Stack - AF : Adaptation Function - MR : Multicast Router - DR : Designated Router - CPE : Customer Premises Equipment (Dual Stack router) - PE : Provider Edge router - BG : Border Gateway - - Figure 3: Signalling Path For the 6-4-6-4 Scenario. - - The major challenge of this scenario is how to ensure that signalling - packets from the CPE that embeds AF0 reach the adaptation function - AF1 located at the boundary between the IPv4 multicast-disabled - access network and the IPv6 multicast network. - - Figure 4 shows the path taken by multicast traffic flowing from the - source to the receiver. Again, AF2 can either encapsulate or - translate the headers of the incoming packets. AF1 performs the - reverse action, and forwards unencapsulated IPv4 packets towards AF0. - AF0 then needs to forward the IPv6 multicast packets that are - equivalent to the incoming IPv4 multicast packets towards the IPv6 - receiver. - - +------+ +-----+ +----+ +------+ - | Host | | DS | | | | DS | - | Rcvr |------| AF0 |------| PE | . . .| AF1 | - | | IPv6 |(CPE)| IPv4 | | IPv4 | (BG) | - +------+ +-----+ +----+ +------+ - / - ----------------->---------- - / IPv6 - +------+ +----+ +------+ - | MR | | | | DS | - | |------| MR | . . . | AF2 | - | (DR) | IPv6 | | IPv6 | (BG) | - +------+ +----+ +------+ - / - ----------------->------- - / IPv4 - +------+ +------+ +-----+ - | MR | | MR | | | - | | . . . . | |------| Src | - | (BG) | IPv4 | (DR) | IPv4 | | - +------+ +------+ +-----+ - - <------------------------------------- - - Rcvr: Multicast receiver - Src : Multicast source - DS : Dual Stack - AF : Adaptation function - MR : Multicast Router - DR : Designated Router - CPE : Customer Premises Equipment (Dual Stack router) - PE : Provider Edge router - BG : Border Gateway - - Figure 4: Multicast Traffic Forwarding Path For the 6-4-6-4 Scenario. - -3.3. IPv6 Receiver and Source Connected to an IPv4-Only Network +3.2. IPv6 Receiver and Source Connected to an IPv4-Only Network We refer to this scenario as 6-4-6. Since providers who own the multicast content may not be ready for IPv6 migration beofre some time, the content is likely to remain IPv4-formatted. As a consequence, this 6-4-6 scenario is of lower priority than the 4-6-4 scenario. The signalling path for the 6-4-6 scenario is illustrated in Figure - 5. + 3. +------+ +-----+ +------+ +------+ | Host | MLD | DS | | MR | PIM | MR | | Rcvr |------| AF1 | | | . . . . | | | | IPv6 | | | (BG) | IPv6 | (DR) | +------+ +-----+ +------+ +------+ / \ IGMP / IPv4 PIM \ IPv6 / \ +------+ +----+ +------+ @@ -527,23 +425,23 @@ -------------------------------------> Rcvr: Multicast receiver DS : Dual Stack AF : Adaptation Function MR : Multicast Router DR : Designated Router BG : Border Gateway - Figure 5: Signalling Path For the 6-4-6 Scenario. + Figure 3: Signalling Path For the 6-4-6 Scenario. - Figure 6 shows the path taken by multicast traffic flowing from the + Figure 4 shows the path taken by multicast traffic flowing from the IPv6 source to the IPv6 receiver. +------+ +-----+ +------+ +------+ | Host | | DS | | MR | | MR | | Rcvr |------| AF1 | | | . . . | | | | IPv6 | | | (BG) | IPv6 | (DR) | +------+ +-----+ +------+ +------+ / \ \ / IPv4 \ IPv6 \ IPv6 / \ \ @@ -556,33 +454,33 @@ <------------------------------------- Rcvr: Multicast receiver DS : Dual Stack AF : Adaptation Function MR : Multicast Router DR : Designated Router BG : Border Gateway Src : Multicast source - Figure 6: Multicast Traffic Forwarding Path For the 6-4-6 Scenario. + Figure 4: Multicast Traffic Forwarding Path For the 6-4-6 Scenario. -3.4. IPv6 Receiver and IPv4 Source +3.3. IPv6 Receiver and IPv4 Source We refer to this scenario as 6-4. An example of such use case is the context of some mobile networks, where terminal devices are only provisioned with an IPv6 prefix. Accessing IPv4-formatted multicast content from an IPv6-only receiver requires additional functions to be enabled. This scenario is privileged by mobile operators who deploy NAT64 - capabilities in their network. It is illustrated in Figures 7 - (signalling path) and 8 (forwarding of multicast traffic). Only one + capabilities in their network. It is illustrated in Figures 5 + (signalling path) and 6 (forwarding of multicast traffic). Only one adaptation function instance is needed, and it will be located at the IPv4/IPv6 multicast domain boundary. +------+ +------+ +------+ | Host | | MR | PIM | MR | | Rcvr | | | . . . . | | | | | (BG) | IPv4 | (DR) | +------+ +------+ +------+ \ \ MLD \ IPv6 PIM \ IPv4 @@ -595,21 +493,21 @@ -------------------------------------> Rcvr: Multicast receiver DS : Dual Stack AF : Adaptation Function MR : Multicast Router DR : Designated Router BG : Border Gateway - Figure 7: Signalling Path For the 6-4 Scenario. + Figure 5: Signalling Path For the 6-4 Scenario. +------+ +------+ +------+ | Host | | MR | | MR | | Rcvr | | | . . . . | | | | | (BG) | IPv4 | (DR) | +------+ +------+ +------+ \ \ \ \ IPv6 \ IPv4 \ IPv4 \ \ \ +------+ +----+ +------+ +-----+ @@ -621,33 +519,31 @@ <------------------------------------- Rcvr: Multicast receiver DS : Dual Stack AF : Adaptation Function MR : Multicast Router DR : Designated Router BG : Border Gateway Src : Multicast source - Figure 8: Multicast Traffic Forwarding Path For the 6-4 Scenario. + Figure 6: Multicast Traffic Forwarding Path For the 6-4 Scenario. -3.5. IPv4 Receiver and IPv6 Source +3.4. IPv4 Receiver and IPv6 Source We refer to this scenario as 4-6. Yet, multicast sources are likely to remain IPv4-enabled in a first stage; therefore, the content is likely to remain IPv4-formatted. As a consequence, this scenario is - unlikely to occur during the first years of the transition period, - and has been assigned a lower priority compared to the use cases - depicted in Sections 3.1, 3.2 and 3.4. + unlikely to occur during the first years of the transition period. - The signalling path for this scenario is shown in Figure 9. The - multicast traffic forwarding path is shown in Figure 10. There are + The signalling path for this scenario is shown in Figure 7. The + multicast traffic forwarding path is shown in Figure 8. There are similarities with the 6-4 scenario but address mapping across IP version boundaries is more challenging. +------+ +------+ +------+ | Host | | MR | PIM | MR | | Rcvr | | | . . . . | | | | | (BG) | IPv6 | (DR) | +------+ +------+ +------+ \ \ IGMP \ IPv4 PIM \ IPv6 @@ -660,21 +556,21 @@ -------------------------------------> Rcvr: Multicast receiver DS : Dual Stack AF : Adaptation Function MR : Multicast Router DR : Designated Router BG : Border Gateway - Figure 9: Signalling Path For the 4-6 Scenario. + Figure 7: Signalling Path For the 4-6 Scenario. +------+ +------+ +------+ | Host | | MR | | MR | | Rcvr | | | . . . . | | | | | (BG) | IPv6 | (DR) | +------+ +------+ +------+ \ \ \ \ IPv4 \ IPv6 \ IPv6 \ \ \ +------+ +----+ +------+ +-----+ @@ -686,26 +582,26 @@ <------------------------------------- Rcvr: Multicast receiver DS : Dual Stack AF : Adaptation Function MR : Multicast Router DR : Designated Router BG : Border Gateway Src : Multicast source - Figure 10: Multicast Traffic Forwarding Path For the 4-6 Scenario. + Figure 8: Multicast Traffic Forwarding Path For the 4-6 Scenario. -3.6. Summary +3.5. Summary To summarize, the use cases of highest priority are those involving - IPv4 sources, i.e., the 4-6-4, 6-4-6-4 and 6-4 scenarios. + IPv4 sources, i.e., the 4-6-4 and 6-4 scenarios. 4. Design Considerations 4.1. Group and Source Discovery Considerations Multicast applications that embed address information in the payload may require Application Level Gateway (ALG) during the transition period. An ALG is application-specific by definition, and may therefore be unnecessary depending on the nature of the multicast service. @@ -890,22 +786,20 @@ o Specify the inter-working function as described in Sections 4.4.1 and 4.4.2. In particular: * Specify the algorithms used by various inter-working functions, covering both encapsulation and translation approaches * Specify the multicast IPv4-embedded address format * Document a 6-4 multicast architecture - * Document a 6-4-6-4 multicast architecture - * Document a 4-6-4 multicast architecture o Document a Management Information Base (MIB) to be used for the management of IWF functions o Encourage the publication of various Applicability Statement documents to reflect IWF operational experience in different contexts 6. IANA Considerations @@ -962,23 +855,24 @@ Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. 9.2. Informative References [I-D.ietf-mboned-64-multicast-address-format] Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and - M. Xu, "IPv4-Embedded IPv6 Multicast Address Format", - draft-ietf-mboned-64-multicast-address-format-01 (work in - progress), February 2012. + M. Xu, "IPv6 Multicast Address With Embedded IPv4 + Multicast Address", + draft-ietf-mboned-64-multicast-address-format-04 (work in + progress), August 2012. Authors' Addresses Christian Jacquenet France Telecom Orange 4 rue du Clos Courtel Cesson-Sevigne 35512 France Phone: +33 2 99 12 43 82 @@ -995,21 +889,21 @@ Yiu Lee Comcast US Email: Yiu_Lee@Cable.Comcast.com Jacni Qin Cisco Systems People's Republic of China - Email: jacniq@gmail.com + Email: jacni@jacni.com Tina Tsou Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050 USA Phone: +1 408 330 4424 Email: tena@huawei.com