v6ops Work Group S. Jiang
Internet Draft D. Gu
Intended status: Informational Y. Fu
Expires: April 21, 2013 B. Liu
Huawei Technologies Co., Ltd
October 22, 2012
Multicast Proxy in IPv6/IPv4 Transition
draft-jiang-v6ops-v4v6mc-proxy-02
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 April 21, 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.
Jiang, et al. Expires April 21, 2013 [Page 1]
Internet-Draft draft-jiang-v6ops-v4v6mc-proxy-02 October 2012
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 solution is a
multicast deployment for transition scenario. It does not propose
any new protocol or protocol modification/extension for multicast.
The multicast proxy is deployed at the border of IPv6/IPv4 networks.
It is mainly based on content
cache. Without packet-based translation, it acquires 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 while acting 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. Acknowledgments ............................................. 7
7. References .................................................. 7
7.1. Normative References ................................... 7
7.2. Informative References ................................. 7
Author's Addresses ............................................. 8
Jiang, et al. Expires April 21, 2013 [Page 2]
Internet-Draft draft-jiang-v6ops-v4v6mc-proxy-02 October 2012
1. Introduction
The deployment of IPv6 is now in progress, and users with
no IPv4 access are likely to appear in increasing numbers in the
coming years. 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. It is a multicast deployment for IPv6 transition
scenario. It doesn't propose any new protocol or protocol
modification/extension for multicast.
A multicast proxy can be deployed at the border between IPv4/IPv6
networks. Without packet-based translation, it acquires 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 while acting 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
Jiang, et al. Expires April 21, 2013 [Page 3]
Internet-Draft draft-jiang-v6ops-v4v6mc-proxy-02 October 2012
locates as IPvY network. When IPvX is IPv6, IPvY must be IPv4, vice
versa.
|
<----------IPvX---------->|<---------IPvY----------->
|
+-----------+ +-----------+ +-----------+
| multicast |------>| multicast |------>| multicast |
| source | | proxy | | client |
+-----------+ +-----------+ +-----------+
|
Figure 1: Multicast proxy Forwards 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, et al. Expires April 21, 2013 [Page 4]
Internet-Draft draft-jiang-v6ops-v4v6mc-proxy-02 October 2012
<------------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, et al. Expires April 21, 2013 [Page 5]
Internet-Draft draft-jiang-v6ops-v4v6mc-proxy-02 October 2012
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). After receiving the multicast packets, the proxy
receiver module extracts the contents while dropping all network
layer information, such as IP headers, etc. It then imports the
contents to the content cache & mgt module (6). The content cache &
mgt module then diverts contents to the correspondent channel of 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, et al. Expires April 21, 2013 [Page 6]
Internet-Draft draft-jiang-v6ops-v4v6mc-proxy-02 October 2012
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 for his valuable
comments.
7. References
7.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.
7.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, June 2011.
Jiang, et al. Expires April 21, 2013 [Page 7]
Internet-Draft draft-jiang-v6ops-v4v6mc-proxy-02 October 2012
Author's Addresses
Sheng Jiang
Huawei Technologies Co., Ltd
156 Bei-Qing Road, Hai-Dian District, Beijing 100095
P.R. China
Email: jiangsheng@huawei.com
Dujuan Gu
Huawei Technologies Co., Ltd
156 Bei-Qing Road, Hai-Dian District, Beijing 100095
P.R. China
Email: gudujuan@huawei.com
Yu Fu
Huawei Technologies Co., Ltd
156 Bei-Qing Road, Hai-Dian District, Beijing 100095
P.R. China
Email: eleven.fuyu@huawei.com
Bing Liu
Huawei Technologies Co., Ltd
156 Bei-Qing Road, Hai-Dian District, Beijing 100095
P.R. China
Email: leo.liubing@huawei.com
Jiang, et al. Expires April 21, 2013 [Page 8]