Internet DRAFT - draft-xu-v6ops-hybrid-platform-ps

draft-xu-v6ops-hybrid-platform-ps



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]