Behave Work Group                                             S. Jiang
Internet Draft                                                   D. Gu
Intended status: Standard Track           Huawei Technologies Co., Ltd
Expires: July 10, 2011                                January 07, 2011

                Multicast Proxy in IPv6/IPv4 Transition
                 draft-jiang-behave-v4v6mc-proxy-02.txt


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 10, 2011.

Copyright Notice

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












Jiang & Gu              Expires July 10, 2011                 [Page 1]


Internet-Draft draft-jiang-behave-v4v6mc-proxy-02.txt    Janauary 2011




Abstract

   During the long co-existing period of IPv6 and IPv4, the
   interoperation between IPv6 network and IPv4 network is essential.
   Multicast services across IPv6 and IPv4 networks are also needed.
   Besides the packet-based multicast translation mechanism, this
   document describes a multicast proxy solution. The multicast proxy is
   deployed at the border of IPv6/IPv4 networks. It is mainly based on
   content cache concept. Without packet-based translation, it retires
   the content data from IPvX network, caches the data, and multicasts
   the data in IPvY network. It acts as a multicast leaf in the IPvX
   network where the data source locates. It also acts as a multicast
   source in IPvY network where the multicast client locates.

Table of Contents

   1. Introduction.................................................3
   2. Terminology..................................................3
   3. Multicast Proxy without packet-based IPv6/IPv4 Translation...3
      3.1. Overview................................................3
      3.2. Operation procedure.....................................5
   4. Security Considerations......................................6
   5. IANA Considerations..........................................7
   6. Change Log [RFC Editor please remove]........................7
   7. References...................................................7
      7.1. Normative References....................................7
      7.2. Informative References..................................7
   Author's Addresses..............................................8


















Jiang & Gu              Expires July 10, 2011                 [Page 2]


Internet-Draft draft-jiang-behave-v4v6mc-proxy-02.txt    Janauary 2011



1. Introduction

   The confirmation of IPv4 address exhaustion clearly indicates that
   global IPv6 deployment is inevitably going to happen. However, it is
   also widely agreed that IPv4 will be still in use for a long period.
   During the long co-existing period of IPv6 and IPv4, the
   interoperation between IPv6 network and IPv4 network is essential.

   Now, multimedia has been deployed widely, such as IPTV and video
   conference etc. They also face the IPv6 and IPv4 intercommunication
   issues. The multicast applications are complicated and face more
   difficulties than unicast applications deployment.

   [I-D.draft-venaas-behave-v4v6mc-framework] proposes a packet-based
   translation framework between IPv4/IPv6 multicast services. It
   describes the packet-based translation operations and
   intercommunication in network layer to support a single source send
   to multiple receivers in different IP networks.

   Besides the packet-based multicast translation mechanism, this
   document describes a multicast proxy solution, which is mainly based
   on content cache.

   A multicast proxy can be deployed at the border between IPv4/IPv6
   networks. Without packet-based translation, it retires the content
   data from IPvX network, caches the data, and multicasts the data in
   IPvY network. It acts as a multicast leaf in the IPvX network where
   the data source locates. It also acts as a multicast source in IPvY
   network where the multicast client locates.

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

3. Multicast Proxy without packet-based IPv6/IPv4 Translation

3.1. Overview

   Within this document, we describe the network where the data source
   locates as IPvX network and the network where the multicast client
   locates as IPvY network. When IPvX is IPv6, IPvY must be IPv4, vice
   versa.




Jiang & Gu              Expires July 10, 2011                 [Page 3]


Internet-Draft draft-jiang-behave-v4v6mc-proxy-02.txt    Janauary 2011


                                |
      <----------IPvX---------->|<---------IPvY----------->
                                |
      +-----------+       +-----------+       +-----------+
      | multicast |------>| multicast |------>| multicast |
      |  source   |       |   proxy   |       |   client  |
      +-----------+       +-----------+       +-----------+
                                |
   Figure 1: Multicast proxy Forward Contents to different IP networks

   As showed in Figure 1, the proposed multicast proxy is deployed at
   the border of IPv4/IPv6 networks. It MUST support both IPv4 and IPv6.
   It MUST support both IGMP (Internet Group Management Protocol,
   [RFC3376]), which is used for IPv4 multicast management functions,
   and MLD (Multicast Listener Discovery, [RFC3810]), which is used in a
   similar way in IPv6 Environment. In the IPvX network, the multicast
   proxy joins the multicast distribution tree as a leaf. In the IPvY
   network, the multicast proxy broadcasts contents as a multicast
   source. The establishment of multicast distribution trees obeys the
   current multicast specifications for each IP family, such as Protocol
   Independent Multicast (PIM [RFC4601]).

   Notice that there are two different multicast distribution trees in
   two sides of the multicast proxy. They are operational independent
   from each other in the network layer.

   Logically, they are relevant to each other and there are
   interoperation behaviors between them. The contents published through
   the multicast distribution tree in IPvY network inherits from the
   IPvX network. They are received by the multicast proxy, which is a
   multicast leaf in the multicast distribution tree in IPvX network.
   Within the multicast proxy, contents are mapped between receiver
   function and publisher function. The operations of the multicast
   distribution tree in IPvY network MAY trigger some operations of the
   multicast distribution tree in IPvX network. For example, a multicast
   client joins a multicast group in IPvY network, and requests
   multicast contents may cause the multicast proxy joins a multicast
   group in IPvX network.

   However, as mentioned earlier, in network or IP layer, the two
   multicast distribution trees are independent from each other. Their
   operations are separated in two sides of the multicast proxy.
   Conceptually, the multicast proxy can be presented virtually in
   functional modules like below Figure 2.





Jiang & Gu              Expires July 10, 2011                 [Page 4]


Internet-Draft draft-jiang-behave-v4v6mc-proxy-02.txt    Janauary 2011


   <------------IPvX-------------->|<------------IPvY--------------->
                   +-------------------------------+
                   |     +-------------------+     |
                   |     |Content cache & mgt|     |
                   |     +-------------------+     |
                   |       /                \      |
   +---------+     | +----------+     +----------+ |     +---------+
   |multicast|     | |  proxy   |     |  proxy   | |     |multicast|
   | source  |-----+>| receiver |     | publisher|-+---->|  client |
   |         |     | |  (IPvX)  |     |  (IPvY)  | |     |         |
   +---------+     | +----------+     +----------+ |     +---------+
                   +-------------------------------+
                                   |
          Figure 2: Separate function model of multicast proxy

   As shown in Figure 2, the proxy receiver module in IPvX network joins
   IPvX multicast groups as a receiver client. Thereby it receives
   packets bound for the IPvX multicast groups, and then hands the
   content to the content cache and management module. The content cache
   and management module then forward the on-demand content to the
   multicast proxy function module in IPvY network, which acts as a
   publisher and multicast source in IPvY network.

3.2. Operation procedure

   <-------------IPvX---------------->|<------------IPvY--------------->
   multicast source            multicast proxy          multicast client
      |                      Content cache & mgt                      |
      |          proxy receiver       |     proxy publisher           |
      |               |               |               |               |
      |               |               |               |   Join IPvY   |
      |               |               |               |multicast group|
      |               |               | Report to mgt |<-----(1)------|
      |               |  Send request |<-----(2)------|               |
      |Join IPvX group|<-----(3)------|               |               |
      |<-----(4)------|               |               |               |
      |               |               |               |               |
      |   Send IPvX   |               |               |               |
      |multicastpacket|               |               |               |
      |------(5)----->|Report contents|Divert request&|               |
      |               |------(6)----->|Divert contents|   Send IPvY   |
      |               |               |------(7)----->|multicastpacket|
      |               |               |               |------(8)----->|
      |               |               |               |               |

       Figure. 3 The interaction communicating from IPvX to IPvY



Jiang & Gu              Expires July 10, 2011                 [Page 5]


Internet-Draft draft-jiang-behave-v4v6mc-proxy-02.txt    Janauary 2011


   As shown in Figure 3, a client, which locates in IPvY network,
   connects to the multicast proxy, requesting a multicast service whose
   source locates in the IPvX network.

   First, the client sends a join IPvY multicast group report (1) to the
   multicast proxy. The proxy publisher module, which also locates in
   the IPvY network, receives this report, then forwards the content
   request to the content cache & management module (2). The content
   cache & mgt module maintains a content & multicast service table,
   including all available multicast services from IPvX network. The
   content cache & mgt module searches the client request in its
   dynamically updated table.

   If the requested content is already multicasted in the IPvY network,
   the content cache & mgt module diverts the user report back to the
   proxy publisher module (7). The proxy publisher module adds the new
   client into its existing multicast tree. Then the requested content
   can be sent to the client (8).

   If the requested content is available but not multicasted in IPvY
   network yet, the content cache & mgt module sends a request to the
   proxy receiver module, which locates in the IPvX network (3). It
   initiates the proxy receiver module to send a join IPvX multicast
   group report (4) to the multicast source. The multicast source adds
   the multicast proxy into its multicast tree and sends IPvX multicast
   packets (5). When receiving the multicast packets, the proxy receiver
   module drops all network layer information, such as IP headers, etc.,
   and only reports contents to the content cache & mgt module (6). The
   content cache & mgt module then diverts contents to the proxy
   publisher module (7). The proxy publisher module builds up a new
   multicast tree in the IPvY network, and sends multicast packets to
   clients (8).

   If all the clients, requesting a certain multicast service in the
   IPvY network, leave the IPvY multicast group, the multicast proxy MAY
   leave the IPvX multicast group in IPvX network.

   Multicast proxies MAY also perform load-balancing, user
   authentication and other additional functions.

4. Security Considerations

   The multicast proxy solution actually separate the IPv4 and IPv6
   multicast services effectively. It prevents the attacks at only one
   side of it.




Jiang & Gu              Expires July 10, 2011                 [Page 6]


Internet-Draft draft-jiang-behave-v4v6mc-proxy-02.txt    Janauary 2011


   However, multicast proxy itself is as vulnerable as normal multicast
   sources and multicast leafs in each IPv4 or IPv6 environment. The
   security mechanisms for IGMP/MLD can be used to enhance the security
   of multicast proxy.

5. IANA Considerations

   This draft does not request any IANA action.

6. Acknowledgments

   The authors would like to thank Stig Venaas, Cisco for his valuable
   comments.

7. Change Log [RFC Editor please remove]

   draft-jiang-behave-v4v6mc-proxy-00, original version, 2010-03-01

   draft-jiang-behave-v4v6mc-proxy-01, private discussion and comments
   from Stig Venaas, 2010-07-09

   draft-jiang-behave-v4v6mc-proxy-02, regular update, 2011-01-07

8. References

8.1. Normative References

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

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

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

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

8.2. Informative References

   [I-D.draft-venaas-behave-v4v6mc-framework]
             S. Venaas, X. Li and C. Bao, "Framework for IPv4/IPv6
             Multicast Translation ", draft-venaas-behave-v4v6mc-
             framework, working in progress, October 2009.


Jiang & Gu              Expires July 10, 2011                 [Page 7]


Internet-Draft draft-jiang-behave-v4v6mc-proxy-02.txt    Janauary 2011


Author's Addresses

   Sheng Jiang
   Huawei Technologies Co., Ltd
   Huawei Building, No.3 Xinxi Rd.,
   Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085
   P.R. China
   Email: shengjiang@huawei.com

   Dujuan Gu
   Huawei Technologies Co., Ltd
   156 Bei-Qing Road, Hai-Dian District, Beijing 100085
   P.R. China
   Email: gudujuan@huawei.com


































Jiang & Gu              Expires July 10, 2011                 [Page 8]