IPv6 Multicast Using Native IPv4 Capabilities in a 6rd Deployment
draft-tsou-softwire-6rd-multicast-02

Abstract

This document describes how IPv6 multicast can be extended across an IPv4 network to an IPv6 host, using the native multicast capabilities of the IPv4 network.

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 March 06, 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
• 1.1. Terminology
• 2. Description of the Solution
• 2.1. Assumed Architecture
• 2.2. Components of the Proposed Solution
• 2.2.1. Address Mapping
• 2.2.2. Multicast Routing
• 2.2.3. Translation From MLD To IGMP
• 2.2.4. Interworking Between PIM With IPv4 and PIM with IPv6 At the 6rd BR
• 2.2.5. Transport of Multicast Data Packets and Unicast RTCP Feedback
• 3. Acknowledgements
• 4. IANA Considerations
• 5. Security Considerations
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Authors' Addresses

1. Introduction

6rd ([RFC5569], [RFC5969]) provides a means to connect IPv6 hosts to the IPv6 Internet across an IPv4 provider network. Unicast traffic is carried through IPv6-in-IPv4 tunnels. It is possible to carry multicast traffic from the IPv6 network through the IPv4 network in the same way, but if multiple customers wish access to the same multicast channels, the failure to use the native multicast capabilities of the IPv4 network wastes resources in that network.

This document describes a solution using the native multicast capabilities of the IPv4 network to acquire and forward multicast traffic from the IPv6 Internet to an IPv6 host attached to the IPv4 network. Typically this solution will operate in combination with 6rd for unicast traffic. However, no IPv6-in-IPv4 tunneling is required for signalling, only the ability to interwork between IPv4 and IPv6 at the 6rd Customer Equipment (6rd CE) and the 6rd Border Relay (6rd BR).

1.1. Terminology

The term "address pair" is used to denote the combination of unicast source address and multicast group address corresponding to a given multicast stream at a given point along the path between the source and receiver.

2. Description of the Solution

A number of problems have to be solved to allow an IPv6 host attached to an IPv4 network to request and receive a multicast stream originating in a neighbouring IPv6 network and passing through the IPv4 network using the native multicast facilities of that network. These problems are described in detail in the course of presenting proposed solutions to them.

It is assumed that the IPv6 host wishing to receive a multicast stream acquires the corresponding IPv6 address pair by means out of scope of this document. See [ID.mboned-multrans-addr-acq].

2.1. Assumed Architecture

This document assumes an architecture similar to that of 6rd [RFC5569], [RFC5969], with additional capabilities for the 6rd Customer Edge (CE) and the 6rd Border Relay (6rd BR). See Figure 1.

+----+        +----+ Access +--------+             +------+ 
|IPv6|  LAN   | 6rd|  Link  |Provider|    IPv4     |Border|     IPv6 
|Host|--------| CE |--------|IP Edge |-- network --|Relay |--- network
+----+        +----+        +--------+             +------+    		     
			

Figure 1: IPv6 Multicast Across an IPv4 Domain Using a Translator Function

In addition to its 6rd responsibilities, the 6rd CE is responsible for:

• mapping between the IPv6 address pair presented by the IPv6 Host and an IPv4 address pair designating the same multicast stream in the provider's IPv4 network;
• accepting MLD [RFC3810] on the IPv6 Host side and emitting IGMP [RFC3376] toward the provider's IPv4 network;
• using the reverse mapping from IPv6 to IPv4 address pairs to translate incoming IPv4 multicast streams to IPv6 before forwarding them to the IPv6 Host. Alternatively, decapsulating IPv6 multicast data packets from incoming IPv4 packets.

The Provider IP Edge has the normal function of interworking between IGMP [RFC3376] and PIM [RFC4601] multicast signalling.

The Border Relay has the usual 6rd responsibilities. In addition, it is responsible for:

• mapping between IPv4 address pairs received in PIM messages from the IPv4 network and IPv6 address pairs denoting the same multicast streams in the neighbouring IPv6 network;
• translating addresses in PIM between the IPv4 and IPv6 networks;
• using the reverse mapping from IPv6 to IPv4 address pairs to translate and forward multicast data packets coming from the IPv6 network. Alternatively, using the reverse mapping to generate encapsulating IPv4 headers for the IPv6 packets before forwarding them as multicast IPv4 data.

2.2. Components of the Proposed Solution

2.2.1. Address Mapping

Both the 6rd CE and the 6rd BR need to map between IPv6 and IPv4 addresses, in both directions. The IPv6 address pairs do not have to be the same at the two nodes, so long as the IPv6 address pair used by the host designates the same multicast stream as the IPv6 address pair generated at the 6rd BR or received from the source IPv6 network.

Because the source network uses IPv6, mapping between the addresses used in that network and the IPv4 addresses used in the provider network is in general a difficult problem. The most general solution is to configure static mappings between the IPv6 and corresponding IPv4 address pairs at the 6rd BR. Mapping at the 6rd CE can use IPv4-embedded IPv6 addresses as defined in [RFC6052] for the unicast source addresses, and [ID.mboned-64-mcast-addr-fmt] for the multicast group addresses. This assumes that the IPv6 host has been provided with such addresses in the first place. It also assumes that the IPv4 network provider can configure suitable prefixes at the 6rd CE for the purpose of such mapping.

With restrictions on the IPv6 addresses used for multicast source and group addresses in the IPv6 network, it may be possible to use algorithmic instead of static mapping at the 6rd BR. This generally requires coordination between the IPv4 and IPv6 network operators.

2.2.2. Multicast Routing

For each IPv4 address to which an IPv6 source address is mapped, the routing tables that PIM uses must result in a path that passes through a multicast-enabled 6rd BR. At the routing level, this means that the 6rd BR must advertise reachability to the mapped IPv4 source addresses it knows about into the IPv4 domain. Its distance metrics to those addresses must reflect the routing information it receives on the IPv6 side for their IPv6 counterparts.

2.2.3. Translation From MLD To IGMP

See [ID.perreault-igmp-mld-translation].

2.2.4. Interworking Between PIM With IPv4 and PIM with IPv6 At the 6rd BR

See [ID.taylor-pim-v4v6-translation].

2.2.5. Transport of Multicast Data Packets and Unicast RTCP Feedback

The documents cited in the previous two sections describe the process of header translation for multicast data packets. The address mapping aspect of that translation was discussed in Section 2.2.1. If the 6rd BR and 6rd CE are configured to use encapsulation/decapsulation of multicast data packets instead, the encapsulating IPv4 header uses the IPv4 address pair mapped from the original IPv6 address pair as source and destination. However, this requires that the IPv6 host uses the same IPv6 addresses as the source IPv6 network for each multicast stream it receives. That may force the 6rd CE to use static rather than algorithmic mapping for address pairs for its MLD/IGMP translation.

When the IPv6 Host sends unicast RTCP [RFC3550] feedback toward the source, the packets are treated by the 6rd CE and 6rd BR like any other unicast packets. That is, they are encapsulated at the 6rd CE, transported across the IPv4 network as IPv6-in-IPv4, and decapsulated at the 6rd BR before forwarding into the IPv6 network.

3. Acknowledgements

Awaiting comments.

4. IANA Considerations

This memo currently includes no request to IANA.

5. Security Considerations

To come.

6. References

6.1. Normative References

6.2. Informative References

Authors' Addresses