One document matched: draft-jiang-behave-v4v6mc-proxy-02.txt
Differences from draft-jiang-behave-v4v6mc-proxy-01.txt
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]| PAFTECH AB 2003-2026 | 2026-04-23 05:42:44 |