MBONED Working Group                                   M. Boucadair, Ed.
Internet-Draft                                            France Telecom
Updates: 4291 (if approved)                                       J. Qin
Intended status: Standards Track                                   Cisco                                  J. Qin
Expires: November 24, 2012 February 11, 2013                                         Cisco
                                                                  Y. Lee
                                                                 Comcast
                                                               S. Venaas
                                                           Cisco Systems
                                                                   X. Li
                                                  CERNET Center/Tsinghua
                                                              University
                                                                   M. Xu
                                                     Tsinghua University
                                                            May 23,
                                                         August 10, 2012

      IPv6 Multicast Address Format With Embedded IPv4 Multicast Address
            draft-ietf-mboned-64-multicast-address-format-02
            draft-ietf-mboned-64-multicast-address-format-03

Abstract

   This document specifies an extension to the reserves two IPv6 multicast addressing
   architecture prefixes to be used in the
   context of IPv4-IPv6 interconnection.
   In particular, this  The document defines specifies an
   algorithmic translation of an address format for IPv4-
   embedded IPv6 multicast addresses.  This address format to a
   corresponding IPv4 multicast address, and vice versa.  This
   algorithmic translation can be used
   for in both IPv4-IPv6 translation or
   encapsulation schemes.

   This document updates RFC4291.

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

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 November 24, 2012. February 11, 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 . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  IPv4-Embedded IPv6 Multicast Prefix & Address Format: ASM Mode  . . . .  5
   4.  IPv4-Embedded IPv6 Multicast Address Format: SSM Mode  . . . .  6
   5.  Textual Representation . .  5
     3.1.  Reserving Dedicated Prefixes . . . . . . . . . . . . . . .  5
     3.2.  IPv4-Embedded IPv6 Multicast Address . . .  7
   6.  Multicast PREFIX64 . . . . . . . .  6
     3.3.  Address Translation Algorithm  . . . . . . . . . . . . . .  7
   7.  Source IPv4 Address in the IPv6 Realm
     3.4.  Textual Representation . . . . . . . . . . . .  8
   8.  Address Translation Algorithm . . . . . .  7
     3.5.  Source IPv4 Address in the IPv6 Realm  . . . . . . . . . .  8
   9.  7
   4.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   10.  7
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   11.  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   12.  8
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   13.  8
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     13.1.  8
     8.1.  Normative References . . . . . . . . . . . . . . . . . . 10
     13.2. .  8
     8.2.  Informative References . . . . . . . . . . . . . . . . . 10 .  9
   Appendix A.  Design Choices  Motivations . . . . . . . . . . . . . . . . . . . 11 . . 10
     A.1.  Why an Address Format is Needed for Multicast
           IPv4-IPv6 Interconnection? . . . . . . . . . . . . . . . 11 . 10
     A.2.  Why Identifying an IPv4-Embedded IPv6 Multicast
           Address is Required? . . . . . . . . . . . . . . . . . . 11 . 10
     A.3.  Location of the IPv4 Address . . . . . . . . . . . . . . 12
     A.4.   Location of the M-bit . . . . . . . . . . . . . . . . . . 12
     A.5.   Encapsulation vs. Translation . . . . . . . . . . . . . . 14 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 11

1.  Introduction

   Various solutions (e.g., [I-D.ietf-softwire-mesh-multicast],
   [I-D.ietf-softwire-dslite-multicast]) have been proposed to allow
   access to IPv4 multicast content from hosts attached to IPv6-enabled
   domains.  Even if these solutions have distinct applicability scopes
   (translation vs. encapsulation) and target different use cases, they
   all make use of specific IPv6 multicast addresses to embed an IPv4
   multicast address.  Particularly, the IPv4-embedded IPv6 multicast
   address is used as a destination IPv6 address of multicast flows
   received from an IPv4-enabled domain and injected by the IPv4-IPv6
   Interconnection Function into an IPv6-enabled domain.  It is also
   used to build an IPv6 multicast state (*, G6) or (S6, G6)
   corresponding to their (*, G4) or (S4, G4) IPv4 counter parts by the
   IPv4-IPv6 Interconnection Function.  [I-D.ietf-mboned-v4v6-mcast-ps]
   provides more discussion about issues related to IPv4/IPv6 multicast.

   This document specifies an extension to the IPv6 multicast addressing
   architecture reserves two prefixes to be used in the context of IPv4-IPv6 interconnection.
   In particular, this document defines an address format for to synthesize IPv4-
   embedded IPv6 multicast addresses. address.  This address format can be used
   for IPv4-IPv6 document also defines how
   IPv4-embedded IPv6 multicast addresses are constructed.  Both IPv4-
   IPv6 translation or encapsulation schemes.

   This document updates [RFC4291].  A new M-bit is defined; if set to
   "1", it indicates an IPv4 multicast address is embedded in the low-
   order 32 bits schemes can make use of the IPv6 multicast address. these
   prefixes.

   Appendix A.1 enumerates the arguments in favor of defining an address format while reserving dedicated
   prefixes Appendix A.2 discusses why identifying an IPv4-embedded IPv6
   multicast address is needed.

   This specification can be used in conjunction with other extensions
   such as building unicast prefix-based multicast IPv6 address
   [RFC3306] or embedding the rendezvous point [RFC3956].

   This  These
   techniques are important tools to simplify IPv6 multicast
   deployments.  Indeed, unicast prefix-based IPv6 addressing is used in
   many current IPv6 multicast deployments, and has also been defined
   for IPv4, and is seen as a very useful technique.  Also embedded-RP
   is used in existing deployments.

   This document is a companion document to [RFC6052] which focuses
   exclusively on IPv4-embedded IPv6 unicast addresses.

   Details about design choices are documented in Appendix A.

2.  Terminology

   This document makes use of the following terms:

   o  IPv4-embedded IPv6 multicast address: denotes a multicast IPv6
      address which includes in 32 bits an IPv4 address.  Two types of
      IPv6 addresses are defined that carry an IPv4 address in the low-
      order 32 bits of the address.  The format to build such addresses
      is defined in Section 3 for Any Source Multicast (ASM) mode and
      Section 4 for Source Specific Multicast (SSM) mode.

   o  Multicast Prefix64 (or MPREFIX64 for short) refers to an IPv6
      multicast prefix to be used to construct IPv4-embedded IPv6
      multicast addresses.  This prefix is used to build an IPv4-
      embedded IPv6 multicast address as defined in Section 8. 3.3.
      Section 8 3.3 specifies also how to extract an IPv4 address from an
      IPv4-embedded IPv6 multicast address.

   o  ASM_MPREFIX64: denotes a multicast Prefix64 used in ASM Any Source
      Multicast (ASM) mode.  It
      follows the format described in Section 3.

   o  SSM_MPREFIX64: denotes a multicast Prefix64 used in SSM Source
      Specific Multicast (SSM) mode.  It
      follows the format described in Section 4.

   o  IPv4-IPv6 Interconnection Function: refers to a function which is
      enabled in a node interconnecting an IPv4-enabled domain with an
      IPv6-enabled one.  It can be located in various places of the
      multicast network.  Particularly, in terms of multicast control
      messages, it can be an IGMP/MLD Interworking Function or an IPv4-
      IPv6 PIM Interworking Function.  An IPv4-IPv6 Interconnection
      Function is configured with one or two MPREFIX64s.

3.  IPv4-Embedded IPv6 Multicast Prefix & Address Format: ASM Mode

   To meet the requirements listed in Appendix A.4, the IPv6 multicast
   address format defined in [RFC4291] is modified

3.1.  Reserving Dedicated Prefixes

   The following constraints should be met when reserving dedicated
   prefix(es) to enclose an IPv4 be used for IPv4/IPv6 multicast address.  Figure 1 shows the modified address format when
   ASM mode is used.

    |   8    |  4 |  4 |  4 |             76               |    32    |
    +--------+----+----+----+------------------------------+----------+
    |11111111|flgs|scop|64IX|         sub-group-id         |v4 address|
    +--------+----+----+----+-----------------------------------------+
                                                  +-+-+-+-+
    IPv4-IPv6 Interconnection bits (64IX):        |M|resvd|
                                                  +-+-+-+-+
    "resvd" are reserved bits.

      Figure interconnection:

   1: IPv4-Embedded IPv6 Multicast Address Format: ASM Mode

   The description of the fields is as follows:
   o  "flgs"  Belong to ff3x::/32 and "scop" fields are defined in [RFC4291].

   o  64IX field (IPv4-IPv6 interconnection bits): The first bit is the
      M-bit.  When "M-bit" is be compatible with unicast-based prefix
       [RFC3306] for SSM.  Note that [RFC3306] suggests to set "plen" to 1, it
       0 and "network-prefix" to 0.  As such, any prefix in the 33-96
       range can be convenient.  Given [RFC4607] indicates that future
       specifications may allow a multicast
      IPv4 address is embedded in non-zero network prefix field, a /33
       would allow for future extensions but it has the low-order 32 bits drawback of
       reserving a large block.  A /96 would be adequate for the multicast
      IPv6 address.  All the remaining bits are reserved and MUST use
       cases already identified in [I-D.ietf-mboned-v4v6-mcast-ps].  In
       the event of any concrete extension, reserving additional
       prefixes may be set
      to 0.
   o  sub-group-id: considered.

   2:  Be compatible with embedded-RP [RFC3956] and unicast-based prefix
       [RFC3306] for ASM.  This field is configurable according results in a prefix length to local
      policies (e.g., enable embedded-RP) of be in the entity managing
       17-20 range.  A /17 has the
      IPv4-IPv6 Interconnection Function.  This field MUST follow advantage of allowing for future
       extensions but it may be seen as a waste of the
      recommendations specified in [RFC3306] if multicast address
       space.  Consequently, a /20 is preferred.

   3:  Avoid ff3x::4000:0001-ff3x::7fff:ffff which is reserved for IANA.

   Meeting (1) and (2) with the same prefix is not feasible without
   modifying embedded-RP and unicast-based prefix specifications; this
   option is avoided.

   As a consequence, two multicast prefixes are proposed to be used or when
   embedding IPv4 address: one prefix for ASM and another one for the recommendations specified
   SSM.  This document reserves the following multicast prefixes to be
   used in [RFC3956] if embedded-RP
      is used.  The default value is all zeros. the context of IPv4/IPv6 multicast interconnection:

   o  The low-order 32 bits MUST include  ff3x:0:8000::/96 SSM range to embed an IPv4 multicast address when in
      the M-bit is set last 32 bits.

   o  ffxx:8000::/20 ASM range to 1.  The enclosed embed an IPv4 multicast address SHOULD
      NOT be in 232/8 range.

4. the
      last 32 bits.

3.2.  IPv4-Embedded IPv6 Multicast Address Format: SSM Mode

   As mentioned in Appendix A.4, any IPv4-embedded IPv6 address used in
   SSM mode MUST be part of ff3x::/32 [RFC4607].  Figure 2 describes

   For the
   format delivery of the IPv6 IPv4-IPv6 multicast address to interconnection services,
   a dedicated multicast prefix denoted as MPREFIX64 should be used
   provisioned (e.g., using NETCONF or
   [I-D.ietf-softwire-multicast-prefix-option]) to any function
   requiring to enclose an IPv4
   multicast address.

    |   8    |  4 |  4 |    16     |  4 |       60         |    32    |
    +--------+----+----+-----------+----+------------------+----------+
    |11111111|0011|scop|00.......00|64IX|   sub-group-id   |v4 address|
    +--------+----+----+-----------+----+------------------+----------+
                                                  +-+-+-+-+
    IPv4-IPv6 Interconnection bits (64IX):        |M|resvd|
                                                  +-+-+-+-+
    "resvd" are reserved bits.

      Figure 2: IPv4-Embedded IPv6 Multicast Address Format: SSM Mode

   The description of the fields is as follows:

   o  Flags MUST be set to 0011.
   o  "scop" is defined in [RFC4291].
   o  64IX field (IPv4-IPv6 interconnection bits): Same meaning as
      Section 3.
   o  sub-group-id: The default value is all zeros.
   o  The low-order 32 bits MUST include an IPv4 multicast address when
      the M-bit is set to 1.  The embedded IPv4 address SHOULD be in the
      232/8 range [RFC4607].

5.  Textual Representation

   The embedded IPv4 address in an IPv6 multicast address is included in
   the last 32 bits; therefore dotted decimal notation can be used.

6.  Multicast PREFIX64

   For the delivery of the IPv4-IPv6 multicast interconnection services,
   a dedicated multicast prefix denoted as MPREFIX64 should be
   provisioned (e.g., using NETCONF or
   [I-D.ietf-softwire-multicast-prefix-option]) to any function
   requiring to build an IPv4-embedded IPv6 multicast address based on build an IPv4-embedded IPv6 multicast address based on
   an IPv4 multicast address.  MPREFIX64 can be of ASM or SSM type.
   When both modes are used, two prefixes are required to be
   provisioned.

   The structure length of the MPREFIX64 follows the guidelines specified in
   Section 3 MUST be /96.  MPREFIX64 should belong to
   ffxx:8000::/20 for the ASM mode and Section 4 when ff3x:0:8000::/96 for the SSM mode is used.

   The length of MPREFIX64 MUST be /96 (as shown in Figure 3).

   The mode.

   For the ASM mode, the format of the MPREFIX64 should follow what is
   specified in [RFC3306] and [RFC3956] if corresponding mechanisms are
   used.

      The format specified in Section 3 uses some reserved bits defined
      in [RFC3306] and [RFC3956]: the first of the reserved bits now has
      a meaning, while the remaining  If not, bits MUST 21-96 can be set to 0.

    ASM Mode:

    |   8    |  4 |  4 |  4 |             76               |    32    |
    +--------+----+----+----+------------------------------+----------+
    |11111111|flgs|scop|64IX|         sub-group-id         |v4 address|
    +--------+----+----+----+------------------------------+----------+
    |                                                      |          |
    v                                                      v          v
    +------------------------------------------------------+----------+
    |                ASM_MPREFIX64                         |v4 address|
    +------------------------------------------------------+----------+

    SSM Mode:

    |   8    |  4 |  4 |    16     |  4 |       60         |    32    |
    +--------+----+----+-----------+----+------------------+----------+
    |11111111|0011|scop|00.......00|64IX|   sub-group-id   |v4 address|
    +--------+----+----+-----------+----+------------------+----------+
    |                                                      |          |
    v                                                      v          v
    +------------------------------------------------------+----------+
    |                SSM_MPREFIX64                         |v4 address|
    +------------------------------------------------------+----------+ any value.

   Figure 3: MPREFIX64

7.  Source IPv4 Address in the 1 shows how to build an IPv4-embedded IPv6 Realm

   An multicast address
   using a configured MPREFIX64 and an IPv4 source multicast address.  The low-
   order 32 bits MUST include an IPv4 multicast address.  The enclosed
   IPv4 multicast address SHOULD NOT be in 232/8 range if an
   ASM_PREFIX64 is represented configured.  The enclosed IPv4 multicast address
   SHOULD be in 232/8 range if an SSM_PREFIX64 is configured.

   Embedding an IPv4 multicast address in the IPv6 realm last 32 bits does not
   conflict with its IPv4-
   converted the Group IDs assigned by IANA (i.e., 0x00000001 to
   0x3FFFFFFF [RFC3307]).

   When several MPREFIX64 are available, it is RECOMMENDED to use the
   MPREFIX64 which preserve the scope of the IPv4 multicast address.

    |                             96                       |    32    |
    +------------------------------------------------------+----------+
    |                         MPREFIX64                    |v4 address|
    +------------------------------------------------------+----------+

           Figure 1: IPv4-Embedded IPv6 address [RFC6052].

8. Multicast Address Format

3.3.  Address Translation Algorithm

   IPv4-embedded IPv6 multicast addresses are composed according to the
   following algorithm:

   o  Concatenate the MPREFIX64 and the 32 bits of the IPv4 address to
      obtain a 128-bit address.

   The IPv4 multicast addresses are extracted from the IPv4-embedded
   IPv6 multicast addresses according to the following algorithm:

   o  If the multicast address belongs to ff3x:0:8000/33 ff3x:0:8000::/96 or ffxx:
      8000/17,
      8000::/20, extract the last 32 bits of the IPv6 multicast address.

9.

3.4.  Textual Representation

   The embedded IPv4 address in an IPv6 multicast address is included in
   the last 32 bits; therefore dotted decimal notation can be used.

3.5.  Source IPv4 Address in the IPv6 Realm

   An IPv4 source is represented in the IPv6 realm with its IPv4-
   converted IPv6 address [RFC6052].

4.  Examples

   Figure 4 2 provides an example of ASM IPv4-Embedded IPv6 Address while
   Figure 5 3 provides an example of SSM IPv4-Embedded IPv6 Address.

   IPv4 multicast addresses used in the examples are derived from the
   IPv4 multicast block reserved for documentation in
   [I-D.ietf-mboned-mcaddrdoc].

     +---------------------+--------------+----------------------------+
     |      MPREFIX64      | IPv4 address | IPv4-embedded IPv6 address |
     +---------------------+--------------+----------------------------+
     | ffxx:8000:abc::/96  |  224.1.2.3   |  ffxx:8000:abc::224.1.2.3  | ffxx:8000:0:abc::/96|  233.252.0.1 |ffxx:8000:0:abc::233.252.0.1|
     +---------------------+--------------+----------------------------+

            Figure 4: 2: Example of ASM IPv4-embedded IPv6 address

     +---------------------+--------------+----------------------------+
     |      MPREFIX64      | IPv4 address | IPv4-embedded IPv6 address |
     +---------------------+--------------+----------------------------+
     |   ff3x:0:8000::/96  |  232.1.2.3 233.252.0.5  |   ff3x:0:8000::232.1.2.3   ff3x:0:8000::233.252.0.5 |
     +---------------------+--------------+----------------------------+

            Figure 5: 3: Example of SSM IPv4-embedded IPv6 address

10.

5.  IANA Considerations

   Authors of this document request to reserve:

   o  ff3x:0:8000/33  ff3x:0:8000::/96 SSM block range to embed an IPv4 multicast address in
      the last 32 bits.

   o  ffxx:8000/17  ffxx:8000::/20 ASM block range to embed an IPv4 multicast address in the
      last 32 bits.

11.

6.  Security Considerations

   This document defines an address format to embed algorithmic translation of an IPv4 IPv6 multicast
   address in into an IPv6 IPv4 multicast address. address, and vice versa.  The same security
   considerations as those discussed in [RFC6052] are to be taken into
   consideration.

12.

7.  Acknowledgements

   Many thanks to R. Bonica, B. Sarikaya, P. Savola, T. Tsou and C.
   Bormann for their comments and review.

13.

8.  References
13.1.

8.1.  Normative References

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

   [RFC3306]  Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
              Multicast Addresses", RFC 3306, August 2002.

   [RFC3307]  Haberman, B., "Allocation Guidelines for IPv6 Multicast
              Addresses", RFC 3307, August 2002.

   [RFC3956]  Savola, P. and B. Haberman, "Embedding the Rendezvous
              Point (RP) Address in an IPv6 Multicast Address",
              RFC 3956, November 2004.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, August 2006.

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

13.2.

8.2.  Informative References

   [I-D.ietf-behave-nat64-learn-analysis]
              Korhonen, J. and T. Savolainen, "Analysis of solution
              proposals for hosts to learn NAT64 prefix",
              draft-ietf-behave-nat64-learn-analysis-03 (work in
              progress), March 2012.

   [I-D.ietf-mboned-mcaddrdoc]
              Venaas, S., Parekh, R., Velde, G., Chown, T., and M.
              Eubanks, "Multicast Addresses for Documentation",
              draft-ietf-mboned-mcaddrdoc-04 (work in progress),
              May 2012.

   [I-D.ietf-mboned-v4v6-mcast-ps]
              Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., Tsou, T.,
              and Q. Sun, "IPv4-IPv6 Multicast: Problem Statement and
              Use Cases", draft-ietf-mboned-v4v6-mcast-ps-00 (work in
              progress), May 2012.

   [I-D.ietf-softwire-dslite-multicast]
              Qin, J., Boucadair, M., Jacquenet, C., Lee, Y., and Q.
              Wang, "Multicast Extensions to DS-Lite Technique in
              Broadband Deployments",
              draft-ietf-softwire-dslite-multicast-02 (work in
              progress), May 2012.

   [I-D.ietf-softwire-mesh-multicast]
              Xu, M., Cui, Y., Yang, S., Wu, J., Yang, S., Metz, C., and G.
              Shepherd, "Softwire Mesh Multicast",
              draft-ietf-softwire-mesh-multicast-02
              draft-ietf-softwire-mesh-multicast-03 (work in progress),
              April
              July 2012.

   [I-D.ietf-softwire-multicast-prefix-option]
              Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6
              Option for IPv4-Embedded Multicast and Unicast IPv6
              Prefixes", draft-ietf-softwire-multicast-prefix-option-00 draft-ietf-softwire-multicast-prefix-option-01
              (work in progress), March August 2012.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

Appendix A.  Design Choices  Motivations

A.1.  Why an Address Format is Needed for Multicast IPv4-IPv6
      Interconnection?

   Arguments why an IPv6 address format is needed to embed multicast
   IPv4 address are quite similar to those of [RFC6052].  Concretely,
   the definition of a multicast address format embedding a multicast
   IPv4 address allows:

   o  Stateless IPv4-IPv6 header translation of multicast flows;

   o  Stateless IPv4-IPv6 PIM interworking function;

   o  Stateless IGMP-MLD interworking function (e.g., required for an
      IPv4 receiver to access to IPv4 multicast content via an IPv6
      network);

   o  Stateless (local) synthesis of IPv6 address when IPv4 multicast
      address are embedded in application payload (e.g., SDP [RFC4566]);

   o  Except the provisioning of the same MPREFIX64, no coordination is
      required between IPv4-IPv6 PIM interworking function, IGMP-MLD
      interworking function, IPv4-IPv6 Interconnection Function and any
      ALG (Application Level Gateway) in the path;

   o  Minimal operational constraints on the multicast address
      management: IPv6 multicast addresses can be constructed using what
      has been deployed for IPv4 delivery mode.

A.2.  Why Identifying an IPv4-Embedded IPv6 Multicast Address is
      Required?

   Reserving an M-bit in the IPv6 multicast address (which is equivalent
   to reserving a dedicated multicast block prefix for IPv4-IPv6 interconnection purposes)
   purposes is a means to guide the address selection process at the
   receiver side; in particular it assists the receiver to select the
   appropriate IP multicast address while avoiding to involve an IPv4-IPv6 IPv4-
   IPv6 interconnection function in the path.

   Two use cases to illustrate this behavior are provided below:

   1.  An ALG is required to help an IPv6 receiver to select the
       appropriate IP address when only the IPv4 address is advertised
       (e.g., using SDP); otherwise the access to the IPv4 multicast
       content can not be offered to the IPv6 receiver.  The ALG may be
       located downstream the receiver.  As such, the ALG does not know
       in advance whether the receiver is dual-stack or IPv6-only.  The
       ALG may be tuned to insert both the original IPv4 address and
       corresponding IPv6 multicast address.  If the M-bit a dedicated prefix is
       not used, a dual-stack receiver may prefer to use the IPv6
       address to receive the multicast content.  This address selection
       would require multicast flows to cross an IPv4-IPv6
       interconnection function.

   2.  In order to avoid involving an ALG in the path, an IPv4-only
       source can advertise both its IPv4 address and IPv4-embedded IPv6
       multicast address.  If the M-bit a dedicated prefix is not used, reserved, a
       dual-stack receiver may prefer to use the IPv6 address to receive
       the multicast content.  This address selection would require
       multicast flows to cross an IPv4-IPv6 interconnection function.

   Reserving an M-bit in the dedicated IPv6 multicast address prefixes for IPv4-IPv6
   interconnection purposes mitigates the issues discussed in
   [I-D.ietf-behave-nat64-learn-analysis] in a multicast context.

A.3.  Location of the IPv4 Address

   There is no strong argument to allow for flexible options to encode
   the IPv4 address inside the multicast IPv6 address.  The option
   retained by the authors is to encode the multicast IPv4 address in
   the low-order 32 bits of the IPv6 address.

   This choice is also motivated by the need to be compliant with
   [RFC3306] and [RFC3956].

A.4.  Location of the M-bit

   Figure 6 is a reminder of the IPv6 multicast address format as
   defined in [RFC4291]:

      |   8    |  4 |  4 |                  112 bits                   |
      +------ -+----+----+---------------------------------------------+
      |11111111|flgs|scop|                  group ID                   |
      +--------+----+----+---------------------------------------------+
                                       +-+-+-+-+
         flgs is a set of 4 flags:     |0|R|P|T|
                                       +-+-+-+-+
      *  "T-bit" is defined in [RFC4291];
      *  "P-bit" is defined in [RFC3306]
      *  "R-bit" is defined in [RFC3956]

       Figure 6: IPv6 Multicast address format as defined in RFC4291

   It was tempting to use the remaining flag to indicate whether an IPv6
   address embeds an IPv4 address or not.  This choice has been
   abandoned by the authors for various reasons:
   o  ff3x::/32 is defined as SSM.  Defining a new flag would require
      standards and implementations to also treat ffbx::/32 as SSM.
   o  Prefixes starting with ff7x are defined as embedded-RP, but not
      prefixes starting with fffx.  Below is provided an excerpt from
      [RFC3956]:
         " ...the encoding and the protocol mode used when the two high-
         order bits in "flgs" are set to 11 ("fff0::/12") is
         intentionally unspecified until such time that the highest-
         order bit is defined.  Without further IETF specification,
         implementations SHOULD NOT treat the fff0::/12 range as
         Embedded-RP."
         as such defining a new flag would require implementations to
         also treat ff7x::/12 as embedded-RP prefix.
   o  This is the last remaining flag and at this stage we are not sure
      whether there is other usage scenarios of the flag.

   As a conclusion, the remaining flag is not used to indicate an IPv6
   multicast address embeds an IPv4 multicast address.  However the
   following constraints should be met:

      (1) Belong to ff3x::/32 and be compatible with unicast-based
      prefix [RFC3306] for SSM.  Note that [RFC3306] suggests to set
      "plen" to 0 and "network-prefix" to 0.
      (2) Be compatible with embedded-RP [RFC3956] and unicast-based
      prefix [RFC3306] for ASM;
      (3) Avoid ff3x::4000:0001-ff3x::7fff:ffff which is reserved for
      IANA.
   Meeting (1) and (2) with the same location of the M-bit is not
   feasible without modifying embedded-RP and unicast-based prefix
   specifications; this option is avoided.

   As a consequence, two multicast blocks are proposed to be used when
   embedding IPv4 address: one block for ASM (Section 3 ) and another
   one for the SSM (Section 4).

A.5.  Encapsulation vs. Translation

   IPv4-IPv6 encapsulator and translator may be embedded in the same
   device or even implemented with the same software module.  In order
   to help the function whether an encapsulated IPv6 multicast packets
   or translated IPv6 ones are to be transferred.  It was tempting to
   define an S-bit for that purpose but this choice has been abandoned
   in favor of the recommendation to use distinct MPREFIX64 for each
   scheme.

   As such, there is no need to reserve a bit in the IPv6 multicast
   address to separate between the translation and the encapsulation
   schemes.

Authors' Addresses

   Mohamed Boucadair (editor)
   France Telecom
   Rennes,   35000
   France

   Email: mohamed.boucadair@orange.com

   Jacni Qin
   Cisco
   China

   Email: jacni@jacni.com

   Yiu L. Lee
   Comcast
   U.S.A

   Email: yiu_lee@cable.comcast.com

   Stig Venaas
   Cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: stig@cisco.com

   Xing Li
   CERNET Center/Tsinghua University
   Room 225, Main Building, Tsinghua University
   Beijing,   100084
   P.R. China

   Phone: +86 10-62785983
   Email: xing@cernet.edu.cn
   Mingwei Xu
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing,   100084
   P.R.China

   Phone: +86-10-6278-5822
   Email: xmw@cernet.edu.cn