Internet DRAFT - draft-sarikaya-behave-mcast4nat64

draft-sarikaya-behave-mcast4nat64






Network Working Group                                        B. Sarikaya
Internet-Draft                                                Huawei USA
Intended status: Standards Track                            T. Kiviniemi
Expires: July 11, 2013                                               CSC
                                                         January 7, 2013


                      Multicast Support for NAT64
                draft-sarikaya-behave-mcast4nat64-07.txt

Abstract

   This memo specifies modifications required to NAT64 so that IPv6 only
   hosts can receive multicast data from IPv4 only servers.  The
   protocol is based on translating IPv4 multicast data before
   delivering it to the host in IPv6.  The protocol also allows IPv6
   only host to join IPv4 any source/ source specific multicast group in
   IPv6 using Multicast Listener Discovery protocol.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 11, 2013.

Copyright Notice

   Copyright (c) 2013 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



Sarikaya & Kiviniemi      Expires July 11, 2013                 [Page 1]

Internet-Draft             Multicast for NAT64              January 2013


   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.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Architecture . . . . . . . . . . . . . . . . . . . . . . . . .  3
   5.  NAT64 Multicast Operation  . . . . . . . . . . . . . . . . . .  5
     5.1.  Address Translation  . . . . . . . . . . . . . . . . . . .  5
       5.1.1.  Learning Multicast  Prefixes for IPv4-embedded
               IPv6 Multicast Addresses . . . . . . . . . . . . . . .  6
     5.2.  Protocol Translation . . . . . . . . . . . . . . . . . . .  7
       5.2.1.  Differences with IP/ICMP Translation . . . . . . . . .  8
       5.2.2.  PIM versus IGMP  . . . . . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     9.2.  Informative references . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11



























Sarikaya & Kiviniemi      Expires July 11, 2013                 [Page 2]

Internet-Draft             Multicast for NAT64              January 2013


1.  Introduction

   With IPv4 address depletion on the horizon, many techniques are being
   standardized for IPv6 migration including NAT64 [RFC6146].  NAT64
   together with DNS64 [RFC6147] and the translation algorithm [RFC6145]
   enables IPv6-only hosts to communicate with IPv4-only servers.

   NAT64 currently supports only unicast communication [RFC6146],
   [RFC6145], [RFC6052].  With the advent of IPTV and Mobile IPTV, there
   is a need to provide support for multicast communication as well.

   The document continues in Section 3 with a set of requirements on a
   solution for NAT64 multicast support.  In Section 4 the architecture
   is presented.  Multicast translation protocol is explained in
   Section 5.


2.  Terminology

   This document uses the terminology defined in [RFC6146], [RFC6145],
   [RFC6052], [I-D.ietf-mboned-64-multicast-address-format], [RFC3810]
   and [RFC3376].


3.  Requirements

   This section states requirements on NAT64 translation protocol.

   The protocol MUST support IPv4-embedded IPv6 multicast addresses as
   defined in [I-D.ietf-mboned-64-multicast-address-format].  The
   translation protocol MUST enable an IPv6 only host to join IPv4
   multicast groups where IPv6 only host identifies IPv4 groups using
   IPv4-embedded IPv6 multicast addresses.

   Both any source multicast (ASM) and source specific multicast (SSM)
   MUST be supported.

   In IPv4 network, Protocol Independent Multicast routing MAY be
   supported.  In IPv4 network, Internet Group Management Protocol
   routing MAY be supported.

   User Datagram Protocol (UDP) MUST be supported.  Transmission Control
   Protocol (TCP) MAY be supported.


4.  Architecture

   We consider an IPv6 only host (Host 1, H1) that wishes to receive



Sarikaya & Kiviniemi      Expires July 11, 2013                 [Page 3]

Internet-Draft             Multicast for NAT64              January 2013


   multicast data sent to IPv4 multicast groups, sent by an IPv4 only
   host (Host 2, H2).  Multicast data sent to an IPv4 multicast group
   such as 232.1.2.3 must be translated into an IPv6 multicast group
   data such as FF3E::232.1.2.3.  So a translator element is needed in
   the architecture.  The translator has to be connected simultaneously
   into IPv4 network and IPv6 network.

                +---------------------------+        +---------------+
                |                           |        |               |
                |IPv6 network           +-------+    |    IPv4       |
                |           |  +-----+  |IGMPv3 |    |  Network      |
                |           |--| MLD |  |Client | -- |               |
                |           |  +-----+  +-------+    |    +----+     |
                |  +----+   |           +------+     |--- | H2 |     |
                |  | H1 |---|           | PIM  | --- |    +----+     |
                |  +----+   |           +------+     |  232.1.2.3    |
                |FF3E::     |      +-----------+     |               |
                |  232.1.2.3|----- |Translator |---- |               |
                |           |      +-----------+     |               |
                |           |               |        |               |
                +---------------------------+        +---------------+

           Figure 1: Key elements of NAT64 Multicast Translator

   In order to receive multicast data, the host H1 must first subscribe
   to the multicast group of interest.  In IPv6 this is done using MLD
   protocol [RFC3810] by sending MLD Membership Report message
   indicating the group address which should have an IPv4 multicast
   group address embedded such as FF3E::232.1.2.3.  MLD entity has to
   communicate the group membership information to an entity that
   supports wide-area multicast routing protocol such as PIM [RFC3973],
   [RFC4601], [RFC5015].  PIM supports both IPv4 and IPv6.

   IPv4 group address in MLD membership Report message should be
   communicated to an entity that supports IGMP protocol [RFC3376].  So
   an IGMP Client is needed to handle joining and leaving IPv4 multicast
   groups by sending IGMPv3 Report messages to IPv4 network.  Once IGMP
   Client subscribes to an IPv4 multicast group, all IPv4 multicast
   packets can be received from the interface connected to IPv4 network.
   The translator translates such packets into IPv6 multicast data
   packets and forwards them to IPv6 network which delivers it to IPv6
   hosts that have joined the corresponding IPv6 multicast group.

   All the elements of NAT64 multicast translation system are shown in
   Figure 1.  Not shown in the figure are MLD Proxies which are located
   in Host 1's first hop router.  MLD Proxy optimizes MLD operation by
   providing only aggregate multicast group membership information to
   the upstream MLD router and duplicating multicast data at a place



Sarikaya & Kiviniemi      Expires July 11, 2013                 [Page 4]

Internet-Draft             Multicast for NAT64              January 2013


   close to the hosts.

   Note that the architecture in Figure 1 is generic and does not
   prescribe any solution as to where in a real network the different
   components can be hosted or whether the architecture can be
   duplicated in the same network.  While in unicast communication
   multiple NAT64 boxes can be supported in an operator's network using
   multiple Pref64s, in multicast NAT64 the same does not hold because
   IPv6 only hosts do not send multicast data.  The elements in the
   architecture in Figure 1 are best placed in where the designated MLD
   router/ querier is hosted.  In broadband networks Broadband Network
   Gateway (BNG), in 3GPP networks Packet Data Network Gateway (P-GW)
   are the candidates for such a placement.  This implies that NAT64
   multicast translator may be hosted in a different network element
   than NAT64 unicast translator [RFC6146].


5.  NAT64 Multicast Operation

   In this section we specify how the host can receive IPv4 multicast
   data from IPv4-only content provider based on the architecture
   defined in Section 4.  The reverse translation of IPv6 multicast data
   for IPv4-only receivers is out of scope.  Multicast translation
   involves address translation defined in Section 5.1 and protocol
   (IPv4 to IPv6) translation defined in Section 5.2.

5.1.  Address Translation

   IPv6-only H1 will join IPv4 multicast group by sending MLD Membership
   Report message upstream towards the MLD entity in Figure 1.  H1 MUST
   use synthesized IPv6 address of IPv4 multicast group address using
   IPv4-embedded IPv6 multicast address format
   [I-D.ietf-mboned-64-multicast-address-format].  ASM_MPREFIX64 for any
   source multicast groups and SSM_MPREFIX64 for source specific
   multicast groups are used.  Both are /96 prefixes.

   In both ASM_MPREFIX64 and SSM_MPREFIX64, M bit MUST be set to 1 to
   indicate that an IPv4 address is embedded in the last 32 bits of the
   multicast IPv6 address.  ASM_MPREFIX64 values are formed by setting
   flgs bits to make it an embedded RP prefix by setting R bit to 1 and
   P and T bits to 1 as shown in Figure 2 [RFC4291], [RFC3306],
   [RFC3956].

     |   8    |  4 |  4 |  4 |             76               |    32    |
     +--------+----+----+----+------------------------------+----------+
     |11111111|0111|scop|1000|         sub-group-id         |v4 address|
     +--------+----+----+----+-----------------------------------------+




Sarikaya & Kiviniemi      Expires July 11, 2013                 [Page 5]

Internet-Draft             Multicast for NAT64              January 2013


                     Figure 2: ASM_MPREFIX64 Formation

   Each translator is assigned a unique ASM_MPREFIX64 prefix.  The hosts
   can learn this value by means out of scope with this document.  With
   this, the host can easily create an IPv6 multicast address from the
   IPv4 group address a.b.c.d that it wants to join.

   Source-Specific Multicast (SSM) can also be supported similar to the
   Any Source Multicast (ASM) described above.  In case of SSM, IPv4
   multicast addresses use 232.0.0.0/8 prefix.  IPv6 SSM_MPREFIX64
   values are formed by setting R bit to zero, P and T bits to 1.  This
   gives FF3x00008x::/96 as the SSM prefix.  This prefix is referred to
   as SSM_PREFIX64 Figure 3.

     |   8    |  4 |  4 |    16     |  4 |       60         |    32    |
     +--------+----+----+-----------+----+------------------+----------+
     |11111111|0011|scop|00.......00|1000|   sub-group-id   |v4 address|
     +--------+----+----+-----------+----+------------------+----------+

                     Figure 3: SSM_MPREFIX64 Formation

   Since SSM translation requires a unique address for each IPv4
   multicast source, an IPv6 unicast prefix must be configured to the
   translator to represent IPv4 sources.  This prefix is prepended to
   IPv4 source addresses in translated packets.

   The join message from the host for the group ASM_MPREFIX64:a.b.c.d or
   SSM_MPREFIX64:a.b.c.d or an aggregate join message will be received
   by MLD entity in the translator.  The translator as multicast anchor
   checks the group address and recognizes ASM_MPREFIX64 or
   SSM_MPREFIX64 prefix.  It next checks the last 32 bits is an IPv4
   multicast address in range 224/8 - 239/8.  If all checks succeed,
   IGMPv4 Client joins a.b.c.d using IGMP on its IPv4 interface.

   Joining IPv4 groups can also be done using PIM since PIM supports
   both IPv4 and IPv6.  The advantage of using PIM is that there is no
   need to enable IGMP support in neighboring IPv4 routers.  The
   advantage of using IGMP is that IGMP is a simpler protocol and it is
   supported by a wider range of routers.  The use of PIM or IGMP is
   left as an implementation choice.

5.1.1.  Learning Multicast  Prefixes for IPv4-embedded IPv6 Multicast
        Addresses

   The hosts can be pre-configured with Multicast Prefix64 of
   ASM_MPREFIX64 and SSM_MPREFIX64 that are supported in their network.
   However automating this process is also desired.
   [I-D.sarikaya-softwire-6man-raoptions] describes a Router



Sarikaya & Kiviniemi      Expires July 11, 2013                 [Page 6]

Internet-Draft             Multicast for NAT64              January 2013


   Advertisement based method which is suitable for mobile hosts
   accessing 3GPP networks.

   A new DHCPv6 option, OPTION_AFT_PREFIX_DHCP, can be defined for this
   purpose.  The option contains IPv6 ASM and SSM prefixes.  The host
   can request these prefixes by sending this option in its request to
   the DHCP server and the server replies with the option containing the
   prefixes.

   After the host gets the multicast prefixes, when an application in
   the host wishes to join an IPv4 multicast group the host MUST use
   ASM_MPREFIX64 or SSM_MPREFIX64 and then obtain the synthesized IPv6
   group address before sending MLD join message.

5.2.  Protocol Translation

   Translator, after processing the addresses will then translate IPv4
   multicast data packet into an IPv6 multicast data packet.  The
   destination address is IPv6 group address ASM_MPREFIX64::a.b.c.d and
   source address is the translator's IPv6 interface address.  The value
   in Type of Service (TOS) field of IPv4 packet is copied into IPv6
   Traffic Class field.  IPv4 Protocol and TTL fields are copied into
   IPv6 Next Header and Hop Limit fields respectively.  IPv4 payload is
   copied into IPv6 payload.  UDP checksum is updated which completes
   the packet translation process [Thesis].  The packet is sent towards
   the host and on its way it may be duplicated for each member of this
   group and then sent to the individual host separately.

   Any IPv4 fragments sent by the routers must be translated into IPv6
   packets with IPv6 Fragment Header.  Fragmentation Offset field is
   copied into the corresponding field in the Fragment Header. 16-bit
   Identification field is copied into the low-order 16 bits of IPv6
   Fragment Header Identification field.  The high-order bits of the 32-
   bit IPv6 Fragment Header Identification field are set to zero.  More
   Fragments (MF) flag is copied to the corresponding field in IPv6
   Fragment Header [Thesis].

   Multicast translation described in this section is not specific to
   the hosts.  Translator gets the join message from the host and then
   updates the membership database.  Translator and any MLD Proxies
   downstream have to know all members of each IPv4 group so that they
   can correctly duplicate the data packets and deliver to the
   individual hosts.

   Also this prefix must be routed towards the translator on the IPv6
   network, to enable reverse path forwarding for multicast, and to
   inform other PIM routers about the correct destination for PIM (S,G)
   Join messages [Thesis].



Sarikaya & Kiviniemi      Expires July 11, 2013                 [Page 7]

Internet-Draft             Multicast for NAT64              January 2013


5.2.1.  Differences with IP/ICMP Translation

   The Stateless IP/ICMP translation [RFC6145] is designed for unicast
   communication.  IP/ICMP Translation uses a different address
   translation than multicast address translation described Section 5.1.
   However some parts of IP/ICMP Translation can be used in multicast
   translation.  In this section we describe the differences of IP/ICMP
   Translation with NAT64 translation.

   IP/ICMP Translation translates IPv4 packets into IPv6 using minimum
   MTU size of 1280 bytes.  However in DVB-IPTV data streams, 1364 byte
   IPv6 packets need to be supported.  NAT64 translator must perform
   IPv6 path MTU discovery and set the MTU size accordingly, not
   necessarily always to 1280 byte MTU size.  Note that IPv4 routers
   must not send ICMPv4 error message in response to a multicast packet
   [RFC1812] while in IPv6 this is not the case which enables path MTU
   discovery for multicast.  Path MTU values are kept in the translator
   for each multicast group.  However, for SSM, a different MTU value
   MUST be kept for each SSM channel.

   IP/ICMP Translation does not require transport layer checksum
   modifications because the prefixes used in IP/ICMP Translation are
   checksum neutral.  NAT64 translator must however modify the UDP
   checksum to replace the IPv4 addresses with the IPv6 source and
   destination addresses in the pseudo-header which consists of source
   address, destination address, protocol and UDP length fields before
   calculating the new checksum.

5.2.2.  PIM versus IGMP

   To handle joining and leaving IPv4 multicast groups, PIM client
   instead of IGMPv3 client as mentioned in Section 4 can be used.  With
   IGMPv3, SSM support requires that all neighboring routers support
   IGMPv3.  If they support IGMPv1 or IGMPv2 the translator has to also
   support IGMPv1 or IGMPv2 for compatibility and as a result, SSM could
   not be supported.

   SSM can be supported with a PIM Client at the translator.  There are
   other advantages of having PIM client at the translator.  PIM can
   communicate with neighboring IPv4 routers over flexible connections.
   The need to enable IGMP in the neighboring routers is removed if PIM
   is used.

   On the other hand, IGMP, being a simpler protocol than PIM, is more
   widely supported.  IGMP does not need to know the location of
   rendezvous points (RP) which makes it easier to configure the
   translator.




Sarikaya & Kiviniemi      Expires July 11, 2013                 [Page 8]

Internet-Draft             Multicast for NAT64              January 2013


6.  Security Considerations

   Security considerations for IPv4 interface of the translator is
   similar to [RFC6146] and the considerations stated there apply.


7.  IANA Considerations

   TBD.


8.  Acknowledgements

   TBD.


9.  References

9.1.  Normative References

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

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers",
              RFC 1812, June 1995.

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

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

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

   [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



Sarikaya & Kiviniemi      Expires July 11, 2013                 [Page 9]

Internet-Draft             Multicast for NAT64              January 2013


              Architecture", RFC 4291, February 2006.

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

   [RFC5015]  Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
              "Bidirectional Protocol Independent Multicast (BIDIR-
              PIM)", RFC 5015, October 2007.

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

   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, April 2011.

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

   [RFC6147]  Bagnulo, M., Sullivan, A., Matthews, P., and I. van
              Beijnum, "DNS64: DNS Extensions for Network Address
              Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
              April 2011.

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

9.2.  Informative references

   [I-D.sarikaya-softwire-6man-raoptions]
              Sarikaya, B., "IPv6 RA Options for Translation Multicast
              Prefixes", draft-sarikaya-softwire-6man-raoptions-00 (work
              in progress), August 2012.

   [Thesis]   Teemu Kiviniemi, Helsinki University of Technology,
              Master's Thesis, "Implementation of an IPv4 to IPv6
              Multicast Translator", October 2009.








Sarikaya & Kiviniemi      Expires July 11, 2013                [Page 10]

Internet-Draft             Multicast for NAT64              January 2013


Authors' Addresses

   Behcet Sarikaya
   Huawei USA
   5340 Legacy Drive, Suite 175
   Plano, TX  75074

   Phone: +1 469-277-5700
   Email: sarikaya@ieee.org


   Teemu Kiviniemi
   CSC

   Phone:
   Email: teemu.kiviniemi@csc.fi



































Sarikaya & Kiviniemi      Expires July 11, 2013                [Page 11]