[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Internet Engineering Task Force                             T. Tsou, Ed.
Internet-Draft                                  Huawei Technologies(USA)
Intended status: Informational                                 T. Taylor
Expires: September 16, 2011                          Huawei Technologies
                                                          March 15, 2011


       Multicast Transition to IPv6 Only in Broadband Deployments
            draft-tsou-v6ops-multicast-transition-v6only-01

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 various
   dimensions.

   This document is intended to eventually meet the criteria for a
   specification in the series envisioned by the v4-to-v6 transition
   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 16, 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



Tsou & Taylor          Expires September 16, 2011               [Page 1]


Internet-Draft      Multicast Transition To IPv6 Only         March 2011


   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.


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 . . . . . . . . . . . . . . . . . . . . 6
   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 16, 2011               [Page 2]


Internet-Draft      Multicast Transition To IPv6 Only         March 2011


1.  Introduction

   [ID.v4v6tran-framework] defines the required content for a series of
   documents describing how to move from IPv4 to IPv6 for specific
   network scenarios.  The present document is an initial sketch of one
   such document.  Content will be added in later versions to allow it
   to meet the criteria set by [ID.v4v6tran-framework].

   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.

   2.  The access network moves from IPv4 only to dual stack directly,
       and then to IPv6 only.  This path may be preferred by other ISPs.

   3.  The access network is deployed from its beginning as an IPv6 only
       network.




Tsou & Taylor          Expires September 16, 2011               [Page 3]


Internet-Draft      Multicast Transition To IPv6 Only         March 2011


   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.


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



Tsou & Taylor          Expires September 16, 2011               [Page 4]


Internet-Draft      Multicast Transition To IPv6 Only         March 2011


   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.

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.







Tsou & Taylor          Expires September 16, 2011               [Page 5]


Internet-Draft      Multicast Transition To IPv6 Only         March 2011


5.  Security Considerations

   TBD


6.  IANA Considerations

   This document requires no IANA action.


7.  Acknowledgements

   Thanks to Fred Baker for preliminary comments..


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.

   [ID.v4v6tran-framework]
              Carpenter, B., Jiang, S., and V. Kuarsingh, "Framework for
              IP Version Transition Scenarios", February 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.















Tsou & Taylor          Expires September 16, 2011               [Page 6]


Internet-Draft      Multicast Transition To IPv6 Only         March 2011


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


   Tom Taylor
   Huawei Technologies
   1852 Lorraine Ave
   Ottawa, Ontario  K1H 6Z8
   Canada

   Phone:
   Email: tom111.taylor@bell.net































Tsou & Taylor          Expires September 16, 2011               [Page 7]