idnits 2.17.00 (12 Aug 2021) /tmp/idnits14198/draft-xu-v6ops-hybrid-platform-ps-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 14, 2009) is 4778 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 2767 (Obsoleted by RFC 6535) -- Obsolete informational reference (is this intentional?): RFC 3338 (Obsoleted by RFC 6535) == Outdated reference: draft-despres-6rd has been published as RFC 5569 == Outdated reference: draft-ietf-softwire-dual-stack-lite has been published as RFC 6333 == Outdated reference: draft-ietf-behave-turn-ipv6 has been published as RFC 6156 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Xu 2 Internet Draft China Telecom 3 Intended status: Informational S. Jiang 4 Expires: October 8, 2009 Huawei Technologies Co., Ltd 5 April 14, 2009 7 A Hybrid ISP Platform (or Architecture) for IPv6: Problem Statement 8 draft-xu-v6ops-hybrid-platform-ps-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on October 12, 2009. 32 Copyright Notice 34 Copyright (c) 2009 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents in effect on the date of 39 publication of this document (http://trustee.ietf.org/license-info). 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. 43 Abstract 45 Global IPv6 deployment is inevitable. There are many solutions have 46 been specified in order to provide IPv6 connectivity services. In 47 order to provide IPv6 connectivity services to all kinds of 48 host/client devices, ISP networks need to support as many as possible 49 IPv6 connectivity solutions. This document proposes a hybrid ISP 50 platform that supports the coexistence of variable IPv6 connectivity 51 solutions and analyses the configuration requirements raised by this 52 platform. Additionally, the applicability of different configuration 53 mechanisms for performing this configuration is discussed. 55 Table of Contents 57 1. Introduction................................................3 58 2. Overview of A Hybrid ISP Platform.............................4 59 3. Configuration Mechanisms.....................................5 60 3.1. Manual configuration....................................5 61 3.2. DHCPv6.................................................6 62 3.3. Domain Name Service.....................................6 63 3.4. Others.................................................6 64 4. Security Considerations......................................6 65 5. IANA Considerations.........................................6 66 6. References..................................................6 67 6.1. Normative References....................................6 68 6.2. Informative References..................................7 69 Author's Addresses.............................................8 71 1. Introduction 73 Global Internet has grown up rapidly in last 25 years. More and more 74 devices are linked on the Internet. Internet Protocol (version 4 75 [RFC791]) plays an important role during the success of the Internet. 76 IPv4 addresses identify the logic location of every device in the 77 Internet so that data packets can be delivered to the right 78 destination. However, giving the fact that the length of IPv4 79 addresses is only 32 bits, there is only less that 4 billion 80 available IPv4 address. IPv4 address exhaustion is now confirmed to 81 happen soon. The dynamically-updated IPv4 Address Report [IPUSAGE] 82 has analyzed this issue. It predicts early 2011 for IANA unallocated 83 address pool exhaustion and middle 2012 for RIR unallocated address 84 pool exhaustion. 86 Although there are a number of mechanisms trying to extend the life 87 time of IPv4, the transition of the Internet to Internet Protocol 88 version 6 [RFC2460] is the only practical and readily available long- 89 term solution to IPv4 address exhaustion. The Internet industry 90 appears to have reached consensus that global IPv6 deployment is 91 inevitable and has to be done quite quickly. IPv4/IPv6 transition, 92 including intercommunication between IPv4 and IPv6, therefore becomes 93 more critical and complicated for the soon-coming global IPv6 94 deployment. 96 On another side, there are many solutions have been specified in 97 order to provide IPv6 connectivity services, include 6over4 [RFC3056], 98 6to4 [RFC3056], ISATAP (Intra-Site Automatic Tunnel Addressing 99 Protocol [RFC5214]), NAT-PT [RFC2663] (though NAT-PT has been 100 obsoleted [RFC4966], NAT-PT-like technologies, for example NAT64 101 [NAT64], are still needed), SIIT (Stateless IP/ICMP Translation 102 Algorithm [RFC2765]), BIS (Dual Stack Hosts using the Bump-In-the- 103 Stack Technique [RFC2767]), Transport Replay Translator [RFC3142], 104 Socks 64 Gateway [RFC3089], BIA (Dual Stack Hosts Using Bump-in-the- 105 API [RFC3338]), etc. Each of them has different service scenarios and 106 needs both Internet Service Provider (ISP) networks and host/client 107 devices to support them at the same time. Furthermore, in the IPv6 108 global deployment, more issues or different scenarios may occur. 109 Correspondently, more solutions may be developed to meet certain 110 requirements in the future. 6RD (IPv6 Rapid Deployment [6RD]), Dual- 111 Stack Lite [DSLite] and Incremental CGN [ICGN], TURN (Traversal Using 112 Relays around NAT [TURN]) has been submitted to IETF. 114 Up to now, there is not AN universal mechanism that can meet all IPv6 115 connectivity service scenarios, including connectivity between IPv6- 116 only and IPv4-only, see table 1. Host/client devices may choose to 117 support one or more certain solutions. But host/client devices with 118 variable solution all require IPv6 connectivity through ISP network 119 services. In order to provide IPv6 connectivity services to all kinds 120 of host/client devices, ISP networks need to support as many as 121 possible IPv6 connectivity solutions. Additionally beside 122 availability, all these efforts should be transparent for end-user. 124 +------------------------------------------------------------+ 125 | |6o4|6to4| ISA |NAT|SIIT|BIS|Trans.|SOCKS|BIA| 126 | | | |-TAP |-PT| | |Relay | G/W | | 127 |---------------+---+----+-----+---+----+---+------+-----+---| 128 |Dual Stack Host| X | | X | | | X | | | X | 129 |---------------+---+----+-----+---+----+---+------+-----+---| 130 | Upper Message | | | | | | | X | X | X | 131 | Manipulation | | | | | | | | | | 132 |---------------+---+----+-----+---+----+---+------+-----+---| 133 | IP Header | | | | X | X | X | | | | 134 | Translation | | | | | | | | | | 135 |---------------+---+----+-----+---+----+---+------+-----+---| 136 | Tunneling | X | X | X | | | | | | | 137 |---------------+---+----+-----+---+----+---+------+-----+---| 138 | In Host | X | | X | | | X | X | X | X | 139 |---------------+---+----+-----+---+----+---+------+-----+---| 140 | In Gate | | X | | X | | | X | X | | 141 |---------------+---+----+-----+---+----+---+------+-----+---| 142 | Consider APPs.| | | | | | | | | X | 143 +------------------------------------------------------------+ 145 Table 1: Characters of IPv6 connectivity mechanisms 147 This document proposes a hybrid ISP platform that supports the 148 coexistence of multiple IPv6 connectivity solutions and analyses the 149 configuration requirements raised by this platform. Additionally, the 150 applicability of different configuration mechanisms for performing 151 this configuration is discussed. 153 2. Overview of A Hybrid ISP Platform 155 The proposed hybrid ISP platform supports the co-existence of hybrid 156 IPv6 connectivity and IPv6/IPv4 intercommunication solutions. It 157 encourages that ISPs work together with Internet Content Providers 158 (ICPs) to provide IPv6 connectivity and IPv6/IPv4 intercommunication 159 services. ISPs provide as much as possible generic support. ICPs can 160 design and implement their application specific traverse mechanisms 161 utilizing ISP's generic services. 163 First, ISP deploys required devices for IPv6 connectivity and 164 IPv6/IPv4 intercommunication solutions in its ISP networks. Depending 165 on each solution, the required devices may be located at different 166 positions. For example, IPv6/IPv4 intercommunication devices should 167 be placed at the edge between IPv4/IPv6 networks. CGNs may be 168 deployed according to the ISP customer aggregation strategy. 169 Application-specific gateways for IPv6/IPv4 intercommunication may be 170 deployed as services by ICP within ISP network too. Each application 171 may have their customized traversal mechanisms and servers. 173 All information of deployed services, including IP addresses of 174 devices, needs to be collected and distributed to ISP access devices, 175 such as BRAS. Through standard protocols, which need to be extended 176 based on existing DHCPv6, PPPoEv6 or other protocols, ISP access 177 devices propagate the availability information to the host/client 178 devices. 180 The operation system on the host/client devices may filter IPv6 181 connectivity services according to its own supporting status. The OS 182 should provide standard IPv6 connectivity invoking interface for the 183 upper layer applications, for example, GetSocks64Address, GetNAT- 184 PTAddress. 186 Based on the availability, applications can choose the IPv6 187 connectivity services accordingly. 189 This hybrid ISP platform provides the maximum IPv6 connectivity 190 support for all different solutions. 192 In order to fulfil this hybrid ISP platform, there are two technical 193 gaps needs to be supplied: configuration mechanisms in which service 194 information could be pushed to the host/client devices; standard IPv6 195 connectivity invoking interface on the hosts/client devices. The 196 latter is out of scope of this document. The configuration mechanism 197 is discussed below. 199 3. Configuration Mechanisms 201 There are a number of configuration mechanisms that could be 202 potentially used to propagate IPv6 connectivity service information 203 to the host/client devices. 205 3.1. Manual configuration 207 Manual configuration has already been used in many IPv6 connectivity 208 solutions. However, this method requires expert knowledge for at 209 least first time configuration. Its scalability is quite poor. 211 Furthermore, this mechanism is lack of flexibility. For example, the 212 connectivity service will become unavailable after a server changes 213 its IP address. 215 3.2. DHCPv6 217 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] can 218 assign addresses statefully. Besides, DHCPv6 can also be used to 219 distribute other configuration information. DHCPv6 can be extended to 220 propagate IPv6 connectivity service information. A set of new options 221 needs to be developed and their interaction behaviour need to be 222 defined clearly. 224 3.3. Domain Name Service 226 For well-known services, certain DNS records may be defined so that 227 host/client devices can resolve their IP address through DNS query. 228 For example, natpt.chinatelecom.com.cn can be used to point all China 229 Telecom customers to available NATPT servers. With intelligence DNS 230 mechanism, client requirements can be diverted to a suitable server 231 among many available servers. 233 3.4. Others 235 According to different access technologies, certain protocol, such as 236 PPPOE or ICMP may be extended to propagate IPv6 connectivity service 237 information. 239 4. Security Considerations 241 The security issues for each solution that provides IPv6 connectivity 242 services are out of scope. However, further security analysis will be 243 needed to understand whether there are security issues for 244 configuration mechanisms mentioned in this document. 246 5. IANA Considerations 248 This draft does not request any IANA action. 250 6. References 252 6.1. Normative References 254 [RFC791] J. Postel, "Internet Protocol", RFC 791, September 1981. 256 [RFC2460] S. Deering, et al., "Internet Protocol, Version 6 (IPv6) 257 Specification", RFC2460, December 1998. 259 [RFC2765] E. Nordmark, "Stateless IP/ICMP Translation Algorithm (SIIT) 260 ", RFC 2765, February 2000. 262 [RFC3056] B. Carpenter, K. Moore, "Connection of IPv6 Domains via 263 IPv4 Clouds", RFC 3056, February 2001. 265 [RFC3315] R. Droms, et al., "Dynamic Host Configure Protocol for 266 IPv6", RFC3315, July 2003. 268 6.2. Informative References 270 [RFC2663] P. Srisuresh and M. Holdrege, "IP Network Address 271 Translator (NAT) Terminology and Considerations", RFC 2663, 272 August 1999. 274 [RFC2767] K. Tsuchiya, et al., "Dual Stack Hosts using the Bump-In- 275 the-Stack Technique (BIS)", RFC 2767, February 2000. 277 [RFC3089] H. Kitamura, "A SOCKS-based IPv6/IPv4 Gateway Mechanism, 278 RFC3089", April 2001. 280 [RFC3142] J. Hagino, "An IPv6-to-IPv4 Transport Relay Translator" RFC 281 3142, June 2001. 283 [RFC3338] S. Lee, et al., "Dual Stack Hosts Using Bump-in-the-API 284 (BIA)", RFC 3338 October 2002 286 [RFC4966] C. Aoun and E. Davies, "Reasons to Move the Network Address 287 Translator - Protocol Translator (NAT-PT) to Historic 288 Status", RFC 4966, July 2007. 290 [RFC5214] F. Templin, T. Gleeson, and D. Thaler, "Intra-Site 291 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 292 March 2008. 294 [IPUSAGE] G. Huston, IPv4 Address Report, March 2009, 295 http://www.potaroo.net/tools/ipv4/index.html. 297 [6RD] R. Despres, "IPv6 Rapid Deployment on IPv4 infrastructures 298 (6rd)", draft-despres-6rd-03.txt, working in progress, 299 April 2009. 301 [DSLite] A. Durand, et al., "Dual-stack lite broadband deployments 302 post IPv4 exhaustion", draft-ietf-softwire-dual-stack-lite- 303 00.txt, working in progress, March 2009. 305 [ICGN] S. Jiang, et al., "An Incremental Carrier-Grade NAT (CGN) 306 for IPv6 Transition" draft-jiang-incremental-cgn-00.txt, 307 working in progress, March 2009. 309 [NAT64] M. Bagnulo, et al., "NAT64: Network Address and Protocol 310 Translation from IPv6 Clients to IPv4 Servers", draft- 311 bagnulo-behave-nat64-03.txt, work in progress, March 2009. 313 [TURN] G. Camarillo and O.Novo, "Traversal Using Relays around NAT 314 (TURN) Extension for IPv6", draft-ietf-behave-turn-ipv6- 315 06.txt, working in progress, March 2009. 317 Author's Addresses 319 Jianfeng Xu 320 China Telecom 321 No.109, West Zhongshan Street, Tian-He District, Guangzhou 510630 322 P.R. China 323 Phone: 86-20-38639112 324 EMail: xujf@gsta.com 326 Sheng Jiang 327 Huawei Technologies Co., Ltd 328 KuiKe Building, No.9 Xinxi Rd., 329 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 330 P.R. China 331 Phone: 86-10-82836774 332 EMail: shengjiang@huawei.com