--- 1/draft-ietf-mboned-v4v6-mcast-ps-01.txt 2013-04-11 14:14:04.360813695 +0100 +++ 2/draft-ietf-mboned-v4v6-mcast-ps-02.txt 2013-04-11 14:14:04.400814679 +0100 @@ -1,105 +1,98 @@ MBONED Working Group C. Jacquenet Internet-Draft M. Boucadair Intended status: Informational France Telecom Orange -Expires: May 13, 2013 Y. Lee +Expires: September 14, 2013 Y. Lee Comcast J. Qin Cisco Systems T. Tsou Huawei Technologies (USA) Q. Sun China Telecom - November 09, 2012 + March 13, 2013 IPv4-IPv6 Multicast: Problem Statement and Use Cases - draft-ietf-mboned-v4v6-mcast-ps-01 + draft-ietf-mboned-v4v6-mcast-ps-02 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 - - 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]. - -Status of this Memo +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 May 13, 2013. + This Internet-Draft will expire on September 14, 2013. Copyright Notice - Copyright (c) 2012 IETF Trust and the persons identified as the + + Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3. Organization of the Document . . . . . . . . . . . . . . . 5 - 2. Scope and Service Requirements . . . . . . . . . . . . . . . . 5 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.2. Organization of the Document . . . . . . . . . . . . . . 4 + 2. Scope and Service Requirements . . . . . . . . . . . . . . . 5 2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2.2. Service Requirements . . . . . . . . . . . . . . . . . . . 6 - 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.2. Service Requirements . . . . . . . . . . . . . . . . . . 5 + 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. IPv4 Receiver and Source Connected to an IPv6-Only - Network . . . . . . . . . . . . . . . . . . . . . . . . . 7 + Network . . . . . . . . . . . . . . . . . . . . . . . . . 6 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 + Network . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.3. IPv6 Receiver and IPv4 Source . . . . . . . . . . . . . . 10 + 3.4. IPv4 Receiver and IPv6 Source . . . . . . . . . . . . . . 11 + 3.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 13 + 4.1. Group and Source Discovery Considerations . . . . . . . . 13 + 4.2. Subscription . . . . . . . . . . . . . . . . . . . . . . 13 + 4.3. Multicast Tree Computation . . . . . . . . . . . . . . . 14 + 4.4. Multicast Adaptation Functions (AF) . . . . . . . . . . . 14 + 4.4.1. AF For Control Flows . . . . . . . . . . . . . . . . 14 + 4.4.2. AF For Data Flows . . . . . . . . . . . . . . . . . . 16 + 4.4.3. Address Mapping . . . . . . . . . . . . . . . . . . . 16 + 4.5. Combination of ASM and SSM Modes . . . . . . . . . . . . 16 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 + 8.2. Informative References . . . . . . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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 @@ -152,151 +145,133 @@ therefore suffer from IPv4 address depletion. o The progressive introduction of IPv6 as the only perennial solution to global IPv4 address depletion does not necessarily assume that multicast-based IPv4 services will be migrated accordingly. Access to IPv4 multicast contents when no global IPv4 address can be assigned to a customer raises several issues: (1) The completion of the IGMP-based multicast group subscription procedure, (2) The computation of the IPv4 multicast distribution tree, and (3) The IPv4-inferred addressing scheme to be used in a - networking environment which will progressively become IPv6- - enabled. + networking environment which will progressively become + IPv6-enabled. This document does not make any assumption on the techniques used for the delivery of multicast traffic (e.g., native IP multicast with or without traffic isolation features, etc.) This document elaborates on the context and discusses multicast- related issues and requirements. -1.1. Goals - - The objective of this document is to clarify the problem space. In - particular, this document elaborates on the following issues: - - o What are the hurdles encountered for the delivery of multicast- - based service offerings when both IPv4 and IPv6 co-exist? - - o What standardization effort is needed: are there any missing - function and protocol extension? - - o Does the work on multicast transition have to cover both - encapsulation and translation schemes, considering the requirement - of multicast network performance among others? - -1.2. Terminology +1.1. Terminology This document uses the following terms: o Multicast Source: Source of contents that are multicast to receivers. A video streaming server is an example of such source. o Multicast Receiver: Receiver, in short. A Set Top Box (STB) is an example of such receiver. o Multicast Delivery Network: Network in short, covers the realm from Designated Routers that are directly connected to sources to IGMP/MLD (Internet Group Management Protocol/Multicast Listener Discovery) Querier devices that process IGMP/MLD signalling traffic exchanged with receivers. -1.3. Organization of the Document +1.2. Organization of the Document This document is organized as follows: o Section 2 details basic requirements that should be addressed by providers involved in the delivery of multicast-based services during the transition period, o Section 3 discusses several use cases that reflect issues raised by the forthcoming transition period, - o Section 4 details design considerations, - - o Section 5 summarizes the standardization effort that should be - tackled by the IETF. + o Section 4 details design considerations. 2. Scope and Service Requirements 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, this content 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 + other words, considerations about forwarding multicast traffic over unicast-only (access) networks are out of the scope of this - document.* + 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 period needs to address the following requirements. Note that some of these requirements are not necessarily specific to the IPv4-to- IPv6 transition context, but rather apply to a wide range of multicast-based services whatever the environmental constraints, but the forthcoming transition period further stresses these requirements (see Section 4.4.1 for more details). - o Optimize bandwidth. Contents SHOULD NOT be multicast twice (i.e., + o Optimize bandwidth. Contents should not be multicast twice (i.e., using both versions of IP) to optimize bandwidth usage. Injecting multicast content using both IPv4 and IPv6 raises some dimensioning issues that should be carefully evaluated by service providers during network planning operations. For instance, if only few IPv6-enabled receivers are in use, it can be more convenient to convey multicast traffic over IPv4 rather than doubling the consumed resources for few users. IPv4/IPv6 co- - existence solutions SHOULD be designed to optimize network + existence solutions should be designed to optimize network resource utilization. o Zap rapidly. The time it takes to switch from one content to - another MUST be as short as possible. For example, zapping times + another must be as short as possible. For example, zapping times between two TV channels should be in the magnitude of a few seconds at most, whatever the conditions to access the multicast network. A procedure called "IGMP fast-leave" is sometimes used to minimize this issue so that the corresponding multicast stream is stopped as soon as the IGMP Leave message is received by the Querier. In current deployments, IGMP fast-leave often assumes the activation of the IGMP Proxy function in DSLAMs. The complexity of such design is aggravated within a context where IPv4 multicast control messages are encapsulated in IPv6. o Preserve the integrity of contents. Some contract agreements may prevent a service provider from altering the content owned by the content provider, because of copyright, confidentiality and SLA - assurance reasons. Multicast streams SHOULD be delivered without + assurance reasons. Multicast streams should be delivered without altering their content. o Preserve service quality. Crossing a CGN or performing multicast packet encapsulation may lead to fragmentation or extra delays and may therefore impact the perceived quality of service. Such - degradation MUST be avoided. + degradation must be avoided. o Optimize IPv4-IPv6 inter-working design. In some operational networks, a source-based stateful NAT function is sometimes used for load balancing purposes, for example. Because of the operational issues raised by such a stateful design, the - deployment of stateless IPv4-IPv6 interworking functions SHOULD be + deployment of stateless IPv4-IPv6 interworking functions should be privileged. 3. Use Cases During the IPv4-to-IPv6 transition period, there might be a mix of multicast receivers, sources, and networks running in different address families. However, service providers must guarantee the delivery of multicast services to IPv4 receivers and, presumably, IPv6 receivers. Because of the inevitable combination of different IP version-related environments (sources, receivers and networks), @@ -608,23 +583,23 @@ Such ALG (Application Level Gateway) may also be required to help an IPv6 receiver select the appropriate multicast group address when only the IPv4 address is advertised (e.g., when the SDP (Session Description Protocol) protocol is used to advertise some contents); otherwise, access to IPv4 multicast content from an IPv6 receiver may be compromised. ALGs may be located upstream in the network. As a consequence, these ALGs do not know in advance whether the receiver is dual-stack or - IPv6-only. In order to avoid the use of an ALG in the path, an IPv4- - only source can advertise both an IPv4 multicast group address and - the corresponding IPv4-embedded IPv6 multicast group address + IPv6-only. In order to avoid the use of an ALG in the path, an + IPv4-only source can advertise both an IPv4 multicast group address + and the corresponding IPv4-embedded IPv6 multicast group address [I-D.ietf-mboned-64-multicast-address-format]. However, a dual-stack receiver may prefer to use the IPv6 address to receive the multicast content. The selection of the IPv6 multicast address would then require multicast flows to cross an IPv4-IPv6 interworking function. The receiver should therefore be able to unambiguously distinguish an IPv4-embedded IPv6 multicast address from a native IPv6 multicast address. @@ -637,134 +612,135 @@ In case the underlying access network is IPv6, the information conveyed in IGMP messages should be relayed by corresponding MLD messages. 4.3. Multicast Tree Computation Grafting to an IPv4 multicast distribution tree through an IPv6 multicast domain suggests that IPv4 multicast traffic will have to be conveyed along an "IPv6-equivalent" multicast distribution tree. That is, part of the multicast distribution tree along which IPv4 - multicast traffic will be forwarded SHOULD be computed and maintained + multicast traffic will be forwarded should be computed and maintained by means of the PIMv6 machinery, so that the distribution tree can be terminated as close to the IPv4 receivers as possible for the sake of - the multicast forwarding efficiency. This assumes a close - interaction between the PIM designs enforced in both IPv4 and IPv6 - multicast domains, by means of specific Inter-Working Functions that - are further discussed in Section 4.4. + the multicast forwarding efficiency. + + This assumes a close interaction between the PIM designs enforced in + both IPv4 and IPv6 multicast domains, by means of specific Inter- + Working Functions that are further discussed in Section 4.4. Such interaction may be complicated by different combinations: the IPv4 multicast domain is SSM-enabled (with no RP (Rendezvous Point) routers), while the IPv6 multicast domain may support both ASM (Any Source Multicast) and SSM (Source Specific Multicast) [RFC3569] modes. 4.4. Multicast Adaptation Functions (AF) IPv4-IPv6 multicast interworking functions are required for both translation (one address family to another) and traversal (one address family over another) contexts. Given the multiple versions of Group Membership management protocols, issues may be raised when, for example, IGMPv2 is running in the IPv4 multicast domain that is connected to the IPv6 multicast domain by means of an IWF, while MLDv2 is running in the IPv6 multicast domain. - To solve these problems, the design of the IWF function SHOULD adhere + To solve these problems, the design of the IWF function should adhere to the IP version-independent, protocol interaction approach documented in Section 8 of [RFC3810] and Section 7 of [RFC3376]. Note that, for traversal cases, to improve the efficiency of the multicast service delivery, traffic will be multicast along distribution trees that should be terminated as close to the receivers as possible for bandwidth optimization purposes. As a reminder, the traversal of unicast-only (access) networks is not considered in this document. 4.4.1. AF For Control Flows The IWF to process multicast signalling flows (such as IGMP or MLD Report messages) should be independent of the IP version and consist mainly of an IPv4-IPv6 adaptation element and an IP address translation element. The message format adaptation must follow what is specified in [RFC3810] or [RFC4601], and the device that embeds - the IWF device must be multicast-enabled, i.e., support IGMP, MLD - and/or PIM, depending on the context (address family-wise) and the + the IWF device must be multicast-enabled, i.e., support IGMP, MLD and + /or PIM, depending on the context (address family-wise) and the design (e.g., this device could be a PIM DR in addition to a MLD Querier). - The IWF can then be operated in the following modes: IGMP-MLD, PIMv4- - PIMv6, MLD-PIMv4 and IGMP-PIMv6. In particular, Source-Specific - Multicast (SSM) must be supported (i.e., IGMPv3/MLDv2 signalling - traffic as well as the ability to directly send PIM (S, G) Join - messages towards the source). + The IWF can then be operated in the following modes: IGMP-MLD, + PIMv4-PIMv6, MLD-PIMv4 and IGMP-PIMv6. In particular, Source- + Specific Multicast (SSM) must be supported (i.e., IGMPv3/MLDv2 + signalling traffic as well as the ability to directly send PIM (S, G) + Join messages towards the source). The following sub-sections describe some interworking functions which may be solicited, depending on the environment. 4.4.1.1. IGMP-MLD Interworking The 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, and vice versa. For example, when an IGMP Report message is received to subscribe to a given multicast group (which may be associated to a source address - if SSM mode is used), the IGMP-MLD Interworking Function MUST send an + if SSM mode is used), the IGMP-MLD Interworking Function must send an MLD Report message to subscribe to the corresponding IPv6 multicast group. 4.4.1.2. IPv4-IPv6 PIM Interworking [RFC4601] allows the computation of PIM-based IPv4 or IPv6 distribution trees; PIM is IP version agnostic. There is no specific IPv6 PIM machinery that would work differently than an IPv4 PIM machinery. The new features needed for the IPv4-IPv6 PIM Interworking Function consist in dynamically triggering the PIM message of Address Family 1 upon receipt of the equivalent PIM message of Address Family 2. - The address mapping MUST be performed similarly to that of the IGMP- + The address mapping must be performed similarly to that of the IGMP- MLD Interworking Function. 4.4.1.3. MLD-IPv4 PIM Interworking This IWF function is required when the MLD Querier is connected to an IPv4 PIM domain. - The address mapping MUST be performed similarly to that of the IGMP- + The address mapping must be performed similarly to that of the IGMP- MLD Interworking Function. 4.4.1.4. IGMP-IPv6 PIM Interworking - The address mapping MUST be performed similarly to that of the IGMP- + The address mapping must be performed similarly to that of the IGMP- MLD Interworking Function. 4.4.2. AF For Data Flows The IWF to be used for multicast data flows is operated at the boundary between IPv4 and IPv6 multicast networks. Either encapsulation/de-capsulation or translation modes can be enforced, depending on the design. Note that translation operations must follow the algorithm specified in [RFC6145]. 4.4.3. Address Mapping The address mapping mechanisms to be used in either a stateful or stateless fashion need to be specified for the translation from one address family to the other. The address formats have been defined in - [I-D.ietf-mboned-64-multicast-address-format] and [RFC6052] for IPv4- - embedded IPv6 multicast and unicast addresses. Mapping operations - are performed in a stateless manner by the algorithms specified in - the aforementioned documents. + [I-D.ietf-mboned-64-multicast-address-format] and [RFC6052] for + IPv4-embedded IPv6 multicast and unicast addresses. Mapping + operations are performed in a stateless manner by the algorithms + specified in the aforementioned documents. In this context, the IPv6 prefixes required for embedding IPv4 addresses can be assigned to devices that support IWF features by various means (e.g., static or dynamic configuration, out-of-band mechanisms, etc.). If stateful approaches are used, it is recommended to carefully investigate the need to synchronize mapping states between multiple boxes, and the coordination of the IWF and source/group discovery elements is also required, at the cost of extra complexity. @@ -772,107 +748,80 @@ 4.5. Combination of ASM and SSM Modes The ASM (Any Source Multicast) mode could be used to optimize the forwarding of IPv4 multicast traffic sent by different sources into the IPv6 multicast domain by selecting RP routers that could be located at the border between the IPv6 and the IPv4 multicast domains. This design may optimize the multicast forwarding efficiency in the IPv6 domain when access to several IPv4 multicast sources needs to be granted. -5. What Is Expected From The IETF - - This document highlights the following IETF standardization needs: - - 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 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 +5. IANA Considerations This document makes no request to IANA. Note to RFC Editor: this section may be removed on publication as an RFC. -7. Security Considerations +6. Security Considerations Access to contents in a multicast-enabled environment raises different security issues that have been already documented. This draft does not introduce any specific security issue. -8. Acknowledgments - - Special thanks to T. Taylor for providing the figures and some of the - text that illustrate the use cases depicted in Section 3. Thanks - also to H. Asaeda, M. Eubanks, N. Leymann and S. Venaas for their - valuable comments. +7. Acknowledgments -9. References + Special thanks to T. Taylor for providing the figures and some of + the text that illustrate the use cases depicted in Section 3. Thanks + also to H. Asaeda, M. Blanchet, M. Eubanks, N. Leymann, S. + Perrault and S. Venaas for their valuable comments and support. -9.1. Normative References +8. References - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. +8.1. Normative References - [RFC2236] Fenner, W., "Internet Group Management Protocol, Version + [RFC2236] Fenner, W.C., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003. [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 - Listener Discovery (MLD)-Based Multicast Forwarding - ("IGMP/MLD Proxying")", RFC 4605, August 2006. - - [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. - Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, - October 2010. + Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP + /MLD Proxying")", RFC 4605, August 2006. [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. -9.2. Informative References +8.2. Informative References [I-D.ietf-mboned-64-multicast-address-format] Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and M. Xu, "IPv6 Multicast Address With Embedded IPv4 - Multicast Address", - draft-ietf-mboned-64-multicast-address-format-04 (work in - progress), August 2012. + Multicast Address", draft-ietf-mboned-64-multicast- + address-format-04 (work in progress), August 2012. + + [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. + Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, + October 2010. Authors' Addresses Christian Jacquenet France Telecom Orange 4 rue du Clos Courtel Cesson-Sevigne 35512 France Phone: +33 2 99 12 43 82