V6OPS                                                       B. Carpenter
Internet-Draft                                         Univ. of Auckland
Intended status: Informational                                  S. Jiang
Expires: April 16, 2010                     Huawei Technologies Co., Ltd
                                                        October 13, 2009

        Emerging Service Provider Scenarios for IPv6 Deployment

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on April 16, 2010.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.


   This document describes scenarios that are emerging among Internet
   Service Providers for the deployment of IPv6.  They are based on

Carpenter & Jiang        Expires April 16, 2010                 [Page 1]

Internet-Draft             ISP IPv6 Scenarios               October 2009

   practical experience so far, as well as current plans and
   requirements, but they are not intended as binding recommendations.
   [[ NOTE: This a preliminary version with incomplete content. ]]

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Review of existing documents  . . . . . . . . . . . . . . . . . 4
   3.  Review of ISP experience, plans and requirements  . . . . . . . 6
   4.  Lessons from experience and planning  . . . . . . . . . . . . . 6
   5.  Suggested scenarios . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Gap analysis  . . . . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   10. Change log  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   11. Informative References  . . . . . . . . . . . . . . . . . . . . 7
   Appendix A.  Questionnaire  . . . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9

Carpenter & Jiang        Expires April 16, 2010                 [Page 2]

Internet-Draft             ISP IPv6 Scenarios               October 2009

1.  Introduction

   [[ NOTE: This a preliminary version with incomplete content.  Later
   sections will be filled out after the authors have obtained feedback
   from various ISPs.  This version is published to clarify our
   intention when approaching ISPs for input. ]]

   As is well known, the approaching exhaustion of IPv4 address space
   will bring about a situation in which Internet Service Providers
   (ISPs) are faced with a choice between three major alternatives:
   1.  Squeeze the use of IPv4 addresses even harder than today, using
       smaller and smaller address blocks per customer, and possibly
       trading address blocks with other ISPs.
   2.  Install multiple layers of network address translation, or share
       IPv4 addresses by other methods such as address-plus-port mapping
       [I-D.ymbk-aplusp], [I-D.boucadair-port-range].
   3.  Deploy IPv6, and operate IPv4-IPv6 coexistence and interworking
   This document focuses on alternative (3), while recognizing that many
   ISPs may be obliged by circumstances to prolong the life of IPv4 by
   using (1) or (2) as well.

   The document is intended as a guide to useful IPv6 deployment
   scenarios.  However, it is not a "cookbook" of operational recipes,
   and the best choice of scenario will depend on the circumstances of
   individual ISPs.

   We consider various aspects of IPv6 deployment: addressing, routing,
   DNS, management and of course IPv4 coexistence and interworking.  We
   do not consider application services in detail, but we do discuss
   general aspects.

   We first review several documents produced in the past by the IETF,
   and mention relevant work in progress in the IETF.  We then survey
   requirements, plans, and practical experience from various ISPs.
   Several deployment scenarios that result from that input are then
   described; these are not formal recommendations, but are intended as
   example scenarios which ISPs may choose to copy or modify to suit
   their own technical, economic and regulatory situation.  We conclude
   with a gap analysis and security considerations.

   The reader is assumed to be familiar with IPv6 in general.  The
   IETF's view of core IPv6 requirements is to be found in [RFC4294]
   (currently being updated as [I-D.ietf-6man-node-req-bis]).  However,
   this does not give a complete view of mechanisms an ISP may need to
   deploy, since it considers the requirements for an individual node,
   not for a network as a whole.

Carpenter & Jiang        Expires April 16, 2010                 [Page 3]

Internet-Draft             ISP IPv6 Scenarios               October 2009

2.  Review of existing documents

   [RFC4029] discusses scenarios for introducing IPv6 into ISP networks,
   as the problem was viewed some years ago.  The document is still
   valuable as a general introduction to the process that an ISP must
   design, but it does not consider today's situation where IPv4
   addresses have in practical terms run out, and interworking between
   IPv6-only and IPv4-only clients and servers must be supported in
   addition to basic dual-stack and tunneling scenarios.  We can extract
   a list of basic issues and needs from RFC4029:
   o  Customer Premises Equipment (CPE) - must support IPv6, or allow
      IPv6-in-IPv4 tunnels.  CPE requirements and security are currently
      being specified by the IETF [I-D.ietf-v6ops-ipv6-cpe-router],
   o  Provider Edge Equipment (PE) - ditto.
   o  ISP backbone (core and border routers, switches if used) - must
      support dual stack, or allow IPv6-in-IPv4 tunnels.  An alternative
      is a newly built IPv6 backbone that allows IPv4-in-IPv6 tunnels.
   o  Network management and monitoring applications must take IPv6 into
   o  Customer management (e.g., RADIUS) mechanisms must be able to
      supply IPv6 prefixes and other information to customers.
   o  Accounting and billing mechanisms must support both versions.
   o  Security mechanisms must support both versions.

   The end goal described in RFC4029 is simply a dual-stack ISP
   backbone.  Today's view is that this is insufficient, as it does not
   allow for interworking between IPv6-only and legacy (IPv4-only)
   hosts.  Indeed, the end goal today might be an IPv6-only ISP
   backbone, with some form of legacy IPv4 support.

   [RFC4779] discusses deployment in broadband access networks such as
   CATV, ADSL and wireless.  [RFC5181] deals specifically with IEEE
   802.16 access networks.  In some access scenarios, the access
   protocol allows separately for IPv4 and IPv6, as for DOCSIS-based
   CATV and for one variant of IEEE 802.16 [RFC5121].  In other
   scenarios, the broadband service is essentially an emulation of raw
   Ethernet, as for Wi-Fi, or for another variant of IEEE 802.16
   [I-D.ietf-16ng-ip-over-ethernet-over-802-dot-16].  Another issue is
   whether the ISP uses MPLS for back-haul from the access network, in
   which case the 6PE [RFC4798] mechanism may be appropriate to carry

   [RFC4942] covers IPv6 security issues, especially those that are
   specific to transition and coexistence scenarios.  The main message
   for ISPs is that the switch to IPv6 does not mean that IP layer
   security issues will go away, and of course security issues that are
   not specific to the IP layer will hardly change.

Carpenter & Jiang        Expires April 16, 2010                 [Page 4]

Internet-Draft             ISP IPv6 Scenarios               October 2009

   Also related to security, [RFC4864] discusses what is referred to as
   "Local Network Protection", i.e., how the internal structure of a
   site network that is not hidden behind a network address translator
   can be protected.  Although not directly relevant to ISP operations,
   this topic does affect the issue of how well an ISP's customers are
   protected after they deploy IPv6.

   [RFC5211] describes an independent view of a possible sequence of
   events for IPv6 adoption in the Internet as a whole, with direct
   implications for ISPs.  Its main point, perhaps, is that by 2012 it
   will be necessary to regard IPv4 networks as the legacy solution.

   Although the basic IPv6 standards have long been stable, it should be
   noted that considerable work continues in the IETF, particularly to
   resolve the issue of highly scalable multihoming support for IPv6
   sites, and to resolve the problem of IP layer interworking between
   IPv6-only and IPv4-only hosts.  Progress continues in various IETF
   working groups that may affect ISP scenarios in due course.
   o  The 6MAN WG maintains the basic IPv6 standards.  This work should
      have little direct effect on ISPs.
   o  The V6OPS WG produces documents of direct interest for operational
      practice as well as security practice.  Current work includes CPE
      requirements, CPE security, and Internet Exchange Point practice.
      The present document will be discussed in V6OPS.
   o  The SOFTWIRE WG is working on additional protocols for IP-in-IP
      tunnels in an ISP context.
   o  The BEHAVE WG is working on specifications for NAT64 and DNS64,
      methods of supporting access from IPv6-only initiators to reach
      IPv4-only services.
   o  The DHC WG maintains and extends DHCPv6.
   o  The SHIM6 WG is finalising work on a host-based protocol for IPv6
      multihoming, based on the usage of multiple IPv6 prefixes for a
      customer connected to multiple ISPs.
   o  The LISP WG is developing experimental standards for a scalable
      tunnel-based routing mechanism which would, if successful, support
      an alternative multihoming model.

   Readers may find the current documents of these WGs via

   The IETF is not currently discussing IPv6/IPv4 interworking at the
   transport or application layers.  The former is not generally
   considered to be a valuable approach.  The latter is considered to be
   handled within the original dual-stack model of IPv6 deployment:
   either one end of an application session will have dual-stack
   connectivity, or a dual-stack intermediary such as an HTTP proxy or
   SMTP server will interface to both IPv4-only and IPv6-only hosts.
   While valid and useful for many common applications, this approach

Carpenter & Jiang        Expires April 16, 2010                 [Page 5]

Internet-Draft             ISP IPv6 Scenarios               October 2009

   does not solve all possible interworking issues.  In any case it does
   not require further standards work at the network layer.

3.  Review of ISP experience, plans and requirements

   [[ NOTE: this section will be filled out when the authors have
   received feedback from various ISPs, by means of a questionnaire. ]]

4.  Lessons from experience and planning

   What was easy, what was difficult, what problems remain.

   [[ NOTE: this section will be filled out after the previous section.

5.  Suggested scenarios

   This document does not make firm recommendations; the circumstances
   of each ISP may be different.  Rather, it describes several suggested
   deployment scenarios that appear, from the analysis above, to have
   the best operational characteristics.  Each ISP should make its own
   choices, according to its own technical, economic and regulatory

   [[ NOTE: this section will be filled out after the previous sections.
   It will also discuss changes since the older analyses discussed in
   Section 2 ]]

6.  Gap analysis

   The analysis has shown a certain number of desirable features to be
   missing, either in relevant specifications, or in many products.
   This section summarizes those gaps.

   [[ NOTE: this section will be filled out after the previous sections.

7.  Security Considerations

   [[ NOTE: this section will be filled out after the previous sections.

Carpenter & Jiang        Expires April 16, 2010                 [Page 6]

Internet-Draft             ISP IPv6 Scenarios               October 2009

8.  IANA Considerations

   This document makes no request of the IANA.

9.  Acknowledgements

   We are grateful to all those ISPs who provided input.  Some of them
   preferred to remain anonymous.  Valuable comments and contributions
   were made by ...

   This document was produced using the xml2rfc tool [RFC2629].

10.  Change log

   draft-carpenter-v6ops-isp-scenarios-00: original version, 2009-10-13

11.  Informative References

              Boucadair, M., Levis, P., Bajko, G., and T. Savolainen,
              "IPv4 Connectivity Access in the Context of IPv4 Address
              Exhaustion: Port  Range based IP Architecture",
              draft-boucadair-port-range-02 (work in progress),
              July 2009.

              Jeon, H., Riegel, M., and S. Jeong, "Transmission of IP
              over Ethernet over IEEE 802.16 Networks",
              draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-12 (work
              in progress), September 2009.

              Loughney, J. and T. Narten, "IPv6 Node Requirements RFC
              4294-bis", draft-ietf-6man-node-req-bis-03 (work in
              progress), July 2009.

              Woodyatt, J., "Recommended Simple Security Capabilities in
              Customer Premises Equipment for  Providing Residential
              IPv6 Internet Service",
              draft-ietf-v6ops-cpe-simple-security-07 (work in
              progress), July 2009.

              Singh, H. and W. Beebee, "IPv6 CPE Router

Carpenter & Jiang        Expires April 16, 2010                 [Page 7]

Internet-Draft             ISP IPv6 Scenarios               October 2009

              Recommendations", draft-ietf-v6ops-ipv6-cpe-router-01
              (work in progress), August 2009.

              Bush, R., "The A+P Approach to the IPv4 Address Shortage",
              draft-ymbk-aplusp-04 (work in progress), July 2009.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC4029]  Lind, M., Ksinant, V., Park, S., Baudot, A., and P.
              Savola, "Scenarios and Analysis for Introducing IPv6 into
              ISP Networks", RFC 4029, March 2005.

   [RFC4294]  Loughney, J., "IPv6 Node Requirements", RFC 4294,
              April 2006.

   [RFC4779]  Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and
              J. Palet, "ISP IPv6 Deployment Scenarios in Broadband
              Access Networks", RFC 4779, January 2007.

   [RFC4798]  De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
              "Connecting IPv6 Islands over IPv4 MPLS Using IPv6
              Provider Edge Routers (6PE)", RFC 4798, February 2007.

   [RFC4864]  Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
              E. Klein, "Local Network Protection for IPv6", RFC 4864,
              May 2007.

   [RFC4942]  Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
              Co-existence Security Considerations", RFC 4942,
              September 2007.

   [RFC5121]  Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
              Madanapalli, "Transmission of IPv6 via the IPv6
              Convergence Sublayer over IEEE 802.16 Networks", RFC 5121,
              February 2008.

   [RFC5181]  Shin, M-K., Han, Y-H., Kim, S-E., and D. Premec, "IPv6
              Deployment Scenarios in 802.16 Networks", RFC 5181,
              May 2008.

   [RFC5211]  Curran, J., "An Internet Transition Plan", RFC 5211,
              July 2008.

Carpenter & Jiang        Expires April 16, 2010                 [Page 8]

Internet-Draft             ISP IPv6 Scenarios               October 2009

Appendix A.  Questionnaire

   This appendix reproduces a questionnaire that was made available for
   ISPs to express their requirements, plans and experience.


Authors' Addresses

   Brian Carpenter
   Department of Computer Science
   University of Auckland
   PB 92019
   Auckland,   1142
   New Zealand

   Email: brian.e.carpenter@gmail.com

   Sheng Jiang
   Huawei Technologies Co., Ltd
   KuiKe Building, No.9 Xinxi Rd.,
   Shang-Di Information Industry Base, Hai-Dian District, Beijing
   P.R. China

   Email: shengjiang@huawei.com

Carpenter & Jiang        Expires April 16, 2010                 [Page 9]