Internet Engineering Task Force T. Tsou, Ed.
Internet-Draft Huawei Technologies(USA)
Intended status: Informational T. Taylor
Expires: September 8, 2011 Huawei Technologies
March 7, 2011
Multicast Transition to IPv6 Only in Broadband Deployments
draft-tsou-v6ops-multicast-transition-v6only-00
Abstract
This document proposes a multicast transition solution from the old
IPv4 only network to the IPv6 only network. It enumerates the
transition steps and then analyzes the transition cost in the light
of this framework.
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 September 8, 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.
Tsou & Taylor Expires September 8, 2011 [Page 1]
Internet-Draft Multicast Transition To IPv6 Only March 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Transition Steps . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. The Old IPv4 Only Multicast Network . . . . . . . . . . . . 4
3.2. First Upgrade . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Second Upgrade, Dropping IPv4 . . . . . . . . . . . . . . . 4
3.4. The Pure IPv6 Multicast Network . . . . . . . . . . . . . . 5
4. Analysis of the Multicast Transition Cost . . . . . . . . . . . 5
4.1. IPTV Source Server . . . . . . . . . . . . . . . . . . . . 5
4.2. Bandwidth Consumed By Multicast . . . . . . . . . . . . . . 5
4.3. Border Devices . . . . . . . . . . . . . . . . . . . . . . 5
4.4. IPTV Terminal . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Informative References . . . . . . . . . . . . . . . . . . 6
8.2. Normative References . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Tsou & Taylor Expires September 8, 2011 [Page 2]
Internet-Draft Multicast Transition To IPv6 Only March 2011
1. Introduction
The handling of unicast during the transition from IPv4 to IPv6 is
the focus of a considerable amount of activity within the BEHAVE and
SOFTWIRES Working Groups, which have worked on tools such as NAT64,
6rd, and DS Lite. At the same time, even though some ISPs have
chosen 6rd or dual stack as their unicast transition solution, they
want to keep their IPv4 only multicast system unchanged as long as
possible, simply because they have enough IPv4 multicast address.
While IPv4 unicast addresses will soon be exhausted, ISPs have no
motivation to update multicast until the day when there are few IPv4
unicast users, it is near the point where the IPv4 stack in network
equipment can be turned off, and the update of the network to IPv6
only is nearly complete.
This document discusses a multicast transition model to keep the old
IPv4 only multicast service while 6rd or dual stack is deployed for
unicast transition, and then to migrate the IPv4 only multicast
system to an IPv6 only multicast system "directly".
1.1. Requirements Language
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 RFC 2119 [RFC2119].
2. Scope
The multicast framework proposed here corresponds to some unicast
transition scenarios in the SOFTWIRES Working Group as follows:
1. The access network moves from IPv4 only to 6rd [RFC5969] and then
to dual stack and finally to IPv6 only. This path may be
preferred by some ISPs in North America and Europe.
2. The access network moves from IPv4 only to dual stack directly,
and then to IPv6 only. This path may be preferred by some ISPs
in China.
3. The access network is deployed from its beginning as an IPv6 only
network.
This document considers unicast transition Scenarios 1 and 2.
Scenario 3 is not considered in this draft because DS-Lite is good as
its unicast solution and [ID.qin-dslite-multicast] is good as its
multicast solution.
Tsou & Taylor Expires September 8, 2011 [Page 3]
Internet-Draft Multicast Transition To IPv6 Only March 2011
3. Transition Steps
The multicast transition solution has four steps as described below.
3.1. The Old IPv4 Only Multicast Network
In this stage, both unicast and multicast services are based on an
IPv4 only network.
3.2. First Upgrade
In this stage, the user IPTV terminal is either IPv4 only or has been
upgraded to dual stack. The network is now dual stack. Multicast
sources continue to be IPv4.
The IPv4 core network is changed to dual stack to support more and
more use of IPv6 unicast, but not multicast in this stage. In a
variation, some ISPs may choose to start with 6rd and then move to
dual stack as their unicast transition solution. The corresponding
multicast solution in that scenario is the same as for a direct move
to dual stack.
In this stage, new dual stack IPTV terminals may be deployed only for
compatibility with the future IPv6 only network.
This stage may exist in more than 15 years. At the end of the stage,
IPv4 unicast traffic may only take up at most 10% of the total
bandwidth.
Moreover, at the end of this stage, the IPv4 source servers should be
updated to dual stack. The IPv6 stack is operated only for testing,
just make sure it will work well in the next stage when the day comes
that the ISP decides to turn off the IPv4 stack in all equipment in
its network.
3.3. Second Upgrade, Dropping IPv4
In this stage the user terminal is either the dual stack device
introduced in the previous stage or a new IPv6 only IPTV Terminal.
The network and the IPTV source are both IPv6 only.
This stage begins when the ISP finds that the IPv4 unicast traffic in
its network is insignificant and decides to turn of all IPv4 stacks
in all of its network devices. At that point the IPv4 only IPTV
terminal will be useless, and the IPv4 stack of the source servers
will be turned off, too.
Tsou & Taylor Expires September 8, 2011 [Page 4]
Internet-Draft Multicast Transition To IPv6 Only March 2011
3.4. The Pure IPv6 Multicast Network
In the final stage, the old dual stack IPTV terminals disappear. The
network is purely IPv6.
4. Analysis of the Multicast Transition Cost
4.1. IPTV Source Server
The IPv4 IPTV source servers may operate for more than 15 years, so
that the ISP investment in the old IPv4 IPTV system is well
protected. Only at the end of stage 2 (Section 3.2) must the ISP add
the IPv6 stack to the source server for testing in preparation for
stage 3.
4.2. Bandwidth Consumed By Multicast
Because the production servers are always running just one IP
version, bandwidth consumption for multicast is not affected by the
transition. The only exception is at the end of the second stage,
when the servers are upgraded to dual stack. Stray customer IPv6
traffic could boost bandwidth, but this can be prevented by proper
filtering to allow IPv6 access only to test traffic for the moment.
4.3. Border Devices
The suggested evolution path avoids the need to deploy the NAT64
function in border routers, such as the Border Relay in 6rd unicast
deployment. NAT64 can seriously degrade performance.
4.4. IPTV Terminal
The suggested evolution path requires an upgrade to IPTV terminals
over a period in the order of 15 years, from IPv4 to dual stack.
Later, the IPv4 stack in these terminals has to be turned off. In
the long run they will be replaced by IPv6 terminals. The time
frames involved are probably longer than the working life of an
individual terminal, so that no extra investment is involved.
5. Security Considerations
TBD
Tsou & Taylor Expires September 8, 2011 [Page 5]
Internet-Draft Multicast Transition To IPv6 Only March 2011
6. IANA Considerations
This document requires no IANA action.
7. Acknowledgements
To be completed.
8. References
8.1. Informative References
[ID.qin-dslite-multicast]
Wang, Q., Qin, J., Sun, P., Boucadair, M., Jacquenet, C.,
and Y. Lee, "Multicast Extensions to DS-Lite Technique in
Broadband Deployments (Work in progress)", January 2011.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010.
8.2. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Tina Tsou (editor)
Huawei Technologies(USA)
2330 Central Expresswayt
Santa Clara, CA 95050
USA
Phone: +1 408 330 4424
Email: tena@huawei.com
Tsou & Taylor Expires September 8, 2011 [Page 6]
Internet-Draft Multicast Transition To IPv6 Only March 2011
Tom Taylor
Huawei Technologies
1852 Lorraine Ave
Ottawa, Ontario K1H 6Z8
Canada
Phone:
Email: tom111.taylor@bell.net
Tsou & Taylor Expires September 8, 2011 [Page 7]