idnits 2.17.1 draft-xu-v6ops-hybrid-framework-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 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 30, 2009) is 5413 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 normative reference: RFC 4741 (Obsoleted by RFC 6241) -- Obsolete informational reference (is this intentional?): RFC 2767 (Obsoleted by RFC 6535) -- Obsolete informational reference (is this intentional?): RFC 3338 (Obsoleted by RFC 6535) Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 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: December 26, 2009 Huawei Technologies Co., Ltd 5 B. Carpenter 6 University of Auckland 7 June 30, 2009 9 A Hybrid ISP Framework for IPv6 Services and IPv6/IPv4 Inter- 10 communication 11 draft-xu-v6ops-hybrid-framework-00.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on December 26, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 Global IPv6 deployment is expected. Many solutions have been 49 specified in order to provide IPv6 connectivity service. In order to 50 provide IPv6 connectivity service to all kinds of host/client devices, 51 ISP networks may need to support as many as possible IPv6 52 connectivity solutions. This document proposes a hybrid ISP framework 53 that supports the coexistence of various IPv6 connectivity solutions 54 and analyses the configuration requirements raised by this framework. 55 Additionally, the applicability of different configuration mechanisms 56 for performing this configuration is discussed. 58 Table of Contents 60 1. Introduction................................................3 61 2. Overview of A Hybrid ISP Framework...........................5 62 3. APPs/ICPs Involvement........................................6 63 4. Configuration Mechanisms.....................................7 64 4.1. Manual configuration....................................7 65 4.2. DHCPv6.................................................7 66 4.3. Domain Name Service.....................................7 67 4.4. Others.................................................8 68 5. Security Considerations......................................8 69 6. IANA Considerations.........................................8 70 7. References..................................................8 71 7.1. Normative References....................................8 72 7.2. Informative References..................................9 73 Author's Addresses............................................11 75 1. Introduction 77 Global Internet has grown up rapidly in last 25 years. More and more 78 devices are connected to the global Internet infrastructure. Internet 79 Protocol (version 4 [RFC0791]) played an essential role during the 80 success of the Internet. IPv4 addresses identify the logical location 81 of every device in the Internet so that data packets can be delivered 82 to the right destination. However, giving the fact that the length of 83 IPv4 addresses is only 32 bits, there are fewer than 4 billion 84 available IPv4 addresses, and the address space is used inefficiently. 85 IPv4 address exhaustion is now confirmed to happen soon. The 86 dynamically-updated IPv4 Address Report [IPUSAGE] has analyzed this 87 issue. It predicts early 2011 for IANA unallocated address pool 88 exhaustion and middle 2012 for RIR unallocated address pool 89 exhaustion. Individual ISPs will experience address shortage at a 90 date depending on their own situation after the RIRs can make no more 91 allocations. 93 Although there are a number of mechanisms trying to extend the life 94 time of IPv4, the transition of the Internet to Internet Protocol 95 version 6 [RFC2460] is the only practical and perennial solution to 96 IPv4 address exhaustion. The Internet industry appears to have 97 reached consensus that global IPv6 deployment is inevitable and has 98 to be done quite quickly. IPv4/IPv6 transition, including inter- 99 communication between IPv4 and IPv6, therefore becomes more critical 100 and complicated for the soon-coming global IPv6 deployment. 102 On the other hand, many solutions have been specified in order to 103 provide IPv6 connectivity service. The most basic is the deployment 104 of dual stack hosts and routers [RFC4213] including the support of 105 configured IPv6-over-IPv4 tunnels. However, the dual stack approach 106 cannot be sufficient once IPv4 addresses have run out, because it 107 does not allow IPv6-only hosts to communicate with IPv4-only hosts. 109 Techniques that extend the dual stack model include 6over4 [RFC2529], 110 6to4 [RFC3056], ISATAP (Intra-Site Automatic Tunnel Addressing 111 Protocol [RFC5214]), and tunnel brokers [RFC3053]. 113 Techniques that address the interworking problem include SIIT 114 (Stateless IP/ICMP Translation Algorithm [RFC2765]) and NAT-PT 115 [RFC2663]. Although NAT-PT has been obsoleted [RFC4966], NAT-PT-like 116 technologies, for example NAT64 [NAT64], are still needed. Other 117 translation techniques include BIS (Dual Stack Hosts using the Bump- 118 In-the-Stack Technique [RFC2767]), Transport Replay Translator 119 [RFC3142], BIA (Dual Stack Hosts Using Bump-in-the-API [RFC3338]), 120 and SOCKS 64 Gateway [RFC3089]. Interworking for specific application 121 services such as HTTP proxy or SMTP, IMAP and POP3 can also easily be 122 provided by dual stack servers. 124 Each technique has different service scenarios and may need both 125 Internet Service Provider (ISP) networks and host/client devices to 126 support them at the same time. Furthermore, in the expected IPv6 127 global deployment, new issues or different scenarios may occur. 128 Correspondingly, more solutions may be developed to meet some of 129 these requirements in the future. For example, 6RD (IPv6 Rapid 130 Deployment [6RD]), Port Range [PortRange, PRv6], Dual-Stack Lite 131 [DSLite], Incremental CGN [ICGN], and TURN (Traversal Using Relays 132 around NAT [TURN] Extension for IPv6) have been also submitted to the 133 IETF recently. 135 Up to now, there is not one universal mechanism that can meet all 136 IPv6 connectivity service scenarios, including connectivity between 137 IPv6-only and IPv4-only. Table 1 gives a partial summary. Host/client 138 devices may choose to support one or several mechanisms. But 139 host/client devices with various solutions all require IPv6 140 connectivity through ISP network services. In order to provide IPv6 141 connectivity service to different kinds of host/client devices, ISP 142 networks need to support as many IPv6 connectivity solutions as is 143 operationally reasonable. Additionally, all these efforts should be 144 transparent for the average end-user. 146 +------------------------------------------------------------+ 147 | |6o4|6to4| ISA |ST-|STLS|BIS|Trans.|SOCKS|BIA| 148 | | | |-TAP |Trs|-Trs| |Relay | G/W | | 149 |---------------+---+----+-----+---+----+---+------+-----+---| 150 |Dual Stack Host| X | | X | | | X | | | X | 151 |---------------+---+----+-----+---+----+---+------+-----+---| 152 | Upper Message | | | | | | | X | X | X | 153 | Manipulation | | | | | | | | | | 154 |---------------+---+----+-----+---+----+---+------+-----+---| 155 | IP Header | | | | X | X | X | | | | 156 | Translation | | | | | | | | | | 157 |---------------+---+----+-----+---+----+---+------+-----+---| 158 | Tunnelling | X | X | X | | | | | X | | 159 |---------------+---+----+-----+---+----+---+------+-----+---| 160 | In Host | X | | X | | | X | X | X | X | 161 |---------------+---+----+-----+---+----+---+------+-----+---| 162 | In Gate | | X | | X | | | X | X | | 163 +------------------------------------------------------------+ 165 Table 1: Characters of IPv6 connectivity mechanisms 167 In table 1, each column means: 168 6o4 = IPv6 over IPv4 [RFC2529] 6to4 = [RFC3056] 169 ISATAP = Intra-Site Automatic Tunnel Addressing Protocol [RFC5214] 170 ST-Trs = Stateful Translation, such as NAT-PT [RFC2663], NAT64 [NAT64] 171 STLS-Trs = Stateless Translation, such as Stateless IP/ICMP 172 Translation Algorithm [RFC2765] 173 BIS = Dual Stack Hosts using the Bump-In-the-Stack Technique [RFC2767] 174 Trans. Relay = Transport Replay Translator [RFC3142] 175 SOCKS G/W = SOCKS 64 Gateway [RFC3089] 176 BIA = Dual Stack Hosts Using Bump-in-the-API [RFC3338] 178 In table 1, each row means: 179 Dual Stack Host = supporting dual-stack hosts 180 Upper Message Manipulation = modifying application messages 181 IP Header Translation = translating IP header 182 Tunnelling = using Tunnel technology 183 In Host = involving host support 184 In Gate = involving gateway support 186 This document proposes a hybrid ISP framework that supports the co- 187 existence of multiple IPv6 connectivity solutions, and analyses the 188 configuration requirements raised by this framework. Additionally, 189 the applicability of different configuration mechanisms for 190 performing this configuration is discussed. 192 2. Overview of A Hybrid ISP Framework 194 The proposed hybrid ISP framework supports the co-existence of hybrid 195 IPv6 connectivity and IPv6/IPv4 inter-communication solutions. It 196 encourages ISPs to work together with Internet Content Providers 197 (ICPs) to provide IPv6 connectivity and IPv6/IPv4 inter-communication 198 service. ISPs provide as much as possible generic support. ICPs can 199 design and implement their application specific interworking 200 mechanisms utilizing their ISP's generic services. 202 First, ISPs should deploy required resources for offering IPv6 203 connectivity and IPv6/IPv4 inter-communication solutions in their 204 operational networks. Depending on each solution, the required 205 devices may be located at different network segments. For example, 206 IPv6/IPv4 inter-communication devices should be placed at the edge 207 between IPv4/IPv6 networks. CGNs may be deployed according to the ISP 208 customer aggregation strategy. Application-specific gateways (ALGs) 209 for IPv6/IPv4 inter-communication may be deployed as services by ICP 210 within ISP network too. Each application may have its customized 211 traversal or interworking mechanisms and servers. As noted above, 212 this is very straightforward for "relay" applications like mail and 213 HTTP proxy. 215 All information about deployed services, including IP addresses of 216 servers, needs to be collected and distributed to ISP access devices, 217 such as BRAS. Then, this information, include availability 218 information, can be propagated to the host/client devices through 219 standard protocols, which need to be extended, based on existing 220 Dynamic Host Configure Protocol for IPv6 (DHCPv6) [RFC3315], IPv6 221 over PPP [RFC5072], Network Configuration Protocol (NETCONF) 222 [RFC4741], Simple Network Management Protocol (SNMP) [RFC3411] or 223 other protocols. Note that IPv6 autoconfiguration is not powerful 224 enough for this purpose. 226 Based on the availability information received, applications on the 227 host/client devices can choose the IPv6 connectivity services they 228 can use or prefer. 230 The operating system (OS) on the host/client devices may filter/drop 231 some IPv6 connectivity services according to its own capability. The 232 OS should provide a standard IPv6 connectivity invoking interface for 233 the upper layer applications. 235 The hybrid ISP framework provides support for as many as possible 236 different IPv6 connectivity solutions. CPEs and host/client devices 237 may need to be configured or updated to get maximum benefit, but they 238 must all get basic connectivity in a standard way. 240 In order to realise this hybrid ISP framework, there are two 241 technical gaps that need to be filled: configuration mechanisms in 242 which service information could be pushed to the host/client devices; 243 standard IPv6 connectivity invoking interface on the hosts/client 244 devices. The latter is out of scope of this document. The 245 configuration mechanism is discussed below. 247 3. APPs/ICPs Involvement 249 This framework assumes applications or ICPs would ideally be aware of 250 IPv4/IPv6 inter-communication; it requests applications or ICPs to 251 choose among the different inter-communication technologies. This 252 seems to be in conflict with the traditional layered network model. 254 However, the reality is that applications/ICPs, particularly peer-to- 255 peer applications, have already broken the layered network model so 256 that they can traverse the ubiquitous NAT devices. In the IPv4 257 networks, the existence of NAT breaks the end-to-end transparency. In 258 order to find NATs and traverse them, applications have to understand 259 network protocols deeply, invoke or interact with network protocols 260 directly and analyse network behaviours by themselves, since the 261 protocol stack on the end user devices is not aware of NATs. 262 Furthermore, since NAT is not standardized, applications have to 263 handle many different NAT technologies. 265 The scenarios between IPv4-only hosts and IPv6-only hosts are partly 266 similar to above discussed NAT scenarios. Due to the differences, 267 there can not be pure end-to-end transparency between them. Based on 268 this reality, the better way is to standardize IPv4/IPv6 inter- 269 communication technologies, also mechanisms which propagate relevant 270 information from networks to end hosts. Then, applications could 271 learn inter-communication information from the protocol stack on the 272 hosts instead of detecting by themselves. This learning process may 273 be through a standard API between network layer and application layer 274 on the hosts. This design actually maintains the traditional layered 275 network model. 277 4. Configuration Mechanisms 279 There are a number of configuration mechanisms that could be 280 potentially used to propagate IPv6 connectivity service information 281 to the host/client devices. 283 4.1. Manual configuration 285 Manual configuration has already been used in many IPv6 connectivity 286 solutions. However, this method requires expert knowledge for at 287 least first time configuration. Its scalability is quite poor. Its 288 operational burden would be too large when there are many users. 289 Furthermore, this mechanism is very exposed to human errors. 291 4.2. DHCPv6 293 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] can 294 assign addresses statefully. Besides, DHCPv6 can also be used to 295 distribute other configuration information. DHCPv6 can be extended to 296 propagate IPv6 connectivity service information. A set of new options 297 needs to be developed and their behaviour must be defined clearly. 299 4.3. Domain Name Service 301 For well-known services, certain DNS records may be defined so that 302 host/client devices can resolve their IP addresses through DNS 303 queries using DNS SRV [RFC2782]. For example, natpt.isp1.example.net 304 can be used to point all ISP1 customers to available NAT-PT servers. 306 With a suitable DNS mechanism, client load can be distributed among 307 many available servers. 309 4.4. Others 311 According to different access technologies, certain protocols, such 312 as PPPoE or ICMP [RFC0792], may be extended to propagate IPv6 313 connectivity service information to subscribers. Note that router and 314 switch configuration protocols such as NETCONF and SNMP are not 315 considered relevant here. 317 5. Security Considerations 319 The security issues for each solution that provides IPv6 connectivity 320 service are discussed in their own specifications. However, further 321 security analysis will be needed to understand whether there are 322 security issues for configuration mechanisms mentioned in this 323 document. 325 6. IANA Considerations 327 This draft does not request any IANA action. 329 7. References 331 7.1. Normative References 333 [RFC0791] J. Postel, "Internet Protocol", RFC 791, September 1981. 335 [RFC0792] J. Postel, "Internet Control Message Protocol", RFC 792, 336 September 1981. 338 [RFC2460] S. Deering, et al., "Internet Protocol, Version 6 (IPv6) 339 Specification", RFC2460, December 1998. 341 [RFC2529] B. Carpenter, C. Jung, "Transmission of IPv6 over IPv4 342 Domains without Explicit Tunnels", RFC 2529, March 1999. 344 [RFC2765] E. Nordmark, "Stateless IP/ICMP Translation Algorithm (SIIT) 345 ", RFC 2765, February 2000. 347 [RFC2782] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for 348 specifying the location of services (DNS SRV)", RFC2782, 349 February 2000. 351 [RFC3053] A. Durand, P. Fasano, I. Guardini, D. Lento, "IPv6 Tunnel 352 Broker", RFC3053, January 2001. 354 [RFC3056] B. Carpenter, K. Moore, "Connection of IPv6 Domains via 355 IPv4 Clouds", RFC 3056, February 2001. 357 [RFC3315] R. Droms, et al., "Dynamic Host Configure Protocol for 358 IPv6", RFC3315, July 2003. 360 [RFC3411] D. Harrington, R. Presuhn, B. Wijnen, "An Architecture for 361 Describing Simple Network Management Protocol (SNMP) 362 Management Frameworks", RFC 3411, December 2002. 364 [RFC4213] E. Nordmark, R. Gilligan, "Basic Transition Mechanisms for 365 IPv6 Hosts and Routers", RFC4213, October 2005. 367 [RFC4741] R. Enns, et al., "NETCONF Configuration Protocol", RFC 4741, 368 December 2006. 370 [RFC5072] S.Varada, Ed., D. Haskins, E. Allen, "IP Version 6 over 371 PPP", RFC 5072, September 2007. 373 7.2. Informative References 375 [RFC2663] P. Srisuresh and M. Holdrege, "IP Network Address 376 Translator (NAT) Terminology and Considerations", RFC 2663, 377 August 1999. 379 [RFC2767] K. Tsuchiya, et al., "Dual Stack Hosts using the Bump-In- 380 the-Stack Technique (BIS)", RFC 2767, February 2000. 382 [RFC3089] H. Kitamura, "A SOCKS-based IPv6/IPv4 Gateway Mechanism, 383 RFC3089", April 2001. 385 [RFC3142] J. Hagino, "An IPv6-to-IPv4 Transport Relay Translator" RFC 386 3142, June 2001. 388 [RFC3338] S. Lee, et al., "Dual Stack Hosts Using Bump-in-the-API 389 (BIA)", RFC 3338 October 2002. 391 [RFC4966] C. Aoun and E. Davies, "Reasons to Move the Network Address 392 Translator - Protocol Translator (NAT-PT) to Historic 393 Status", RFC 4966, July 2007. 395 [RFC5214] F. Templin, T. Gleeson, and D. Thaler, "Intra-Site 396 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 397 March 2008. 399 [IPUSAGE] G. Huston, IPv4 Address Report, March 2009, 400 http://www.potaroo.net/tools/ipv4/index.html. 402 [6RD] R. Despres, "IPv6 Rapid Deployment on IPv4 infrastructures 403 (6rd)", draft-despres-6rd, working in progress. 405 [PortRange] B. Storer, et al., "IPv4 Connectivity Access in the 406 Context of IPv4 Address Exhaustion", draft-boucadair-port- 407 range, work in progress. 409 [PRv6] M. Boucadair, et al., "Flexible IPv6 Migration Scenarios in 410 the Context of IPv4 Address Shortage", draft-boucadair- 411 behave-ipv6-portrange, work in progress. 413 [DSLite] A. Durand, et al., "Dual-stack lite broadband deployments 414 post IPv4 exhaustion", draft-ietf-softwire-dual-stack-lite, 415 working in progress. 417 [ICGN] S. Jiang, et al., "An Incremental Carrier-Grade NAT (CGN) 418 for IPv6 Transition" draft-jiang-v6ops-incremental-cgn, 419 working in progress. 421 [NAT64] M. Bagnulo, et al., "NAT64: Network Address and Protocol 422 Translation from IPv6 Clients to IPv4 Servers", draft- 423 bagnulo-behave-nat64, work in progress. 425 [TURN] G. Camarillo and O.Novo, "Traversal Using Relays around NAT 426 (TURN) Extension for IPv6", draft-ietf-behave-turn-ipv6, 427 working in progress. 429 Author's Addresses 431 Jianfeng Xu 432 China Telecom 433 No.109, West Zhongshan Street, Tian-He District, Guangzhou 510630 434 P.R. China 435 Phone: 86-20-38639112 436 EMail: xujf@gsta.com 438 Sheng Jiang 439 Huawei Technologies Co., Ltd 440 KuiKe Building, No.9 Xinxi Rd., 441 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 442 P.R. China 443 Phone: 86-10-82836774 444 EMail: shengjiang@huawei.com 446 Brian Carpenter 447 Department of Computer Science 448 University of Auckland 449 PB 92019 450 Auckland, 1142 451 New Zealand 452 Email: brian.e.carpenter@gmail.com