Skip to main content

Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Translation ("IGMP/MLD Translation")
draft-perreault-mboned-igmp-mld-translation-00

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 Simon Perreault , Tina Tsou (Ting ZOU)
Last updated 2012-02-24
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-perreault-mboned-igmp-mld-translation-00
Network Working Group                                       S. Perreault
Internet-Draft                                                  Viagenie
Intended status: Standards Track                                 T. Tsou
Expires: August 27, 2012                       Huawei Technologies (USA)
                                                       February 24, 2012

Internet Group Management Protocol (IGMP) / Multicast Listener Discovery
       (MLD)-Based Multicast Translation ("IGMP/MLD Translation")
             draft-perreault-mboned-igmp-mld-translation-00

Abstract

   This document describes translation between IPv4 and IPv6 of
   multicast flows by an IGMP/MLD proxy.  This allows single-stack nodes
   to participate in multicast groups from a different address family.
   Both sending and receiving is supported by this translation
   mechanism.  Both any-source and source-specific multicast (ASM and
   SSM) are supported as well.

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 August 27, 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

Perreault & Tsou         Expires August 27, 2012                [Page 1]
Internet-Draft            IGMP/MLD Translation             February 2012

   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
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     3.1.  Mixed IPv4/IPv6 Networks . . . . . . . . . . . . . . . . .  5
     3.2.  Role in the Multrans Framework . . . . . . . . . . . . . .  5
   4.  Signalling Translation . . . . . . . . . . . . . . . . . . . .  5
     4.1.  IP Headers . . . . . . . . . . . . . . . . . . . . . . . .  5
       4.1.1.  Addresses  . . . . . . . . . . . . . . . . . . . . . .  6
       4.1.2.  Router-Alert Option  . . . . . . . . . . . . . . . . .  6
     4.2.  IGMP/MLD Translation . . . . . . . . . . . . . . . . . . .  7
       4.2.1.  Message Type Equivalences  . . . . . . . . . . . . . .  7
       4.2.2.  The "Translated" Bit . . . . . . . . . . . . . . . . .  7
       4.2.3.  Maximum Response {Delay,Time}  . . . . . . . . . . . . 11
       4.2.4.  Multicast Group Address  . . . . . . . . . . . . . . . 12
       4.2.5.  Source Addresses . . . . . . . . . . . . . . . . . . . 13
       4.2.6.  Additional and Auxiliary Data  . . . . . . . . . . . . 13
     4.3.  MTU Considerations . . . . . . . . . . . . . . . . . . . . 13
   5.  Data Transfer  . . . . . . . . . . . . . . . . . . . . . . . . 13
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15

Perreault & Tsou         Expires August 27, 2012                [Page 2]
Internet-Draft            IGMP/MLD Translation             February 2012

1.  Introduction

   This document specifies IGMP/MLD translation, a mechanism for IPv4-
   IPv6 transition and coexistence.  It enables single-stack (i.e.,
   IPv4-only or IPv6-only) hosts to participate, either as listeners,
   sources, or both, in multicast groups belonging to a different
   address family.

   This translation mechanism is designed to be part of an IGMP/MLD
   proxy [RFC4605].  It could be located at the customer network edge
   (e.g., in customer-premises equipment (CPE)) or at the provider
   network edge (e.g., in a DSLAM for DSL networks, in a CMTS for cable
   networks, etc.), or any other node reachable by IGMP/MLD packets.
   Note that the proxy function could be virtual, feeding its output
   directly into a multicast router process (e.g., a PIM daemon) running
   on the same host as the translating proxy.

2.  Terminology

   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 [RFC2119].

   The unqualified term "proxy" refers to an IGMP/MLD proxy as defined
   in [RFC4605].

3.  Overview

   As described in [RFC4605], an IGMP/MLD proxy is located between an
   upstream network and one or more downstream networks.  Listeners are
   in the downstream networks while the rest of the multicast
   infrastructure is upstream.  It is possible to arrange multiple
   proxies in a tree topology, where one proxy's upstream network is
   another's downstream network.

   The translation function is logically situated between the proxy and
   the upstream network, as shown in Figure 1.

Perreault & Tsou         Expires August 27, 2012                [Page 3]
Internet-Draft            IGMP/MLD Translation             February 2012

                                 Upstream
                                    |
                               +----+-----+
                               |Translator|
                               +----+-----+
                                    |
                                +---+----+
                                | Proxy  |
                                +-+-+-+-++
                                  | | | |
                               Downstream(s)

              Figure 1: IGMP/MLD translator function topology

   If the translator and proxy functions are performed by the same node,
   as is expected to be the common case, the node acts as a translating
   multicast router.  If two nodes are used instead, the translator
   would be considered a "bump in the wire", acting as a link-layer
   bridge that modifies the data transiting through it.  These two
   implementation possibilities are both supported by this document.
   Focus is on the logical definition of the translator function.

   There are two reasons for locating the translator upstream of the
   proxy rather than downstream:

   1.  Translating addresses on downstream interfaces could interfere
       with Querier elections.  As described in [RFC3376] section 6.6.2
       and [RFC3810] section 7.6.2, IGMP and MLD routers elect a Querier
       amongst themselves.  The criteria for winning the election is
       based on the source address of IGMP/MLD Queries.  Having a
       translator on a downstream interface would impose a new
       constraint on the address mapping scheme: it would need to ensure
       the same election result before and after applying the mapping.
       This constraint is lifted when the translation is applied to the
       upstream interface instead.  Since a proxy acts as a client on
       its upstream interface, it does not participate in Querier
       elections.

   2.  There is only one upstream interface whereas there may be
       multiple downstream interfaces.  Applying the translation on the
       upstream interface has the advantage of having a single
       translation point, which can facilitate debugging and
       troubleshooting.

   State information is not duplicated.  Internally, the address family
   of the membership state maintained by the proxy and the address
   families of the IGMP/MLD router and client state machines will all be
   the same as that of its downstream networks.  This enables existing

Perreault & Tsou         Expires August 27, 2012                [Page 4]
Internet-Draft            IGMP/MLD Translation             February 2012

   proxy code to be reused as-is.  Furthermore, and perhaps more
   importantly, avoiding duplication of state eliminates the possibility
   of IPv4 and IPv6 state data getting out of sync.

   Conceptually, translation is applied to messages sent upstream by the
   client state machine and to messages received from upstream.  This
   document specifies how translation is carried out in terms of packet
   translation.  However, a particular implementation is at liberty to
   adopt any internal structure as long as externally observable
   behavior is identical.

3.1.  Mixed IPv4/IPv6 Networks

   In mixed networks, where there may be both IPv4 and IPv6 receivers,
   two logical proxies are used.  Each maintains membership state and
   runs state machines in the address families of the receivers it is
   proxying.  Translation is applied to only one of them.  This is
   illustrated in Figure 2.

                                  Upstream
                             +-----IPvX-----+
                             |              |
                        +----+-----+        |
                        |Translator|        |
                        +----+-----+        |
                             |              |
                       +---+--------+ +-----+------+
                       | Proxy IPvY | | Proxy IPvX |
                       +-+-+-+-+-+--+ +-+-+-+-+-+--+
                         | | | | |      | | | | |
                       Downstream(s)   Downstream(s)
                           IPvX            IPvX

                    Figure 2: Mixed IPv4/IPv6 topology

3.2.  Role in the Multrans Framework

   TODO

4.  Signalling Translation

   This section describes how to translate between IGMP and MLD.

4.1.  IP Headers

Perreault & Tsou         Expires August 27, 2012                [Page 5]
Internet-Draft            IGMP/MLD Translation             February 2012

4.1.1.  Addresses

   Destination addresses are translated as follows:

   MLDv2 and IGMPv3:  The destination address is a well-known address
      and is translated as listed in Table 1.

   MLDv1, IGMPv1, and IGMPv2:  The destination address corresponds to
      the address of the multicast group.  The multicast group address
      is mapped between IPv4 and IPv6 as described in
      [I-D.boucadair-64-multicast-address-format].

     +--------------------------------------+------------+----------+
     | Description                          | IPv4       | IPv6     |
     +--------------------------------------+------------+----------+
     | All nodes on link                    | 224.0.0.1  | ff02::1  |
     | All routers on link                  | 224.0.0.2  | ff02::2  |
     | All IGMP/MLD-capable routers on link | 224.0.0.22 | ff02::16 |
     +--------------------------------------+------------+----------+

       Table 1: IPv4/IPv6 Well-Known Multicast Address Equivalences

   Source addresses are translated as follows:

   IGMP to MLD:  The source address is set to a link-local IPv6 address
      assigned to the proxy's upstream interface.

   MLD to IGMP:  The source address is set to the IPv4 address assigned
      to the proxy's upstream interface.

   IGMP and MLD Reports having an unspecified source address (0.0.0.0 or
   ::) are handled differently.  In MLD, they are dropped ([RFC3810]
   section 5.2.13).  In IGMP, they are accepted ([RFC3376] section
   4.2.13).  This means that translating 0.0.0.0 to :: and vice-versa
   would change the router's behaviour: it would accept a message that
   should have been dropped, and vice-versa.  To eliminate this
   ambiguity, the translator MUST drop IGMP and MLD reports having an
   unspecified source address.

4.1.2.  Router-Alert Option

   IGMP messages are sent with a Router Alert IPv4 option [RFC2113]
   while MLD message are sent with a Router Alert option in a Hop-By-Hop
   IPv6 extension header [RFC2711].  The translator needs to convert
   between these two.  In particular, a Router Alert option MUST be sent
   on output if and only if it was received on input.  The value MUST be
   set to zero unconditionally because the IPv4 and IPv6 value spaces
   are not identical.

Perreault & Tsou         Expires August 27, 2012                [Page 6]
Internet-Draft            IGMP/MLD Translation             February 2012

4.2.  IGMP/MLD Translation

4.2.1.  Message Type Equivalences

   The IGMP/MLD messages to be handled by the translator belong to the
   proxy's upstream interface, on which the proxy acts as a listener.
   This means that translation will be applied to IGMP/MLD Reports and
   Leave/Done messages sent from the proxy as well as to to IGMP/MLD
   Queries received from routers.

   Upon reception of an IGMP message with a type field containing one of
   the values listed in Table 2, the translator will intercept the
   message and produce an equivalent MLDv2 message corresponding to an
   ICMPv6 message with the listed type number in the same row.  The
   translator will perform the reverse operation upon reception of an
   MLDv2 message.

              +-----------------------+--------------------+
              | IGMP type number      | ICMPv6 type number |
              +-----------------------+--------------------+
              | 17 IGMPv1/v2/v3 Query | 130 MLDv1/v2 Query |
              | 18 IGMPv1 Report      | 131 MLDv1 Report   |
              | 22 IGMPv2 Report      | 131 MLDv1 Report   |
              | 23 IGMPv2 Leave       | 132 MLDv1 Done     |
              | 34 IGMPv3 Report      | 143 MLDv2 Report   |
              +-----------------------+--------------------+

                Table 2: IGMP/MLD Message Type Equivalences

4.2.2.  The "Translated" Bit

   Experience IPv6 transition in general and translation in particular
   has shown that it is often useful, for various reasons, most often of
   an operational nature, that can not necessarily be anticipated at the
   time a specification gets written, to include a mechanism allowing
   the identification of translated traffic.

   This specification tries to anticipate that need by assigning a
   reserved bit in both IGMPv3 and MLDv2 for such a purpose.  When set
   to 1, it indicates a message that has been translated according to
   this specification at least once.  When set to 0, it indicates that
   no translation has been performed.

   A translator conforming to this specification MUST set the Translated
   bit to 1 on output.  The bit is ignored on input by default, meaning
   that a message could be translated twice or more.  This will often be
   undesirable, but is allowed by this specification.

Perreault & Tsou         Expires August 27, 2012                [Page 7]
Internet-Draft            IGMP/MLD Translation             February 2012

   In an IGMPv3 Query, bit number 64 is the Translated bit, as shown in
   Figure 3.

   In an IGMPv3 Report, bit number 32 is the Translated bit, as shown in
   Figure 4.

   In an MLDv2 Query, bit number 192 is the Translated bit, as shown in
   Figure 5.

   In an MLDv2 Report, bit number 32 is the Translated bit, as shown in
   Figure 6.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = 0x11  | Max Resp Code |           Checksum            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Group Address                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |T|Resv |S| QRV |     QQIC      |     Number of Sources (N)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Source Address [1]                      |
     +-                                                             -+
     |                       Source Address [2]                      |
     +-                              .                              -+
     .                               .                               .
     .                               .                               .
     +-                                                             -+
     |                       Source Address [N]                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 3: "Translated" bit in an IGMPv3 Query (identified by the
                                 letter T)

Perreault & Tsou         Expires August 27, 2012                [Page 8]
Internet-Draft            IGMP/MLD Translation             February 2012

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = 0x22  |    Reserved   |           Checksum            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |T|         Reserved            |  Number of Group Records (M)  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                        Group Record [1]                       .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                        Group Record [2]                       .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               .                               |
     .                               .                               .
     |                               .                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                        Group Record [M]                       .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 4: "Translated" bit in an IGMPv3 Report (identified by the
                                 letter T)

Perreault & Tsou         Expires August 27, 2012                [Page 9]
Internet-Draft            IGMP/MLD Translation             February 2012

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = 130   |      Code     |           Checksum            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Maximum Response Code      |           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     *                                                               *
     |                                                               |
     *                       Multicast Address                       *
     |                                                               |
     *                                                               *
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |T|Resv |S| QRV |     QQIC      |     Number of Sources (N)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     *                                                               *
     |                                                               |
     *                       Source Address [1]                      *
     |                                                               |
     *                                                               *
     |                                                               |
     +-                                                             -+
     |                                                               |
     *                                                               *
     |                                                               |
     *                       Source Address [2]                      *
     |                                                               |
     *                                                               *
     |                                                               |
     +-                              .                              -+
     .                               .                               .
     .                               .                               .
     +-                                                             -+
     |                                                               |
     *                                                               *
     |                                                               |
     *                       Source Address [N]                      *
     |                                                               |
     *                                                               *
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 5: "Translated" bit in an MLDv2 Query (identified by the
                                 letter T)

Perreault & Tsou         Expires August 27, 2012               [Page 10]
Internet-Draft            IGMP/MLD Translation             February 2012

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = 143   |    Reserved   |           Checksum            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |T|         Reserved            |Nr of Mcast Address Records (M)|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                  Multicast Address Record [1]                 .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                  Multicast Address Record [2]                 .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               .                               |
     .                               .                               .
     |                               .                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                  Multicast Address Record [M]                 .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 6: "Translated" bit in an MLDv2 Report (identified by the
                                 letter T)

4.2.3.  Maximum Response {Delay,Time}

   IGMPv2 and IGMPv3 queries contain a field specifying the Maximum
   Response Time (MRT), which is the maximum time allowed before sending
   a Report, expressed in units of 1/10 seconds.  Similarly, MLDv1 and
   MLDv2 queries contain a field specifying the Maximum Response Delay
   (MRD), expressed in units of milliseconds.

   IGMPv2 (resp. MLDv1) encode the MRT (resp. MRD) value directly as a
   binary integer.  IGMPv3 (resp. MLDv2) allows a floating-point
   encoding as well.

   IGMPv2 and IGMPv3 uses an 8-bit field while MLDv1 and MLDv2 use a 16-
   bit field.

Perreault & Tsou         Expires August 27, 2012               [Page 11]
Internet-Draft            IGMP/MLD Translation             February 2012

   The conversion algorithm is as follows:

   IGMPv2 to MLDv1:  MRD = 100 * MRT

      All values that can be represented in IGMPv2 can be equivalently
      represented in MLDv1 without loss of precision.

   IGMPv3 to MLDv2:  MRD = 100 * MRT

      All values that can be represented in IGMPv3 can be equivalently
      represented in MLDv2 without loss of precision.

      If MRT < 128, both MRT and MRD will be encoded as binary integers.

      If 128 <= MRT < 336, MRT will be encoded as a floating-point value
      while MRD will be encoded as a binary integer.

      If 336 <= MRT, both MRT and MRD will be encoded as floating-point
      values.

   MLDv1 to IGMPv2:  MRT = min(255, round(MRD / 100))

      The MRD is divided by 100, rounded to the nearest integer, then
      capped at 255 (the largest MRT value representable in IGMPv2).
      There is both precision and range loss.

   MLDv2 to IGMPv3:  MRT = min(31744, round(MRD / 100))

      The MRD is divided by 100, rounded to the nearest integer, then
      capped at 31744 (the largest MRT value representable in IGMPv3).
      There is both precision and range loss.

      If MRD < 12800, both MRD and MRT will be encoded as binary
      integers.

      If 12800 <= MRD < 32768, MRD will be encoded as a binary integer
      while MRT will be encoded as a floating-point value.

      If 32768 <= MRD, both MRD and MRT will be encoded as binary
      integers.

4.2.4.  Multicast Group Address

   The multicast group address is mapped between IPv4 and IPv6 as
   described in [I-D.boucadair-64-multicast-address-format].

Perreault & Tsou         Expires August 27, 2012               [Page 12]
Internet-Draft            IGMP/MLD Translation             February 2012

4.2.5.  Source Addresses

   Source addresses, if any, are mapped as follows:

   IGMP to MLD:  IPv4 source addresses are mapped as described in
      [RFC6052] section 2.2.

   MLD to IGMP:  An IPv4 address is extracted from an IPv6 source
      address as described in [RFC6052] section 2.2.  MLD messages
      containing a source address outside the IPv4-Embedded IPv6 Prefix
      are dropped unless there exists an applicable statically
      configured mapping.

4.2.6.  Additional and Auxiliary Data

   All IGMPv3 and MLDv2 messages can contain Additional Data, as defined
   in [RFC3376] sections 4.1.10 and 4.2.11 and [RFC3810] sections 5.1.12
   and 5.2.11.

   In addition, IGMPv3 and MLDv2 Reports can contain Auxiliary Data, as
   defined in [RFC3376] section 4.2.10 and [RFC3810] section 5.2.10.

   A translator MUST preserve Additional and Auxiliary Data.  This is
   accomplished by treating such data an an opaque blob and setting the
   appropriate IPv4 or ICMPv6 length fields appropriately.

4.3.  MTU Considerations

   MTU issues should be handled at the application layer, not at the IP
   layer.  That is, the translator MUST split large Report messages into
   smaller pieces that fit into an interface's MTU after translation, as
   described in [RFC3810] section 5.2.15 and [RFC3376] section 4.2.16..

5.  Data Transfer

   The IGMP/MLD translator is configured either to translate the headers
   of multicast packets or to encapsulate/decapsulate them.  This
   applies to regular multicast traffic, not to IGMP/MLD signalling.

   Translation is performed according to [RFC6145], with the address
   mapping specified in [I-D.boucadair-64-multicast-address-format].
   IPv6 packets with a source or destination address outside MPREFIX64
   are dropped unless there exists an applicable statically configured
   mapping.

   Encapsulation/decapsulation might be preferable when joining two IPvX
   islands across an IPvY network.  Interfaces on which encapsulation/

Perreault & Tsou         Expires August 27, 2012               [Page 13]
Internet-Draft            IGMP/MLD Translation             February 2012

   decapsulation takes place are configured into the translator.  When
   encapsulating, the original packet is not modified.  If it is an IPv6
   packet, it gets encapsulated in an IPv4 packet, and vice-versa.  The
   addresses of the encapsulating packet are obtained by mapping those
   of the original packet according to
   [I-D.boucadair-64-multicast-address-format].  When decapsulating, the
   original packet is obtained from the encapsulating packet's payload
   and is forwarded as-is.  Refer to [RFC2473] for details.

6.  IANA Considerations

   TODO

7.  Security Considerations

   TODO

8.  Acknowledgements

   TODO

9.  Normative References

   [I-D.boucadair-64-multicast-address-format]
              Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and
              M. Xu, "IPv4-Embedded IPv6 Multicast Address Format",
              draft-boucadair-64-multicast-address-format-00 (work in
              progress), January 2012.

   [RFC2113]  Katz, D., "IP Router Alert Option", RFC 2113,
              February 1997.

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

   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
              IPv6 Specification", RFC 2473, December 1998.

   [RFC2711]  Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
              RFC 2711, October 1999.

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

Perreault & Tsou         Expires August 27, 2012               [Page 14]
Internet-Draft            IGMP/MLD Translation             February 2012

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

   [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.

   [RFC6145]  Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
              Algorithm", RFC 6145, April 2011.

Authors' Addresses

   Simon Perreault
   Viagenie
   246 Aberdeen
   Quebec, QC  G1R 2E1
   Canada

   Phone: +1 418 656 9254
   Email: simon.perreault@viagenie.ca
   URI:   http://viagenie.ca

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

   Phone: +1 408 330 4424
   Email: tina.tsou.zouting@huawei.com

Perreault & Tsou         Expires August 27, 2012               [Page 15]