[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Operations Area                                              Y. Lee, Ed.
Internet-Draft                                                   Comcast
Intended status: Informational                              V. Kuarsingh
Expires: March 21, 2011                            Rogers Communications
                                                                 G. Yang
                                                           China Telecom
                                                                 G. Chen
                                                            China Mobile
                                                      September 17, 2010

              Problem Statements of IPv6 Transition of ISP


   The IETF has defined a number of technologies and techniques that
   targets the transition from IPv4 to IPv6.  Documented techniques
   identify high level use cases and generalized options for networks.
   Operators may have difficulty attempting to apply the documented
   techniques to their networks since each network and system operates
   uniquely within the global Internet.  Operators may require guidance
   on how to identify the appropriate technology, or technologies, and
   apply them to their specific environments.  This memo describes the
   problem statements related to the transition of operator's networks
   to IPv6.

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 March 21, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Lee, et al.              Expires March 21, 2011                 [Page 1]

Internet-Draft               IPv6 Transition              September 2010

   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.

Table of Contents

   1.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Network Problems . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Address Architecture . . . . . . . . . . . . . . . . . . .  4
     2.2.  Connectivity . . . . . . . . . . . . . . . . . . . . . . .  5
     2.3.  High Availability  . . . . . . . . . . . . . . . . . . . .  6
     2.4.  DNS  . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  CPE Problems . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Application Problems . . . . . . . . . . . . . . . . . . . . .  7
   5.  Network Management and Operation Problems  . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   7.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     10.1. Normative References . . . . . . . . . . . . . . . . . . .  9
     10.2. Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10

Lee, et al.              Expires March 21, 2011                 [Page 2]

Internet-Draft               IPv6 Transition              September 2010

1.  Problem Statement

   IPv4 addresses are a limited resource which are expected to exhaust
   in the near future.  As of the time of this writing, the IANA free
   pool has been reduced to 14 /8 blocks.  The current projection [ref
   to ipv4.potaroo.net] is that IANA will exhaust this pool in less than
   a year, with the RIRs allocating all their remaining blocks in
   January 2012.  IPv6 is the next generation IP protocol which will
   solve the address exhaustion problem.  IPv4 and IPv6 are not
   interoperable and the uptake of IPv6 in client and server nodes will
   be gradual.  An ISP will need to take steps to ensure service
   continuity and transparency to the customers at all times during
   transition and coexistence.

   It is very important that the transition to IPv6 is stable and non-
   interruptive to existing services.  It is critical to operators to
   have a clear picture of how they will transition to IPv6.  As we are
   approaching to the initial phase of the transition, operators must
   understand the risks and challenges ahead of time before they start
   the transition.  Each operator should have a list of items (s)he
   should find the answers to.  This item list is different from
   operator to operator.  Some may focus more on IPv6 green field
   design, some may focus on IPv4 and IPv6 coexistence, some may focus
   more on IPv4 constrained network environments.  Many operators are
   seeking advices, guidelines and common practices to address their
   needs and begin the transition process.
   [I-D.arkko-ipv6-transition-guidelines] is a good summary of the
   existing transition technologies and techniques.  It covers general
   guidelines of transitioning.  The next step would be detailed
   guidelines for specific use case and network scenario.

   The IETF has been developing tools for transiting to IPv6 for more
   than a decade.  However, many operators have yet to begin
   transitioning.  One possible reason is that operators face lags in
   the IPv6 development in applications, hosts, CPEs, network equipment
   and contents.  Another possible reason is that operators didn't know
   how to apply the technologies and techniques in their networks
   without causing service interruption.  Even IPv4 address is projected
   to be depleted in couple years, the IPv6 adoption rate is still far
   from desire.  The IETF v6ops working group successfully addresses
   many individual IPv6 operation issues.  In the transition phase,
   operators are seeking detailed guidelines that provide "howto"
   information for the transition.  Operators would like these
   guidelines produced by IETF since IETF invented IPv6 and continues
   improving it.  The v4v6trans work items target to produce these
   guidelines to assist the operators to start the transition.

   Numbers of RFC have been published to describe mechanisms for IPv6

Lee, et al.              Expires March 21, 2011                 [Page 3]

Internet-Draft               IPv6 Transition              September 2010

   deployment, but not every RFC addresses the operation concerns.  For
   example: [RFC4213] suggests to use tunnel to connect IPv4 islands
   over an IPv6 core network.  [RFC5565] describes the protocol to
   exchange the tunnel endpoint information.  One requirement of
   [RFC5565] is that the operator must build a full mesh to interconnect
   all the IPv4 islands.  This may cause some scaling issue.  Operators
   would like to have some guidelines and best practice to assess a
   transition technique.

   There exists RFCs that describes some transition mechanisms.  For
   example: [RFC4213] provides good mechanisms to transition to hosts
   and routes to IPv6.  But it doesn't address the new transition
   techniques such as 6rd, NAT444, NAT64, DS-lite, etc.  Also, there is
   no existing memo to give tactical and strategic analyzes of these
   techniques.  For example: NAT64 requires much consideration of ALG
   but no specific requirements to IPv6 CPE.  Another example: No
   exiting memo has discussed how multiple transition technologies fit
   together in a given network scenario.

   This memo attempts to describe the common problems and concerns which
   may hinder an operator from building an IPv6 transition plan and/or
   executing it.  The memo attempts to call out the key challenges faced
   by the providers which will require separate drafts to outline the
   guidance to the questions and challenges raised.

   We separate the transition problem into four areas: Network,
   Connectivity, Applications, and Network Management and Operation.
   Each area has its own challenges and problems.  IETF may have already
   published answers for individual problems.  But it is lack of
   collective effort that presents scenarios and recommendations for the
   transition.  In the transition phase, these guidelines and framework
   documents are useful for operators to prioritize timelines to address
   the transition problems.

2.  Network Problems

2.1.  Address Architecture

   IPv6 by nature is a much larger address space when compared to IPv4.
   IPv6 is intended to maintain a strong hierarchy and the address space
   allows for many new use cases for address assignments to customers
   and networks.  Due to the shear size of the IPv6 address space,
   special attention is required when designing the IPv6 network since
   it will differ from the fragmented and smaller IPv4 address design.
   Operators will need to plan in advance for IPv6 since, unlike the
   IPv4 counterpart, will provide them with an enormous address space
   which requires careful architectural consideration.  Some basic

Lee, et al.              Expires March 21, 2011                 [Page 4]

Internet-Draft               IPv6 Transition              September 2010

   questions a operator may ask include:

   o  How to decide the IPv6 address architecture in the network?

   o  What is the recommended prefix length for a large operator?

   o  What is the recommended prefix length for a medium operator?

   o  What is the recommended prefix length to hand out to customers?

   o  What is the recommended longest prefix length an operator should
      accept from customers?

   o  If privacy is a concern and an operator wants to use ULA in the
      network, what are the guidelines?

2.2.  Connectivity

   When an operator starts transitioning to IPv6, the engineers must
   design a network to offer service continuity to customers.  Native
   dual-stack is the natural approach.  However, due to IPv4 address
   exhaustion and cost associated to operate dual-stack network,
   operators may consider to upgrade part of their network to IPv6-only.
   They want to know the techniques and guidelines.  Some basic
   questions a operator may ask include:

   o  What techniques should be applied when multiple transition
      techniques are available?

   o  What is the matrix of the different transition techniques to the
      network and applications?

   o  How to deploy an IPv4 access network over an IPv6 core network?

   o  How to deploy an IPv6 access network over an IPv4 core network?

   o  Under what considerations, IS-IS should be used?

   o  Under what considerations, OSPFv3 should be used?

   o  What is the longest prefix to be allowed for peering?

   o  How to support traffic engineering and QoS in tunneling

Lee, et al.              Expires March 21, 2011                 [Page 5]

Internet-Draft               IPv6 Transition              September 2010

2.3.  High Availability

   High Availability (HA) is a major requirement for every service and
   network service.  Operators have accumulated tremendous experience of
   operating HA in IPv4 using mature protocols such as VRRP and OSPF
   Graceful Restart.  Compared to IPv4, HA for IPv6 is less known.
   During transitioning, an application running on IPv6 may need to
   failover to IPv4 network due to network failure.  New work may need
   to be done in this area.  In addition, the new transition techniques
   require new HA models.  Operators will normally deploy a transition
   technique if HA is supported.  Some basic questions a operator may
   ask include:

   1.  What are the requirements for deploying HA in IPv6?

   2.  What are the available techniques available for IPv6?

   3.  How to failover an application from IPv6 to IPv4 (or vice versa)?

   4.  What is the HA architecture for the new transition techniques
       such as NAT444, NAT64, DS-lite, etc.

2.4.  DNS

   Despite the similarity of DNS operation in IPv4 and IPv6, there are
   some substantial differences.  Most widely discussed is the usage of
   Reverse DNS in IPv6 [I-D.howard-isp-ip6rdns].  Many applications such
   as some email server implementations rely on Reverse DNS to operate
   probably.  Operators must find an answer to manage Reverse DNS in
   IPv6.  Some basic questions a operator may ask include:

   1.  How to support Reverse DNS in IPv6?

   2.  How to use DDNS to manage customer's IPv6 CPEs?

   3.  How to avoid unnecessary DNS translation in NAT64 scenario?

3.  CPE Problems

   CPE provisioning is very important for operators. operators must
   provide a manageable and reliable provisioning mechanism to provision
   IPv6 service to the customers.  In the IPv4 world, most customers are
   given a public address via DHCP or IPCP.  Customer home network is
   manage by a CPE and uses private address space in the home network.
   In the IPv6 world, things work differently.  Most CPEs are still
   given an IPv6 address.  However, the home network is given an IPv6
   prefix and all the hosts behind the CPE can have public IPv6 address.

Lee, et al.              Expires March 21, 2011                 [Page 6]

Internet-Draft               IPv6 Transition              September 2010

   This changes the existing CPE provisioning model.  Some basic
   questions a operator may ask include:

   o  What provisioning mechanism should be used.  DHCP or Auto-
      configuration, or mix of two?

   o  What is the recommended length for customer prefix?

   o  How to inject the customer's PD to the access router?

   o  Should the prefix be stable?

   o  How does the home CPE manage the prefix?

   o  What is the basic model for home security?

   o  Some legacy OS don't support PPPoEv6.  What other alternatives to
      provision these devices?

   o  How to support the legacy CPEs while transitioning to IPv6?

4.  Application Problems

   During transitioning, IPv4 and IPv6 applications will coexist in the
   network.  Regardless to what technology or multiple technologies an
   operator choose to use, the operator must provide service continuity.
   These are some common questions:

   o  What is the best way to give IPv4 access to the IPv4 applications
      over an IPv6 access and/or core network?

   o  What is the best way to enable an IPv6-only application to
      communicate to an IPv4 application?

   o  What are the impacts of NAT444 and NAT64 to applications?

   o  How to support Single Sign-On which relies on IPv4 address in a
      shared address environment in the operator's network?

   o  When multiple translation techniques are available, how the
      network communicates to the applications to choose the best

Lee, et al.              Expires March 21, 2011                 [Page 7]

Internet-Draft               IPv6 Transition              September 2010

5.  Network Management and Operation Problems

   In theory, managing an IPv6 network should be similar to managing an
   IPv4 network.  For example: SNMP works over IPv6 without
   modification.  During transition, new technologies and techniques may
   be introduced to the network.  These new technologies and techniques
   require new operation models.  Some basic questions a operator may
   ask include:

   o  What is the most effective mechanism to log NAT binding in shared
      address environment?

   o  How to scale these techniques?

   o  What is the IP sharing ratio for IPv4 address to customers?

   o  How does address sharing mechanism impact enterprise customers?

   o  How to enable an IPv6 application to communicate to a legacy IPv4

6.  Security Considerations

   Security is always important and must be addressed.  Some basic
   questions a operator may ask include:

   o  What are the minimal requirements for IPv6 security?

   o  What are the additional security risks with IPv6 compared to IPv4?

   o  What IPv4 risks do not apply to IPv6?

   o  What are the known issues with existing security solutions when
      applied to IPv6?

   o  What is involved in configuring IPv6 security?

7.  Conclusion

   Many operators either started or will start the transition this year
   and next year.  This memo presents some high-level questions which
   operators encounter during the early phase of the transition.  Some
   problems are business oriented and may not be answered by the IETF.
   But this memo explains why operators seek guidelines from the IETF
   and want to apply them to their use cases and network scenarios.  The
   goal of these guidelines will serve as "howto" to the transition

Lee, et al.              Expires March 21, 2011                 [Page 8]

Internet-Draft               IPv6 Transition              September 2010

   process.  The guidelines should also consider and discuss time
   sequence and steps during transitioning.
   [I-D.ietf-v6ops-incremental-cgn] is a good example to provide
   transition steps for CGN deployment.  The next 18 months are critical
   for the transition because IPv4 addresses may be exhausted in 18
   months.  We would like to recommend the IETF to dedicate resources in
   next few months to:

   1.  Generate individual use cases that describes the network

   2.  Generate guidelines of each use case/network scenario that
       explain the procedures to transition to IPv6.

   With this work effort, operators will have authoritative references
   to design the transition process most fit to their services, networks
   and operations.

8.  Acknowledgements

   The editor gathered the information from various individuals and
   presented it in this memo.  All the credits of this memo go to the
   following contributors: Can-Can Huang, Ed Jankiewicz, Tina Tsou,
   Cathy Zhou, Sheng Jiang, Brian Carpenter, Remi Despres, and Seiichi

9.  IANA Considerations

   This memo includes no request to IANA.

10.  References

10.1.  Normative References

              Arkko, J. and F. Baker, "Guidelines for Using IPv6
              Transition Mechanisms during IPv6 Deployment",
              draft-arkko-ipv6-transition-guidelines-06 (work in
              progress), August 2010.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Lee, et al.              Expires March 21, 2011                 [Page 9]

Internet-Draft               IPv6 Transition              September 2010

10.2.  Informative References

              Howard, L. and A. Durand, "Reverse DNS in IPv6 for
              Internet Service Providers", draft-howard-isp-ip6rdns-04
              (work in progress), September 2010.

              Jiang, S., Guo, D., and B. Carpenter, "An Incremental
              Carrier-Grade NAT (CGN) for IPv6 Transition",
              draft-ietf-v6ops-incremental-cgn-01 (work in progress),
              June 2010.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3769]  Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix
              Delegation", RFC 3769, June 2004.

   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
              for IPv6 Hosts and Routers", RFC 4213, October 2005.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC5565]  Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
              Framework", RFC 5565, June 2009.

Authors' Addresses

   Yiu L. Lee (editor)
   One Comcast Center
   Philadelphia, PA  19103

   Email: yiu_lee@cable.comcast.com
   URI:   http://www.comcast.com

Lee, et al.              Expires March 21, 2011                [Page 10]

Internet-Draft               IPv6 Transition              September 2010

   Victor Kuarsingh
   Rogers Communications
   8200 Dixie Road
   Brampton, Ontario  L6T 0C1

   Email: victor.kuarsingh@rci.rogers.com
   URI:   http://www.rogers.com

   Guoliang Yang
   China Telecom
   109 Zhong San Da Dao Xi
   Guangzhou  510630
   P.R. China

   Email: yanggl@gsta.com
   URI:   http://www.gsta.com

   Gang Chen
   China Mobile
   53A Xibianmennei Avenue
   Beijing  100053
   P.R. China

   Email: chengang@chinamobile.com
   URI:   http://www.chinamobile.com

Lee, et al.              Expires March 21, 2011                [Page 11]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/