[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-boucadair-behave-64-multicast-address-format) 00

Network Working Group                                  M. Boucadair, Ed.
Internet-Draft                                            France Telecom
Updates: 4291 (if approved)                                       J. Qin
Intended status: Standards Track                                     ZTE
Expires: July 26, 2012                                            Y. Lee
                                                                 Comcast
                                                               S. Venaas
                                                           Cisco Systems
                                                                   X. Li
                                                  CERNET Center/Tsinghua
                                                              University
                                                                   M. Xu
                                                     Tsinghua University
                                                        January 23, 2012


              IPv4-Embedded IPv6 Multicast Address Format
             draft-boucadair-64-multicast-address-format-00

Abstract

   This document specifies an extension to the IPv6 multicast addressing
   architecture to be used in the context of IPv4-IPv6 interconnection.
   In particular, this document defines an address format for IPv4-
   embedded IPv6 multicast addresses.  This address format can be used
   for 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



Boucadair, et al.         Expires July 26, 2012                 [Page 1]


Internet-Draft         64 Multicast Address Format          January 2012


   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 26, 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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

































Boucadair, et al.         Expires July 26, 2012                 [Page 2]


Internet-Draft         64 Multicast Address Format          January 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  IPv4-Embedded IPv6 Multicast Address Format: ASM Mode  . . . .  4
   4.  IPv4-Embedded IPv6 Multicast Address Format: SSM Mode  . . . .  5
   5.  Textual Representation . . . . . . . . . . . . . . . . . . . .  6
   6.  Multicast PREFIX64 . . . . . . . . . . . . . . . . . . . . . .  6
   7.  Source IPv4 Address in the IPv6 Ream . . . . . . . . . . . . .  7
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   11. Normative References . . . . . . . . . . . . . . . . . . . . .  8
   Appendix A.  Design Choices  . . . . . . . . . . . . . . . . . . .  8
     A.1.  Location of the IPv4 Address . . . . . . . . . . . . . . .  8
     A.2.  Location of the M-bit  . . . . . . . . . . . . . . . . . .  8
     A.3.  Encapsulation vs. Translation  . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10

































Boucadair, et al.         Expires July 26, 2012                 [Page 3]


Internet-Draft         64 Multicast Address Format          January 2012


1.  Introduction

   This document specifies an extension to the IPv6 multicast addressing
   architecture to be used in the context of IPv4-IPv6 interconnection.
   In particular, this document defines an address format for IPv4-
   embedded IPv6 multicast addresses.  This address format can be used
   for IPv4-IPv6 translation or encapsulation schemes.

   This document updates [RFC4291].

   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 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 ASM mode and Section 4 for 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.
   o  ASM_MPREFIX64: denotes a multicast Prefix64 used in ASM mode.  It
      follows the format described in Section 3.
   o  SSM_MPREFIX64: denotes a multicast Prefix64 used in SSM mode.  It
      follows the format described in Section 4.


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

   To meet the requirements listed in Appendix A.2, the following
   address format is defined to enclose an IPv4 multicast address when
   ASM mode is used:









Boucadair, et al.         Expires July 26, 2012                 [Page 4]


Internet-Draft         64 Multicast Address Format          January 2012


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

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

   The description of the fields is as follows:
   o  "flgs" 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 set to 1, it indicates that an multicast
      IPv4 address is embedded in the low-order 32 bits of the multicast
      IPv6 address.  All the remaining bits are reserved and MUST be set
      to 0.
   o  sub-group-id: This field is configurable according to local
      policies of the entity managing the IPv4-IPv6 Interconnection
      Function.  This field must follow the recommendations specified in
      [RFC3306] if unicast-based prefix is used or the recommendations
      specified in [RFC3956] if embedded-RP is used.  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 enclosed IPv4 multicast address SHOULD
      NOT be in 232/8 range.


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

   As mentioned above, any IPv4-embedded IPv6 address used in SSM mode
   MUST be part of ff3x::/32 [RFC4607].  Figure 2 describes the format
   of the IPv6 multicast address to be used to enclose an IPv4 multicast
   address.

















Boucadair, et al.         Expires July 26, 2012                 [Page 5]


Internet-Draft         64 Multicast Address Format          January 2012


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

      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]. 232.0.0.1-232.0.0.255 range is being
      reserved to IANA.


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 to any function requiring to 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 of the MPREFIX64 follows the guidelines specified in
   Section 3 for the ASM mode and Section 4 when SSM mode is used.

   The RECOMMENDED MPREFIX64 length is /96 (as shown in Figure 3).

   The format of the MPREFIX64 should be compatible with what is
   specified in [RFC3306] and [RFC3956] if corresponding mechanisms are
   used.





Boucadair, et al.         Expires July 26, 2012                 [Page 6]


Internet-Draft         64 Multicast Address Format          January 2012


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


                            Figure 3: MPREFIX64


7.  Source IPv4 Address in the IPv6 Ream

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


8.  IANA Considerations

   Authors of this document request to reserve:
   o  ff3x:0:8000/33 SSM block to embed an IPv4 multicast address in the
      last 32 bits.
   o  ffxx:8000/17 ASM block to embed an IPv4 multicast address in the
      last 32 bits.


9.  Security Considerations

   This document defined an address format to embed an IPv4 multicast
   address in an IPv6 multicast address.  The same security
   considerations as those discussed in [RFC6052] are to be taken into



Boucadair, et al.         Expires July 26, 2012                 [Page 7]


Internet-Draft         64 Multicast Address Format          January 2012


   consideration.


10.  Acknowledgements

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


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

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


Appendix A.  Design Choices

A.1.  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.2.  Location of the M-bit

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



Boucadair, et al.         Expires July 26, 2012                 [Page 8]


Internet-Draft         64 Multicast Address Format          January 2012


      |   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 4: 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.  Blow 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



Boucadair, et al.         Expires July 26, 2012                 [Page 9]


Internet-Draft         64 Multicast Address Format          January 2012


   embedding IPv4 address: one block for ASM (Section 3 ) and another
   one for the SSM (Section 4).

A.3.  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
   ZTE
   Shanghai
   China

   Email: jacniq@gmail.com


   Yiu L. Lee
   Comcast
   U.S.A

   Email: yiu_lee@cable.comcast.com










Boucadair, et al.         Expires July 26, 2012                [Page 10]


Internet-Draft         64 Multicast Address Format          January 2012


   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
























Boucadair, et al.         Expires July 26, 2012                [Page 11]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/