[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Network Working Group                                           J. Xu
Internet Draft                                           China Telecom
Intended status: Informational                               S. Jiang
Expires: October 8, 2009                  Huawei Technologies Co., Ltd
                                                       April 14, 2009

   A Hybrid ISP Platform (or Architecture) for IPv6: Problem Statement
                draft-xu-v6ops-hybrid-platform-ps-00.txt


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-Drafts.

   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
        http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html

   This Internet-Draft will expire on October 12, 2009.

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.










Xu, et al.            Expires October 12, 2009                [Page 1]


Internet-Draft draft-xu-v6ops-hybrid-platform-ps-00.txt      April 2009




Abstract

   Global IPv6 deployment is inevitable. There are many solutions have
   been specified in order to provide IPv6 connectivity services. In
   order to provide IPv6 connectivity services to all kinds of
   host/client devices, ISP networks need to support as many as possible
   IPv6 connectivity solutions. This document proposes a hybrid ISP
   platform that supports the coexistence of variable IPv6 connectivity
   solutions and analyses the configuration requirements raised by this
   platform. Additionally, the applicability of different configuration
   mechanisms for performing this configuration is discussed.

Table of Contents

   1. Introduction................................................3
   2. Overview of A Hybrid ISP Platform.............................4
   3. Configuration Mechanisms.....................................5
      3.1. Manual configuration....................................5
      3.2. DHCPv6.................................................6
      3.3. Domain Name Service.....................................6
      3.4. Others.................................................6
   4. Security Considerations......................................6
   5. IANA Considerations.........................................6
   6. References..................................................6
      6.1. Normative References....................................6
      6.2. Informative References..................................7
   Author's Addresses.............................................8



















Xu, et al.            Expires October 12, 2009                [Page 2]


Internet-Draft draft-xu-v6ops-hybrid-platform-ps-00.txt      April 2009



1. Introduction

   Global Internet has grown up rapidly in last 25 years. More and more
   devices are linked on the Internet. Internet Protocol (version 4
   [RFC791]) plays an important role during the success of the Internet.
   IPv4 addresses identify the logic location of every device in the
   Internet so that data packets can be delivered to the right
   destination. However, giving the fact that the length of IPv4
   addresses is only 32 bits, there is only less that 4 billion
   available IPv4 address. IPv4 address exhaustion is now confirmed to
   happen soon. The dynamically-updated IPv4 Address Report [IPUSAGE]
   has analyzed this issue. It predicts early 2011 for IANA unallocated
   address pool exhaustion and middle 2012 for RIR unallocated address
   pool exhaustion.

   Although there are a number of mechanisms trying to extend the life
   time of IPv4, the transition of the Internet to Internet Protocol
   version 6 [RFC2460] is the only practical and readily available long-
   term solution to IPv4 address exhaustion. The Internet industry
   appears to have reached consensus that global IPv6 deployment is
   inevitable and has to be done quite quickly. IPv4/IPv6 transition,
   including intercommunication between IPv4 and IPv6, therefore becomes
   more critical and complicated for the soon-coming global IPv6
   deployment.

   On another side, there are many solutions have been specified in
   order to provide IPv6 connectivity services, include 6over4 [RFC3056],
   6to4 [RFC3056], ISATAP (Intra-Site Automatic Tunnel Addressing
   Protocol [RFC5214]), NAT-PT [RFC2663] (though NAT-PT has been
   obsoleted [RFC4966], NAT-PT-like technologies, for example NAT64
   [NAT64], are still needed), SIIT (Stateless IP/ICMP Translation
   Algorithm [RFC2765]), BIS (Dual Stack Hosts using the Bump-In-the-
   Stack Technique [RFC2767]), Transport Replay Translator [RFC3142],
   Socks 64 Gateway [RFC3089], BIA (Dual Stack Hosts Using Bump-in-the-
   API [RFC3338]), etc. Each of them has different service scenarios and
   needs both Internet Service Provider (ISP) networks and host/client
   devices to support them at the same time. Furthermore, in the IPv6
   global deployment, more issues or different scenarios may occur.
   Correspondently, more solutions may be developed to meet certain
   requirements in the future. 6RD (IPv6 Rapid Deployment [6RD]), Dual-
   Stack Lite [DSLite] and Incremental CGN [ICGN], TURN (Traversal Using
   Relays around NAT [TURN]) has been submitted to IETF.

   Up to now, there is not AN universal mechanism that can meet all IPv6
   connectivity service scenarios, including connectivity between IPv6-
   only and IPv4-only, see table 1. Host/client devices may choose to


Xu, et al.            Expires October 12, 2009                [Page 3]


Internet-Draft draft-xu-v6ops-hybrid-platform-ps-00.txt      April 2009


   support one or more certain solutions. But host/client devices with
   variable solution all require IPv6 connectivity through ISP network
   services. In order to provide IPv6 connectivity services to all kinds
   of host/client devices, ISP networks need to support as many as
   possible IPv6 connectivity solutions. Additionally beside
   availability, all these efforts should be transparent for end-user.

   +------------------------------------------------------------+
   |               |6o4|6to4| ISA |NAT|SIIT|BIS|Trans.|SOCKS|BIA|
   |               |   |    |-TAP |-PT|    |   |Relay | G/W |   |
   |---------------+---+----+-----+---+----+---+------+-----+---|
   |Dual Stack Host| X |    |  X  |   |    | X |      |     | X |
   |---------------+---+----+-----+---+----+---+------+-----+---|
   | Upper Message |   |    |     |   |    |   |   X  |  X  | X |
   |  Manipulation |   |    |     |   |    |   |      |     |   |
   |---------------+---+----+-----+---+----+---+------+-----+---|
   |   IP Header   |   |    |     | X |  X | X |      |     |   |
   |   Translation |   |    |     |   |    |   |      |     |   |
   |---------------+---+----+-----+---+----+---+------+-----+---|
   |   Tunneling   | X |  X |  X  |   |    |   |      |     |   |
   |---------------+---+----+-----+---+----+---+------+-----+---|
   |    In Host    | X |    |  X  |   |    | X |   X  |  X  | X |
   |---------------+---+----+-----+---+----+---+------+-----+---|
   |    In Gate    |   |  X |     | X |    |   |   X  |  X  |   |
   |---------------+---+----+-----+---+----+---+------+-----+---|
   | Consider APPs.|   |    |     |   |    |   |      |     | X |
   +------------------------------------------------------------+

              Table 1: Characters of IPv6 connectivity mechanisms

   This document proposes a hybrid ISP platform that supports the
   coexistence of multiple IPv6 connectivity solutions and analyses the
   configuration requirements raised by this platform. Additionally, the
   applicability of different configuration mechanisms for performing
   this configuration is discussed.

2. Overview of A Hybrid ISP Platform

   The proposed hybrid ISP platform supports the co-existence of hybrid
   IPv6 connectivity and IPv6/IPv4 intercommunication solutions. It
   encourages that ISPs work together with Internet Content Providers
   (ICPs) to provide IPv6 connectivity and IPv6/IPv4 intercommunication
   services. ISPs provide as much as possible generic support. ICPs can
   design and implement their application specific traverse mechanisms
   utilizing ISP's generic services.




Xu, et al.            Expires October 12, 2009                [Page 4]


Internet-Draft draft-xu-v6ops-hybrid-platform-ps-00.txt      April 2009


   First, ISP deploys required devices for IPv6 connectivity and
   IPv6/IPv4 intercommunication solutions in its ISP networks. Depending
   on each solution, the required devices may be located at different
   positions. For example, IPv6/IPv4 intercommunication devices should
   be placed at the edge between IPv4/IPv6 networks. CGNs may be
   deployed according to the ISP customer aggregation strategy.
   Application-specific gateways for IPv6/IPv4 intercommunication may be
   deployed as services by ICP within ISP network too. Each application
   may have their customized traversal mechanisms and servers.

   All information of deployed services, including IP addresses of
   devices, needs to be collected and distributed to ISP access devices,
   such as BRAS. Through standard protocols, which need to be extended
   based on existing DHCPv6, PPPoEv6 or other protocols, ISP access
   devices propagate the availability information to the host/client
   devices.

   The operation system on the host/client devices may filter IPv6
   connectivity services according to its own supporting status. The OS
   should provide standard IPv6 connectivity invoking interface for the
   upper layer applications, for example, GetSocks64Address, GetNAT-
   PTAddress.

   Based on the availability, applications can choose the IPv6
   connectivity services accordingly.

   This hybrid ISP platform provides the maximum IPv6 connectivity
   support for all different solutions.

   In order to fulfil this hybrid ISP platform, there are two technical
   gaps needs to be supplied: configuration mechanisms in which service
   information could be pushed to the host/client devices; standard IPv6
   connectivity invoking interface on the hosts/client devices. The
   latter is out of scope of this document. The configuration mechanism
   is discussed below.

3. Configuration Mechanisms

   There are a number of configuration mechanisms that could be
   potentially used to propagate IPv6 connectivity service information
   to the host/client devices.

        3.1. Manual configuration

   Manual configuration has already been used in many IPv6 connectivity
   solutions. However, this method requires expert knowledge for at
   least first time configuration. Its scalability is quite poor.


Xu, et al.            Expires October 12, 2009                [Page 5]


Internet-Draft draft-xu-v6ops-hybrid-platform-ps-00.txt      April 2009


   Furthermore, this mechanism is lack of flexibility. For example, the
   connectivity service will become unavailable after a server changes
   its IP address.

        3.2. DHCPv6

   Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] can
   assign addresses statefully. Besides, DHCPv6 can also be used to
   distribute other configuration information. DHCPv6 can be extended to
   propagate IPv6 connectivity service information. A set of new options
   needs to be developed and their interaction behaviour need to be
   defined clearly.

        3.3. Domain Name Service

   For well-known services, certain DNS records may be defined so that
   host/client devices can resolve their IP address through DNS query.
   For example, natpt.chinatelecom.com.cn can be used to point all China
   Telecom customers to available NATPT servers. With intelligence DNS
   mechanism, client requirements can be diverted to a suitable server
   among many available servers.

        3.4. Others

   According to different access technologies, certain protocol, such as
   PPPOE or ICMP may be extended to propagate IPv6 connectivity service
   information.

4. Security Considerations

   The security issues for each solution that provides IPv6 connectivity
   services are out of scope. However, further security analysis will be
   needed to understand whether there are security issues for
   configuration mechanisms mentioned in this document.

5. IANA Considerations

   This draft does not request any IANA action.

6. References

        6.1. Normative References

   [RFC791] J. Postel, "Internet Protocol", RFC 791, September 1981.

   [RFC2460] S. Deering, et al., "Internet Protocol, Version 6 (IPv6)
             Specification", RFC2460, December 1998.


Xu, et al.            Expires October 12, 2009                [Page 6]


Internet-Draft draft-xu-v6ops-hybrid-platform-ps-00.txt      April 2009


   [RFC2765] E. Nordmark, "Stateless IP/ICMP Translation Algorithm (SIIT)
             ", RFC 2765, February 2000.

   [RFC3056] B. Carpenter, K. Moore, "Connection of IPv6 Domains via
             IPv4 Clouds", RFC 3056, February 2001.

   [RFC3315] R. Droms, et al., "Dynamic Host Configure Protocol for
             IPv6", RFC3315, July 2003.

        6.2. Informative References

   [RFC2663] P. Srisuresh and M. Holdrege, "IP Network Address
             Translator (NAT) Terminology and Considerations", RFC 2663,
             August 1999.

   [RFC2767] K. Tsuchiya, et al., "Dual Stack Hosts using the Bump-In-
             the-Stack Technique (BIS)", RFC 2767, February 2000.

   [RFC3089] H. Kitamura, "A SOCKS-based IPv6/IPv4 Gateway Mechanism,
             RFC3089", April 2001.

   [RFC3142] J. Hagino, "An IPv6-to-IPv4 Transport Relay Translator" RFC
             3142, June 2001.

   [RFC3338] S. Lee, et al., "Dual Stack Hosts Using Bump-in-the-API
             (BIA)", RFC 3338 October 2002

   [RFC4966] C. Aoun and E. Davies, "Reasons to Move the Network Address
             Translator - Protocol Translator (NAT-PT) to Historic
             Status", RFC 4966, July 2007.

   [RFC5214] F. Templin, T. Gleeson, and D. Thaler, "Intra-Site
             Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
             March 2008.

   [IPUSAGE] G. Huston, IPv4 Address Report, March 2009,
             http://www.potaroo.net/tools/ipv4/index.html.

   [6RD]    R. Despres, "IPv6 Rapid Deployment on IPv4 infrastructures
             (6rd)", draft-despres-6rd-03.txt, working in progress,
             April 2009.

   [DSLite] A. Durand, et al., "Dual-stack lite broadband deployments
             post IPv4 exhaustion", draft-ietf-softwire-dual-stack-lite-
             00.txt, working in progress, March 2009.




Xu, et al.            Expires October 12, 2009                [Page 7]


Internet-Draft draft-xu-v6ops-hybrid-platform-ps-00.txt      April 2009


   [ICGN]   S. Jiang, et al., "An Incremental Carrier-Grade NAT (CGN)
             for IPv6 Transition" draft-jiang-incremental-cgn-00.txt,
             working in progress, March 2009.

   [NAT64]  M. Bagnulo, et al., "NAT64: Network Address and Protocol
             Translation from IPv6 Clients to IPv4 Servers", draft-
             bagnulo-behave-nat64-03.txt, work in progress, March 2009.

   [TURN]   G. Camarillo and O.Novo, "Traversal Using Relays around NAT
             (TURN) Extension for IPv6", draft-ietf-behave-turn-ipv6-
             06.txt, working in progress, March 2009.

Author's Addresses


   Jianfeng Xu
   China Telecom
   No.109, West Zhongshan Street, Tian-He District, Guangzhou 510630
   P.R. China
   Phone: 86-20-38639112
   EMail: xujf@gsta.com


   Sheng Jiang
   Huawei Technologies Co., Ltd
   KuiKe Building, No.9 Xinxi Rd.,
   Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085
   P.R. China
   Phone: 86-10-82836774
   EMail: shengjiang@huawei.com


















Xu, et al.            Expires October 12, 2009                [Page 8]