| Internet Engineering Task Force | H. Asaeda |
| Internet-Draft | Keio University |
| Intended status: Informational | M. Eubanks |
| Expires: August 30, 2012 | AmericaFree.TV |
| T. Tsou | |
| Huawei Technologies (USA) | |
| S. Venaas | |
| Cisco Systems | |
| February 29, 2012 |
Multicast Transition Overview
draft-eubanks-mboned-transition-overview-03
IPTV providers must serve content to their customers during the period of transition from IPv4 to IPv6. During this period, the content provider may support only one version of IP while the customer supports only the other. Likewise, the network between the provider and its customer may include segments supporting only one version of IP or another.
This document provides an overview of the multicast transition problem. It also provides an overview of the solution space. The solution space is characterized by an adaptation function (AF) that provides an interface between IPv4 and IPv6 multicast domains.
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 30, 2012.
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.
IPTV providers must serve content to their customers during the period of transition from IPv4 to IPv6. During this period, the content provider may support only one version of IP while the customer supports only the other. Likewise, the network between the provider and its customer may include segments supporting only one version of IP or another.
This document provides an overview of the multicast transition problem. It also provides an overview of the solution space. The solution space is characterized by an adaptation function (AF) that provides an interface between IPv4 and IPv6 multicast domains.
Section 2 describes the problem space in detail. This section describes an environment that includes a content provider, a customer, and an intervening network. Any component of that environment may support only one version of IP or the other. At points where IPv4-only devices lie on one side and IPv6-only devices on the other, an adaptation function is required.
Section 3 proposes a framework for the solution. Section 4 defines formal requirements for any proposed solution.
Historically, IPTV providers have served IPv4 content to consumers over IPv4 multicast networks. CPE has supported IPv4 only. As the Internet transitions to IPv6, IPv6-capable equipment will be deployed by content providers and consumers, as well as the networks that connect them to one another. So long as all of the newly deployed gear supports both IPv4 and IPv6, the transition to IPv6 may not require new IETF protocol specifications. However, if some of the newly deployed gear supports IPv6 only, incompatibilities will be introduced.
An incompatibility occurs at a device lying along the path between the source and the receiver when the next device on the path on one side of it supports a different version of IP from the next device on the path on the other side of it (i.e., one device supports IPv4 only and the other supports IPv6 only). For the purposes of this document, we will call these points of incompatibility "IP version transition points". The communication path between provider and consumer (which includes both endpoints) can include zero or more IP version transition points.
IP version transition points may be introduced at any point along the path. These IP version transition points may reside in the subscriber premises, at the CPE, in the intervening network etc. In addition, the Set Top Box (STB) and Electronic Program Guides (EPG) may have different IP versions.
In order to maintain multicast connectivity, one or more adaptation functions (AF) are required. These adaption funtions may be deployed at each IP version transition point. However, if for instance there are IPv4-only and IPv6-only routers on the path, separated by dual-stack routers (routers supporting both IPv4 and IPv6), the adaption function may be placed anywhere along that dual-stack path. The AF operates in both the forwarding and control planes. Because it provides an interface between the IPv4 and IPv6 domain, it must be both IPv4-capable and IPv6-capable.
In most cases, the adaptation function will mediate between IPv4 and IPv6 on both the control and forwarding planes. However, in scenarios where the path between provider and consumer contains multiple IP version transition points, adaptation function instances may tunnel traffic between one another.
The AF operates on both the forwarding and control planes. On the forwarding plane, the AF inserts itself into the forwarding path translating multicast packets from one IP version to the other. On the control plane, the AF receives routing and signaling messages of one protocol and sends out routing and signaling messages of another protocol. If the device acts as a router this may be part of the usual message processing and generation, but it may also be done as translation of messages, without taking part in the protocol operations. [draft to come] provides a discussion of AF operation and deployment.
The AF accepts packets from one IP version, removes the IP header, and replaces it with an IP Header of the other version. A significant portion of that task is address translation. Ideally the address translation strategy used by an AF should be algorithmic, stateless and reversible. This should be simple when addresses from one IP version can simply be embedded into another (IPv4 into IPv6), but this may not be possible in the opposite direction. That the translation is reversible means that there is a stateless algorithm for translating back into the original address.
[RFC6052] provides an algorithm for translating unicast addresses between IPv4 and IPv6. Likewise [I-D.mboned-64-mcast-addr-fmt] provides an algorithm for multicast address conversion between IPv4 and IPv6. Note that using this algorithm, different translators could choose different IPv6 prefixes for embedding the IPv4 addresses. But the format allows for stateless translation back to the original IPv4 addresses.
Other issues associated with IP version translation may arise (e.g., fragmentation and checksums). The scope of these issues is wider than that of multicast transition. As such issues are identified, they will be resolved in conjunction with appropriate IETF working groups.
On the control plane, the AF mediates between:
The IGMP-to-MLD translation may be configured to use only IGMPv2 features. It is defined in [draft to come].
The PIM-to-PIM mediation operates between PIM protocol operations of one IP version with operations of the other version. This mediation is defined in [draft to come].
Multicast requires a mechanism through which a receiver can associate a multicast stream with a multicast group address. The Session Announcement Protocol (SAP, [RFC2974]) is such a mechanism which is still in use in academic environments and by some content providers. AF translation rules for this protocol are also described in [draft to come]. For commercial purposes, different standards development organizations have specified protocols for transmission of electronic program guides. [ID.tsou-multrans-addr-acquisition] specifies the operation of the AF in such an environment [... in a future version of the draft which comes to a conclusion on the best way forward].
A mechanism to optimize the path to the multicast source for a combination of IPv4 and IPv6 networks is not immediately required, but is a topic for future work.
From the description above, we can distill the following requirements:
Ron Bonica inspired the writing of this memo and shaped its content. Michael McBride provided useful comments on an intermediate version of this document.
This memo includes no request to IANA.
To come.