V6OPS Work Group S. Jiang
Internet Draft D. Gu
Intended status: Standard Stack Huawei Technologies Co., Ltd
Expires: August 27, 2010 March 1, 2010
Multicast Proxy in IPv6/IPv4 Transition
draft-jiang-behave-v4v6mc-proxy-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 27, 2010.
Copyright Notice
Copyright (c) 2010 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 BSD License.
Jiang & Gu Expires August 27, 2010 [Page 1]
Internet-Draft draft-jiang-behave-v4v6mc-proxy-00.txt March 2010
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 multicast translation mechanism, this document describes
a multicast proxy solution. The multicast proxy is deployed at the
border of IPv6/IPv4 networks. It acts as a multicast leaf in the
network that the data source locates. It also acts as a multicast
source in other IP network. Without translation, it multicasts the
data retrieved and cached from different IP network.
Table of Contents
1. Introduction................................................3
2. Terminology.................................................3
3. Multicast Proxy without IPv6/IPv4 Translation...............3
3.1. Overview...............................................3
3.2. Operation procedure....................................5
4. Security Considerations.....................................5
5. IANA Considerations.........................................5
6. Change Log [RFC Editor please remove].......................5
7. References..................................................5
7.1. Normative References...................................5
7.2. Informative References.................................6
Author's Addresses.............................................6
Jiang & Gu Expires August 27, 2010 [Page 2]
Internet-Draft draft-jiang-behave-v4v6mc-proxy-00.txt March 2010
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 translation
framework between IPv4/IPv6 multicast services. It describes the
translation operations and intercommunication in network layer to
support a single source send to multiple receivers in different IP
networks.
Besides the multicast translation mechanism, this document describes
a multicast proxy solution, which is conceptually similar to an
application-level gateway.
A multicast proxy can be deployed at the border between IPv4/IPv6
networks. It acts as a multicast leaf in the network that the data
source locates. It also acts as a multicast source in other IP
network. Without translation, it multicasts the data retrieved and
cached from different IP network.
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 IPv6/IPv4 Translation
3.1. Overview
|
<----------IPvX---------->|<---------IPvY----------->
|
+-----------+ +-----------+ +-----------+
| multicast |------>| multicast |------>| multicast |
| source | | proxy | | client |
+-----------+ +-----------+ +-----------+
Jiang & Gu Expires August 27, 2010 [Page 3]
Internet-Draft draft-jiang-behave-v4v6mc-proxy-00.txt March 2010
|
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 is one multicast distribution tree in each sides of
the multicast proxy.
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, in network or IP layer, they are independent from each other.
Conceptually, the multicast proxy can be presented virtually like
below Figure 2.
|
<------------IPvX-------------->|<------------IPvY--------------->
|
+---------+ +----------+ +-----------+ +---------+
|multicast| |multicast | mapping | multicast | |multicast|
| source |---->| proxy |-------->| proxy |---->| client |
| | |(Receiver)| interop |(Publisher)| | |
+---------+ +----------+ +-----------+ +---------+
|
Figure 2: Separate function model of multicast proxy
Jiang & Gu Expires August 27, 2010 [Page 4]
Internet-Draft draft-jiang-behave-v4v6mc-proxy-00.txt March 2010
3.2. Operation procedure
A client, locates in IPvY network, connects to the multicast proxy,
requesting a multicast service whose source locates in IPvX network.
The multicast proxy maintains a multicast service table, including
available multicast services from itself and IPvX network. The
multicast proxy searches the client request in its multicast service
table. If the requested multicast service is from IPvX network, the
multicast proxy connects to the multicast source in IpvX network and
requesting the service on behalf of the client.
When a second client in IPvY network requests the same multicast
service, the multicast proxy can provide the service without any
additional operation.
If all the clients, requesting a certain multicast service in IPvY
network, leave the multicast group in IPvY network, the multicast
proxy MAY leave the multicast group in IPvX network.
Multicast Proxy MAY also perform load-balancing, authentication and
caching 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.
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. Change Log [RFC Editor please remove]
draft-jiang-behave-v4v6mc-proxy-00, original version, 2010-03-01
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.
Jiang & Gu Expires August 27, 2010 [Page 5]
Internet-Draft draft-jiang-behave-v4v6mc-proxy-00.txt March 2010
[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, October 2009.
Author's Addresses
Sheng Jiang
Huawei Technologies Co., Ltd
KuiKe Building, No.9 Xinxi Rd.,
Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085
P.R. China
Phone: 86-10-82836081
Email: shengjiang@huawei.com
Dujuan Gu
Huawei Technologies Co., Ltd
156 Bei-Qing Road, Hai-Dian District, Beijing 100085
P.R. China
Phone: 86-10-59723287
Email: gudujuan@huawei.com
Jiang & Gu Expires August 27, 2010 [Page 6]