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

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 July 9, 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.

Table of Contents

1.  Introduction
    1.1.  Requirements Language
2.  Description of the Solution
    2.1.  Assumed Architecture
    2.2.  Steps In the Proposed Solution
3.  Acknowledgements
4.  IANA Considerations
5.  Security Considerations
6.  References
    6.1.  Normative References
    6.2.  Informative References
§  Authors' Addresses

1.  Introduction

6rd ([RFC5569] (Despres, R., “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd),” January 2010.), [RFC5969] (Townsley, W. and O. Troan, “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification,” August 2010.)) 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 use the native multicast capabilities of the IPv4 network to acquire and forward multicast traffic from 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 (BR).

1.1.  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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

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.

2.1.  Assumed Architecture

This document assumes an architecture similar to that of 6rd [RFC5569] (Despres, R., “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd),” January 2010.), [RFC5969] (Townsley, W. and O. Troan, “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification,” August 2010.), with additional capabilities for the 6rd CE and the 6rd Border Relay. In addition, it postulates a multicast source discovery and translation function, which MAY be collocated with the BR. See Figure 1 (IPv6 Multicast Across an IPv4 Domain Using a Translator Function).

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

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

• requesting a mapping between IPv6 <Source, Group> pairs presented by the IPv6 Host and IPv4 <Source, Group> pairs valid for the provider's IPv4 network;
• interworking between MLD [RFC3810] (Vida, R. and L. Costa, “Multicast Listener Discovery Version 2 (MLDv2) for IPv6,” June 2004.) presented by the IPv6 Host and IGMP [RFC3376] (Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, “Internet Group Management Protocol, Version 3,” October 2002.) forwarded toward the provider's IPv4 network;
• translating incoming IPv4 multicast streams to IPv6 before forwarding them to the IPv6 Host.

The Provider IP Edge has the normal function of interworking between IGMP [RFC3376] (Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, “Internet Group Management Protocol, Version 3,” October 2002.) and PIM [RFC4601] (Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, “Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised),” August 2006.) multicast signalling.

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

• requesting a mapping between IPv4 <Source, Group> pairs received in PIM messages from the IPv4 network and IPv6 <Source, Group> pairs valid for the neighbouring IPv6 network;
• translating PIM messaging between the IPv4 and IPv6 networks;
• using the reverse mapping from IPv6 to IPv4 <Source, Group> pairs to translate and forward multicast media streams coming from the IPv6 network.

The Translator function has the following responsibilities:

• creating a mapping between IPv6 and IPv4 <Source, Group> address pairs for multicast streams, beginning with IPv6 address pairs provided in requests from the 6rd CE and assigning the corresponding IPv4 unicast and multicast addresses from pool of addresses with which it is configured.
• responding to requests for mappings in either direction.

2.2.  Steps In the Proposed Solution

1. Initial discovery and Join request

The IPv6 Host discovers the <Source, Group> address pair of a multicast stream the user wants to receive. The discovery is by means outside the scope of this specification (e.g., via the web). The IPv6 Host sends an MLDv2 [RFC3810] (Vida, R. and L. Costa, “Multicast Listener Discovery Version 2 (MLDv2) for IPv6,” June 2004.) request to the 6rd CE to acquire the stream.

+----+        +----+
|IPv6|  LAN   | 6rd|
|Host|--------| CE |
+----+        +----+
      ------->
      MLD/IPv6

2. <Source, Group> Address Mapping At 6rd CE

The 6rd CE checks its cache of mappings to see if it already has a mapping between the IPv6 <Source, Group> address pair received in the MLD request and a corresponding pair of IPv4 addresses. Failing to find a mapping, it sends a request for the required mapping to the Translator. The Translator in turn checks whether it has already created the mapping. If not, it assigns unicast and multicast IPv4 addresses from its pool and records the mapping for further use. In either case it returns the requested mapping to the 6rd CE, which caches it. [Editor's Note: The transaction is carried out over a protocol to be specified in a later version of this document.]

              +----+ Access +--------+           +------------+
              | 6rd|  Link  |Provider|    IPv4   | Translator |
              | CE |--------|IP Edge |- network -|  function  |
              +----+        +--------+           +------------+
                   ----------------------------->
                      TBD protocol / IPv4

3. Propagation Of the Join Request Into the IPv4 Network

The 6rd CE interworks between the MLDv2 request it received and an IGMPv3 [RFC3376] (Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, “Internet Group Management Protocol, Version 3,” October 2002.) request which it forwards to the Provider IP Edge. It uses the address pair mapping it received from the Translator as part of this interworking.

The Provider IP Edge acts on the IGMP request by forwarding a PIM [RFC3973] (Adams, A., Nicholas, J., and W. Siadak, “Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised),” January 2005.) or [RFC4601] (Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, “Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised),” August 2006.) request into the IPv4 network, indicating the IPv4 <Source, Group> address pair it was given and ensuring that it is on the multicast tree for the stream concerned. [Editor's note: details later.]

Eventually the PIM request finds its way to the 6rd Border Relay. [Editor's note: details needed here to make sure this happens. Alternatively, we could recast this as using any Border Router and not a 6rd Relay in particular, but we would end up with possibly different paths for the multicast packets and the returning unicast RTCP feedback. Maybe that doesn't matter.]

              +----+ Access +--------+           +------+
              | 6rd|  Link  |Provider|    IPv4   |Border|    IPv6
              | CE |--------|IP Edge |- network -|Relay |-  network
              +----+        +--------+           +------+
                    -------->        ------------>
	                  IGMP/IPv4          PIM/IPv4

4. Remapping the <Source, Group> Address Pair At the 6rd BR

The 6rd BR needs to map from the IPv4 <Source, Group> address pair it received back to the corresponding IPv6 address pair before propagating the PIM request into the IPv6 network. It sends a request to the Translator to provide that mapping. The Translator already has this mapping, as a result of the original 6rd CE request, and returns it to the 6rd BR. [Editor's note: protocol again to be specified later. It can probably be the same as the one used by the 6rd CE, since both nodes are operator-managed even if the 6rd CE is more likely to have been hacked. Have to work out the security considerations.]

                                                 +------+
                                                 |Border|
                                                 |Relay |
                                                 +------+
                                                    | TBD protocol
                                                    |    /IPv4
                                               +----V-------+
                                               | Translator |
                                               |  function  |
                                               +------------+

5. Propagation Of the PIM Request Into the IPv6 Network

The 6rd BR propagates translates the PIM request from IPv4 to IPv6 using the mapping it received. It propagates the request into the IPv6 network to complete the construction of the path for the requested multicast stream. [Editor's note: probably don't have to go this far if there are already other listeners attached to the IPv4 network. Have to insert corresponding text in previous steps. Also, if PIM can return errors, the 6rd BR should notify the Translator so it can mark the IPv6 address pair as bad (so it doesn't get remapped) while releasing the assigned IPv4 addresses.]

                                                 +------+
                                                 |Border|    IPv6
                                                 |Relay |-  network
                                                 +------+
                                                         ----------->
                                                           PIM/IPv6

6. Transport of Multicast Media and Unicast RTCP Feedback

If the 6rd BR receives a multicast packet from the IPv6 network, it translates the source and group addresses to IPv4 using the mapping it has retained from Step 4. It then forwards it to the next hop in the multicast tree for that stream.

                                                 +------+
                                        IPv4     |Border|    IPv6
                                       network  -|Relay |-  network
                                                 +------+
                                   <----------        <----------
                                     Media packet         Media packet
                                    <S',G'>/IPv4      <S,G>/IPv6

When the 6rd CE receives a multicast packet from the IPv4 network, it translates the packet to IPv4 using the mapping which it has retained from Step 2.

When the IPv6 Host sends unicast RTCP [RFC3550] (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) 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.

Finally, if the IPv6 Host emits multicast packets destined for an any-source multicast group, the 6rd CE and 6rd BR translate the packets from IPv6 to IPv4 and back again using the mappings they have retained.

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