Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Tina Tsou (Ting ZOU) , Tom Taylor , Cathy Zhou , Hui Ji
Last updated 2012-03-12
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-tsou-softwire-6rd-multicast-01
Internet Engineering Task Force                                  T. Tsou
Internet-Draft                                 Huawei Technologies (USA)
Intended status: Informational                                 T. Taylor
Expires: September 12, 2012                                      C. Zhou
                                                     Huawei Technologies
                                                                   H. Ji
                                                           China Telecom
                                                          March 11, 2012

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

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 September 12, 2012.

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

Tsou, et al.           Expires September 12, 2012               [Page 1]
Internet-Draft           IPv6 Multicast With 6rd              March 2012

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

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

Tsou, et al.           Expires September 12, 2012               [Page 2]
Internet-Draft           IPv6 Multicast With 6rd              March 2012

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 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 (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 that wishes to receive a multicast
   stream acquires the corresponding IPv6 address pair by means out of
   scope of this document.  See [ID.tsou-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.

Tsou, et al.           Expires September 12, 2012               [Page 3]
Internet-Draft           IPv6 Multicast With 6rd              March 2012

  +----+        +----+ 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:

   o  mapping between the IPv6 address pair presented by the IPv6 Host
      and IPv4 address pair designating the same multicast stream in the
      provider's IPv4 network;

   o  translation from MLD [RFC3810] presented by the IPv6 Host to IGMP
      [RFC3376] forwarded toward the provider's IPv4 network;

   o  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:

   o  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;

   o  interworking PIM between the IPv4 and IPv6 networks;

   o  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

Tsou, et al.           Expires September 12, 2012               [Page 4]
Internet-Draft           IPv6 Multicast With 6rd              March 2012

   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

Tsou, et al.           Expires September 12, 2012               [Page 5]
Internet-Draft           IPv6 Multicast With 6rd              March 2012

   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

   [ID.mboned-64-mcast-addr-fmt]
              Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and
              M. Xu, "IPv4-Embedded IPv6 Multicast Address Format (Work
              in progress)", February 2012.

   [ID.perreault-igmp-mld-translation]
              Perrault, S. and T. Tsou, "Internet Group Management
              Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based
              Multicast Translation ("IGMP/MLD Translation") (Work in
              progress)", February 2012.

   [ID.taylor-pim-v4v6-translation]
              Taylor, T. and C. Zhou, "A Translator For Protocol
              Independent Multicast (PIM) Interworking Between IPv4 and
              IPv6 (Work in progress)", March 2012.

Tsou, et al.           Expires September 12, 2012               [Page 6]
Internet-Draft           IPv6 Multicast With 6rd              March 2012

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

   [RFC3973]  Adams, A., Nicholas, J., and W. Siadak, "Protocol
              Independent Multicast - Dense Mode (PIM-DM): Protocol
              Specification (Revised)", RFC 3973, January 2005.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC5969]  Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
              Infrastructures (6rd) -- Protocol Specification",
              RFC 5969, August 2010.

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              October 2010.

6.2.  Informative References

   [ID.tsou-mboned-multrans-addr-acq]
              Tsou, T., Clauberg, A., Boucadair, M., Venaas, S., and Q.
              Sun, "Address Acquisition For Multicast Content When
              Source and Receiver Support Differing IP Versions (Work in
              progress)", March 2012.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC5569]  Despres, R., "IPv6 Rapid Deployment on IPv4
              Infrastructures (6rd)", RFC 5569, January 2010.

Tsou, et al.           Expires September 12, 2012               [Page 7]
Internet-Draft           IPv6 Multicast With 6rd              March 2012

Authors' Addresses

   Tina Tsou
   Huawei Technologies (USA)
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Phone: +1 408 330 4424
   Email: Tina.Tsou.Zouting@huawei.com
   URI:   http://tinatsou.weebly.com/contact.html

   Tom Taylor
   Huawei Technologies
   Ottawa, Ontario
   Canada

   Phone:
   Email: tom.taylor.stds@gmail.com

   Cathy Zhou
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Phone:
   Email: cathy.zhou@huawei.com

   Hui Ji
   China Telecom
   NO19.North Street
   Beijing, Chaoyangmen,Dongcheng District
   P.R. China

   Phone:
   Email: jihui@chinatelecom.com.cn

Tsou, et al.           Expires September 12, 2012               [Page 8]