Internet DRAFT - draft-xu-v6ops-hybrid-framework


Network Working Group                                           J. Xu 
Internet Draft                                           China Telecom 
Intended status: Informational                               S. Jiang 
Expires: December 26, 2009                Huawei Technologies Co., Ltd 
                                                         B. Carpenter 
                                               University of Auckland 
                                                        June 30, 2009 
      A Hybrid ISP Framework for IPv6 Services and IPv6/IPv4 Inter-

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 

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

   This Internet-Draft will expire on December 26, 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 ( 
   Please review these documents carefully, as they describe your rights 
   and restrictions with respect to this document.

Xu, et al.            Expires December 26, 2009               [Page 1] 
Internet-Draft  draft-xu-v6ops-hybrid-framework-00.txt        June 2009 



   Global IPv6 deployment is expected. Many solutions have been 
   specified in order to provide IPv6 connectivity service. In order to 
   provide IPv6 connectivity service to all kinds of host/client devices, 
   ISP networks may need to support as many as possible IPv6 
   connectivity solutions. This document proposes a hybrid ISP framework 
   that supports the coexistence of various IPv6 connectivity solutions 
   and analyses the configuration requirements raised by this framework. 
   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 Framework...........................5 
   3. APPs/ICPs Involvement........................................6 
   4. Configuration Mechanisms.....................................7 
      4.1. Manual configuration....................................7 
      4.2. DHCPv6.................................................7 
      4.3. Domain Name Service.....................................7 
      4.4. Others.................................................8 
   5. Security Considerations......................................8 
   6. IANA Considerations.........................................8 
   7. References..................................................8 
      7.1. Normative References....................................8 
      7.2. Informative References..................................9 
   Author's Addresses............................................11 

Xu, et al.            Expires December 26, 2009               [Page 2] 
Internet-Draft  draft-xu-v6ops-hybrid-framework-00.txt        June 2009 

1. Introduction 

   Global Internet has grown up rapidly in last 25 years. More and more 
   devices are connected to the global Internet infrastructure. Internet 
   Protocol (version 4 [RFC0791]) played an essential role during the 
   success of the Internet. IPv4 addresses identify the logical 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 are fewer than 4 billion 
   available IPv4 addresses, and the address space is used inefficiently. 
   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. Individual ISPs will experience address shortage at a 
   date depending on their own situation after the RIRs can make no more 

   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 perennial 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 inter-
   communication between IPv4 and IPv6, therefore becomes more critical 
   and complicated for the soon-coming global IPv6 deployment. 

   On the other hand, many solutions have been specified in order to 
   provide IPv6 connectivity service. The most basic is the deployment 
   of dual stack hosts and routers [RFC4213] including the support of 
   configured IPv6-over-IPv4 tunnels. However, the dual stack approach 
   cannot be sufficient once IPv4 addresses have run out, because it 
   does not allow IPv6-only hosts to communicate with IPv4-only hosts.  

   Techniques that extend the dual stack model include 6over4 [RFC2529], 
   6to4 [RFC3056], ISATAP (Intra-Site Automatic Tunnel Addressing 
   Protocol [RFC5214]), and tunnel brokers [RFC3053]. 

   Techniques that address the interworking problem include SIIT 
   (Stateless IP/ICMP Translation Algorithm [RFC2765]) and NAT-PT 
   [RFC2663]. Although NAT-PT has been obsoleted [RFC4966], NAT-PT-like 
   technologies, for example NAT64 [NAT64], are still needed. Other 
   translation techniques include BIS (Dual Stack Hosts using the Bump-
   In-the-Stack Technique [RFC2767]), Transport Replay Translator 
   [RFC3142], BIA (Dual Stack Hosts Using Bump-in-the-API [RFC3338]), 
   and SOCKS 64 Gateway [RFC3089]. Interworking for specific application 
Xu, et al.            Expires December 26, 2009               [Page 3] 
Internet-Draft  draft-xu-v6ops-hybrid-framework-00.txt        June 2009 

   services such as HTTP proxy or SMTP, IMAP and POP3 can also easily be 
   provided by dual stack servers. 

   Each technique has different service scenarios and may need both 
   Internet Service Provider (ISP) networks and host/client devices to 
   support them at the same time. Furthermore, in the expected IPv6 
   global deployment, new issues or different scenarios may occur. 
   Correspondingly, more solutions may be developed to meet some of 
   these requirements in the future. For example, 6RD (IPv6 Rapid 
   Deployment [6RD]), Port Range [PortRange, PRv6], Dual-Stack Lite 
   [DSLite], Incremental CGN [ICGN], and TURN (Traversal Using Relays 
   around NAT [TURN] Extension for IPv6) have been also submitted to the 
   IETF recently. 

   Up to now, there is not one universal mechanism that can meet all 
   IPv6 connectivity service scenarios, including connectivity between 
   IPv6-only and IPv4-only. Table 1 gives a partial summary. Host/client 
   devices may choose to support one or several mechanisms. But 
   host/client devices with various solutions all require IPv6 
   connectivity through ISP network services. In order to provide IPv6 
   connectivity service to different kinds of host/client devices, ISP 
   networks need to support as many IPv6 connectivity solutions as is 
   operationally reasonable. Additionally, all these efforts should be 
   transparent for the average end-user. 

   |               |6o4|6to4| ISA |ST-|STLS|BIS|Trans.|SOCKS|BIA| 
   |               |   |    |-TAP |Trs|-Trs|   |Relay | G/W |   | 
   |Dual Stack Host| X |    |  X  |   |    | X |      |     | X | 
   | Upper Message |   |    |     |   |    |   |   X  |  X  | X | 
   |  Manipulation |   |    |     |   |    |   |      |     |   | 
   |   IP Header   |   |    |     | X |  X | X |      |     |   | 
   |   Translation |   |    |     |   |    |   |      |     |   | 
   |   Tunnelling  | X |  X |  X  |   |    |   |      |  X  |   | 
   |    In Host    | X |    |  X  |   |    | X |   X  |  X  | X | 
   |    In Gate    |   |  X |     | X |    |   |   X  |  X  |   | 

              Table 1: Characters of IPv6 connectivity mechanisms 

Xu, et al.            Expires December 26, 2009               [Page 4] 
Internet-Draft  draft-xu-v6ops-hybrid-framework-00.txt        June 2009 

   In table 1, each column means: 
   6o4 = IPv6 over IPv4 [RFC2529]      6to4 = [RFC3056] 
   ISATAP = Intra-Site Automatic Tunnel Addressing Protocol [RFC5214] 
   ST-Trs = Stateful Translation, such as NAT-PT [RFC2663], NAT64 [NAT64] 
   STLS-Trs = Stateless Translation, such as Stateless IP/ICMP 
              Translation Algorithm [RFC2765] 
   BIS = Dual Stack Hosts using the Bump-In-the-Stack Technique [RFC2767] 
   Trans. Relay = Transport Replay Translator [RFC3142] 
   SOCKS G/W = SOCKS 64 Gateway [RFC3089] 
   BIA = Dual Stack Hosts Using Bump-in-the-API [RFC3338] 

   In table 1, each row means:  
   Dual Stack Host = supporting dual-stack hosts 
   Upper Message Manipulation = modifying application messages 
   IP Header Translation = translating IP header 
   Tunnelling = using Tunnel technology 
   In Host = involving host support 
   In Gate = involving gateway support 

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

2. Overview of A Hybrid ISP Framework 

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

   First, ISPs should deploy required resources for offering IPv6 
   connectivity and IPv6/IPv4 inter-communication solutions in their 
   operational networks. Depending on each solution, the required 
   devices may be located at different network segments. For example, 
   IPv6/IPv4 inter-communication 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 (ALGs) 
   for IPv6/IPv4 inter-communication may be deployed as services by ICP 
   within ISP network too. Each application may have its customized 
   traversal or interworking mechanisms and servers. As noted above, 

Xu, et al.            Expires December 26, 2009               [Page 5] 
Internet-Draft  draft-xu-v6ops-hybrid-framework-00.txt        June 2009 

   this is very straightforward for "relay" applications like mail and 
   HTTP proxy. 

   All information about deployed services, including IP addresses of 
   servers, needs to be collected and distributed to ISP access devices, 
   such as BRAS. Then, this information, include availability 
   information, can be propagated to the host/client devices through 
   standard protocols, which need to be extended, based on existing 
   Dynamic Host Configure Protocol for IPv6 (DHCPv6) [RFC3315], IPv6 
   over PPP [RFC5072], Network Configuration Protocol (NETCONF) 
   [RFC4741], Simple Network Management Protocol (SNMP) [RFC3411] or 
   other protocols. Note that IPv6 autoconfiguration is not powerful 
   enough for this purpose. 

   Based on the availability information received, applications on the 
   host/client devices can choose the IPv6 connectivity services they 
   can use or prefer. 

   The operating system (OS) on the host/client devices may filter/drop 
   some IPv6 connectivity services according to its own capability. The 
   OS should provide a standard IPv6 connectivity invoking interface for 
   the upper layer applications. 

   The hybrid ISP framework provides support for as many as possible 
   different IPv6 connectivity solutions. CPEs and host/client devices 
   may need to be configured or updated to get maximum benefit, but they 
   must all get basic connectivity in a standard way. 

   In order to realise this hybrid ISP framework, there are two 
   technical gaps that need to be filled: 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. APPs/ICPs Involvement 

   This framework assumes applications or ICPs would ideally be aware of 
   IPv4/IPv6 inter-communication; it requests applications or ICPs to 
   choose among the different inter-communication technologies. This 
   seems to be in conflict with the traditional layered network model. 

   However, the reality is that applications/ICPs, particularly peer-to-
   peer applications, have already broken the layered network model so 
   that they can traverse the ubiquitous NAT devices. In the IPv4 
   networks, the existence of NAT breaks the end-to-end transparency. In 
   order to find NATs and traverse them, applications have to understand 
Xu, et al.            Expires December 26, 2009               [Page 6] 
Internet-Draft  draft-xu-v6ops-hybrid-framework-00.txt        June 2009 

   network protocols deeply, invoke or interact with network protocols 
   directly and analyse network behaviours by themselves, since the 
   protocol stack on the end user devices is not aware of NATs. 
   Furthermore, since NAT is not standardized, applications have to 
   handle many different NAT technologies. 

   The scenarios between IPv4-only hosts and IPv6-only hosts are partly 
   similar to above discussed NAT scenarios. Due to the differences, 
   there can not be pure end-to-end transparency between them. Based on 
   this reality, the better way is to standardize IPv4/IPv6 inter-
   communication technologies, also mechanisms which propagate relevant 
   information from networks to end hosts. Then, applications could 
   learn inter-communication information from the protocol stack on the 
   hosts instead of detecting by themselves. This learning process may 
   be through a standard API between network layer and application layer 
   on the hosts. This design actually maintains the traditional layered 
   network model. 

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

4.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. Its 
   operational burden would be too large when there are many users. 
   Furthermore, this mechanism is very exposed to human errors. 

4.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 behaviour must be defined clearly. 

4.3. Domain Name Service 

   For well-known services, certain DNS records may be defined so that 
   host/client devices can resolve their IP addresses through DNS 
   queries using DNS SRV [RFC2782]. For example, 
   can be used to point all ISP1 customers to available NAT-PT servers. 

Xu, et al.            Expires December 26, 2009               [Page 7] 
Internet-Draft  draft-xu-v6ops-hybrid-framework-00.txt        June 2009 

   With a suitable DNS mechanism, client load can be distributed among 
   many available servers. 

4.4. Others 

   According to different access technologies, certain protocols, such 
   as PPPoE or ICMP [RFC0792], may be extended to propagate IPv6 
   connectivity service information to subscribers. Note that router and 
   switch configuration protocols such as NETCONF and SNMP are not 
   considered relevant here. 

5. Security Considerations 

   The security issues for each solution that provides IPv6 connectivity 
   service are discussed in their own specifications. However, further 
   security analysis will be needed to understand whether there are 
   security issues for configuration mechanisms mentioned in this 

6. IANA Considerations 

   This draft does not request any IANA action. 

7. References 

7.1. Normative References 

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

   [RFC0792] J. Postel, "Internet Control Message Protocol", RFC 792, 
             September 1981. 

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

   [RFC2529] B. Carpenter, C. Jung, "Transmission of IPv6 over IPv4 
             Domains without Explicit Tunnels", RFC 2529, March 1999. 

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

   [RFC2782] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for 
             specifying the location of services (DNS SRV)", RFC2782, 
             February 2000. 

   [RFC3053] A. Durand, P. Fasano, I. Guardini, D. Lento, "IPv6 Tunnel 
             Broker", RFC3053, January 2001. 
Xu, et al.            Expires December 26, 2009               [Page 8] 
Internet-Draft  draft-xu-v6ops-hybrid-framework-00.txt        June 2009 

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

   [RFC3411] D. Harrington, R. Presuhn, B. Wijnen, "An Architecture for 
             Describing Simple Network Management Protocol (SNMP) 
             Management Frameworks", RFC 3411, December 2002. 

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

   [RFC4741] R. Enns, et al., "NETCONF Configuration Protocol", RFC 4741, 
             December 2006. 

   [RFC5072] S.Varada, Ed., D. Haskins, E. Allen, "IP Version 6 over 
             PPP", RFC 5072, September 2007. 

7.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, 
Xu, et al.            Expires December 26, 2009               [Page 9] 
Internet-Draft  draft-xu-v6ops-hybrid-framework-00.txt        June 2009 

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

   [PortRange] B. Storer, et al., "IPv4 Connectivity Access in the 
             Context of IPv4 Address Exhaustion", draft-boucadair-port-
             range, work in progress. 

   [PRv6]   M. Boucadair, et al., "Flexible IPv6 Migration Scenarios in 
             the Context of IPv4 Address Shortage", draft-boucadair-
             behave-ipv6-portrange, work in progress. 

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

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

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

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

Xu, et al.            Expires December 26, 2009              [Page 10] 
Internet-Draft  draft-xu-v6ops-hybrid-framework-00.txt        June 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 
   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 
   Brian Carpenter 
   Department of Computer Science 
   University of Auckland 
   PB 92019 
   Auckland, 1142 
   New Zealand 

Xu, et al.            Expires December 26, 2009              [Page 11]