idnits 2.17.1 draft-hiromi-sunset4-termination-ipv4-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 11, 2013) is 4064 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.draft-hazeyama-widecamp-ipv6-only-experience-02' is mentioned on line 121, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R.Hiromi 3 Intended Status: Informational Intec,Inc. 4 Expires: September 12, 2013 Hazeyama 5 NAIST 6 A.Onoe 7 Sony Corporation 8 O.Nakamura 9 Keio University 10 March 11, 2013 12 A workaround for termination of IPv4 network services 13 draft-hiromi-sunset4-termination-ipv4-01 15 Abstract 17 After sun-setting of IPv4, many devices will be connected to IPv6 18 single stack network. In this document we describe a workaround for 19 IPv6 enabled network configuration. At this moment, the condition of 20 IPv6 adoption on the consumer devices such as PC, tablet, mobile 21 terminal and entertainment device are various. For example, some 22 devices are fully support IPv6 client but some are not. It is very 23 hard to provide IPv6 network service with these various conditioned 24 devices. To solve this problem, we tried to verify some 25 configurations to connect these devices into IPv6 enabled consumer 26 network for termination of IPv4 network services. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as 36 Internet-Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/1id-abstracts.html 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 49 Copyright and License Notice 51 Copyright (c) 2013 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . 3 69 1.3 Test Network . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Variety of devices . . . . . . . . . . . . . . . . . . . . . . 6 71 2.1 Device classification . . . . . . . . . . . . . . . . . . . 6 72 2.2 Observation on devices . . . . . . . . . . . . . . . . . . . 8 73 3 Workaround . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 3.1 trial and result . . . . . . . . . . . . . . . . . . . . . . 9 75 3.2 remaining issue . . . . . . . . . . . . . . . . . . . . . . 10 76 4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 10 78 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 79 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 7.1 Normative References . . . . . . . . . . . . . . . . . . . 11 81 8 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 12 83 1 Introduction 85 After sun-setting of IPv4, many devices will be connected to IPv6 86 single stack network. In this document we describe a workaround of 87 IPv6 enabled network configuration. At this moment, the condition of 88 IPv6 adoption on the consumer devices such as PC, tablet, smart 89 phones and entertainment devices are various. For example, some 90 devices are fully support DHCPv6 client function but some are not. 91 In IETF, additional function for connecting clients are still 92 discussed. Implementation of client function will be changing for a 93 while. It must be very hard to provide IPv6 network service with 94 these various conditioned devices. To solve this issue, we tried to 95 verify several configurations to connect these devices into IPv6 96 enabled consumer network. 98 1.1 Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 1.2 Problem Statement 106 "IPv6 support" on consumer devices are inconsistent in 107 implementation. Especially some devices are designed with IPv6 108 limitation if no IPv4 information provided on the device. The IPv6 109 network services has to absorb these differences in some way. 111 1.3 Test Network 113 In this document we call "IPv6-only network" as a user network which 114 connects IPv6 clients and carries IPv6 packets. We made an IPv6-only 115 test network with 3 patterns of configurations. The pattern A is the 116 basic configuration. In the pattern B, DNS64[DNS64]/NAT64[NAT64] is 117 located in the User router segment and users refer DNS proxy. In the 118 pattern C, DNS64/NAT64 is located in ISP segment. 120 We brought above IPv6-only network to seasonal WIDE Camp from 2011 to 121 2012[I-D.draft-hazeyama-widecamp-ipv6-only-experience-02]. WIDE Camp 122 was hold 3 times. Through DNS64/NAT64 translation, the clients can 123 access IPv4 Internet services and with this technique the users can 124 turn off IPv4 at the edge network. We can observe simply IPv6 client 125 behavior and solve the specified points. 127 Here is the basic configuration; 129 User-Access: WiFi(IEEE802.11a,b,g,n) 130 ISP(IPv6): DHCP-PD or static setting of prefix 131 IPv4 Internet: using coexistence mechanism(4rd,464XLAT,SA46T, 132 DNS64/NAT64) over IPv6, base technology 133 is DNS64/NAT64 134 DNS64/NAT64: Map all IPv4 toward IPv4 Internet into IPv6 135 RA: Enable Other Config flag for DHCP6 136 DHCP6: Distribute DNS64 server address 137 DHCP4: No DHCPv4 running 138 (this is for whom really needs IPv4 connection) 139 IPv6 Address Configuration: 140 SLAAC(address prefix, default router), DHCPv6 141 (DNS server) 143 Fig.1 Pattern A(Basic Network Topology) 145 +-------------+ 146 | IPv6 router | 147 | on ISP | 148 +-------------+ 149 | 150 | 151 +--------------- IPv6 Internet ----------------------+ 152 | 153 | 154 +---------+ 155 | User GW | 156 +---------+ 157 | +--- IPv4 Internet ---+ 158 | | | 159 +-----+ | +--------+ +-------+ +------+ 160 |DHCP4| | | DHCP6 | | DNS64 | | NAT64| 161 +-----+ | +--------+ +-------+ +------+ 162 | | | | | 163 | | | | | 164 +---------------- /64 prefix segment ---------------------+ 165 | 166 +--------------+ 167 | user devices | 168 +--------------+ 170 Fig.2 Pattern B 172 +-------------+ 173 | IPv6 router | 174 | on ISP | 175 +-------------+ 176 | 177 | 178 +--------------- IPv6 Internet ----------------------+ 179 | 180 | +--- IPv4 Internet ---+ 181 +--------------+ | | 182 | IPv6 router | +-----+ +-----+ 183 | on user side | |DNS64| |NAT64| 184 +--------------+ +-----+ +-----+ 185 | | | | 186 | +--- /64 prefix segment ---+ 187 | 188 +---------+ 189 | User GW | 190 +---------+ 191 | 192 | 193 +-----+ +------------+ | +--------+ 194 |DHCP4| |DNS Proxy | | | DHCP6 | 195 +-----+ |wt. A filter| | +--------+ 196 | +------------+ | | 197 | | | | 198 +---------------- /64 prefix segment ---------------------+ 199 | 200 +--------------+ 201 | user devices | 202 +--------------+ 204 Fig.3 Pattern C 206 +-- IPv4 Internet --+ 207 | | 208 +-----+ +-----+ 209 |DNS64| |NAT64| 210 +-----+ +-----+ 211 | | 212 +--------------- IPv6 Internet ----------------------+ 213 | 214 +-------------+ 215 | IPv6 router | 216 | on ISP | 217 +-------------+ 218 | 219 | 220 +--------------- IPv6 Internet ----------------------+ 221 | 222 | 223 +---------+ 224 | User GW | 225 +---------+ 226 | 227 | 228 +-----+ +------------+ | +--------+ 229 |DHCP4| |DNS Proxy | | | DHCP6 | 230 +-----+ |wt. A filter| | +--------+ 231 | +------------+ | | 232 | | | | 233 +---------------- /64 prefix segment ---------------------+ 234 | 235 +--------------+ 236 | user devices | 237 +--------------+ 239 2. Variety of devices 241 In this section, we describe what kinds of devices we examined in the 242 test network. 244 2.1 Device classification 246 Over 300 devices were brought into every WIDE Camp. We classified their 247 Device Type, OS, OS version. We determined deference of DHCP6 client 248 behavior and possible precondition per OS. Table 1 and 2 shows the 249 result of them. Popular OS on PC was both Windows and MacOS X series. 250 Various versions were observed. Popular OS on Mobile Phone was both 251 Android and iOS. Feature phone were also popular but there were no WiFi 252 function on such feature phone so that they were out of our target. In 253 Table 1, we listed up auto-address configuration function on each OS. 254 The last column means the SLAAC/DHCP6 failed if they got IPv4 local 255 address. In Table 2, we picked up the OS which does not have IPv6 256 friendly User Interface and could not input IPv6 address manually with 257 the UI. 259 Table 1. Result of the client behavior per OS 260 +---------+----------+----------+----------+----------+ 261 |OS |Version |RA |DHCPv6 |169.254/16| 262 +---------+----------+----------+----------+----------+ 263 |Windows |XP |o |x | | 264 | |Vista |o |o | | 265 | |7 |o |o | | 266 | |8 |o |o | | 267 +---------+----------+----------+----------+----------+ 268 |MacOS X |10.6 |o |x | | 269 | |10.7 |o |o | | 270 | |10.8 |o |o | | 271 +---------+----------+----------+----------+----------+ 272 |Android |1.6 |x |x | | 273 | |2.3.4 |o |x |x | 274 | |2.3.5 |o |x |x | 275 | |2.3.6 |o |x |x | 276 | |4.0.3 |o |x |x | 277 | |4.0.4 |o |x |x | 278 | |4.1 |o |x |x | 279 +---------+----------+----------+----------+----------+ 280 |iOS |4.3.2 JB |o |x |x | 281 | |5 |o |x |x | 282 +---------+----------+----------+----------+----------+ 283 |iPad iOS |5 |o |o | | 284 | |6 |o |o | | 285 +---------+----------+----------+----------+----------+ 286 |kindle |3.1 |x |x | | 287 +---------+----------+----------+----------+----------+ 288 |NetBSD |5.1 |o |x | | 289 | |6.99.4 |o |x | | 290 +---------+----------+----------+----------+----------+ 291 |Ubuntsu |12.0.4 |o |o | | 292 +---------+----------+----------+----------+----------+ 293 Table 2. List of OS without IPv6 support on User Interface 295 +----------+-----------+--------------+--------------+ 296 |OS |Version |display |configuration | 297 +----------+-----------+--------------+--------------+ 298 |Android |2.3.4 |x |x | 299 | |2.3.6 |x |x | 300 +----------+-----------+--------------+--------------+ 301 |iOS |5 |x |x | 302 +----------+-----------+--------------+--------------+ 303 |iPad iOS |5 |x |x | 304 +----------+-----------+--------------+--------------+ 306 2.2 Observation on devices 308 We observed 5 problematic behaviors. 310 (a). failed to set name server(v6) information(WinXP, MacOS SL, 311 Android) 312 (b). failed to input name server(v6) by manual configuration(Android) 313 (c). failed to resolve resource record under (a) or (c) 314 condition(WinXP, MacOS SL, Android) 315 (d). "network setting" won't be completed before getting set of IPv4 316 information(DNS,router,IPv4 Address)(iOS5,Android) 317 (e). waiting for IPv4 connection timeout(MacOS) 319 The causes of problems on consumer devices are sorted by 3 types. 321 First one is IPv6 implementation issue, which we listed on Table 1. 323 The other issue is User Interface issue, which we listed on Table 2. 325 The last one is coming from other layer's function, typical issue is a 326 WiFi controller which provided by vendor(Lenovo Access Connections) and 327 turn off IPv4 with the controller setting then the client was able to 328 connect to IPv6-only network. 330 3 Workaround 332 In this document, we focused on the problem which occurred by IPv6 333 implementation on the clients. 335 How do we solve the problematic behavior? It might be a distant idea 336 that waiting for all devices fully support IPv6. We considered to put 337 additional configuration parameters to comply with improvements. 339 3.1 trial and result 341 To solve (a)to(e) in Section 2.2, we reconsidered network setting and 342 putting into testbed network step by step. 344 (1) DNS64/NAT64 Map all IPv4 on Internet into IPv6 345 (2) DHCPv6 for DNS(IPv6) configuration 346 (3) DHCPv4 for IPv4 private address configuration 347 (4) DHCPv4 for DNS(IPv4) and Default Router 348 (actual packet transfer is prohibited on this router) 349 (5) DNS(IPv4) is located local segment 350 (6) DNS(IPv4, IPv6) set 'A' filter 351 (7) DNS(IPv4, IPv6) always returns 'NODATA' with 'A' query 352 (Over both IPv4 and IPv6 transport) 353 (8) AAAA queries forward to DNS64 server 355 Experiment #1: 356 With "IPv4 private address assignment via DHCP4 without Default 357 Router nor DNS", no issues were solved. 358 - Timeout problem exist on MacOSX. 359 - iOS applications are sometimes working,but periodically fails due 360 to retrying Wi-Fi connection. 362 Experiment #2: 363 Put BIND9 forwarder on-link and configure DHCP4/6 to use this DNS. 364 Configure BIND9 forwarder with: deny-answer-addresses { 0.0.0.0/0; }; 365 Which direct no IPv4 address answer should be trusted. It returns 366 SERVFAIL to resolver. 367 - Android is now working: Browser, Twitter, Facebook are OK. 368 - iOS is working: but periodically fails due to retrying. 369 - MacOS is working: but still encountered fallback timeout. 370 - Windows is NOT WORKING: all DNS queries failed due to SERVFAIL. 372 Experiment #3: 373 Hack AAAA filtering code on BIND9 to filter 'A' instead of 'AAAA' 374 both on IPv4/IPv6 transport. Put BIND9 above to local link, which is 375 configured to forward all queries to DNS64. Configure DHCP4/DHCP6 to 376 use the DNS proxy. 377 - Windows, MacOS X, iOS, Android is now working. 379 - Some of applications still failed on IPv6 only, but many are OK: 380 IE/Safari/Chrome/Firefox, Twitter, Facebook, Instagram, APNS, ... 382 After bringing all new additional network configuration, most of all 383 clients were able to connect IPv6-only network with zero- 384 configuration on the client side. 386 This is the technique for IPv6-only network but also can be useful 387 for terminating IPv4 network environment at the user network. 389 3.2 remaining issue 391 "Waiting for IPv4 connection timeout on MacOS" is still issued. A 392 possible reason for this connection failure during 1-2 minutes after 393 WiFi connection established is timing of sending RS(Router 394 Solicitation). RS is sent from kernel before Wi-Fi link is 395 established. No IPv6 address is obtained until periodical RA(Router 396 Advertisement) is received. 398 Workaround for this is considered as follows but we were not unable 399 to examine it on the camp at this time. 401 - shorten RA interval to 5-10 seconds (though it disturb Wi-Fi...) 402 - Detect association through AP log and kick RS or RA. 404 4 Conclusion 406 We determined several network configurations with variety of devices. 407 For IPv4 sun-setting, the network should have these capabilities 408 described below. 410 - Core Network has to connect IPv4 Internet 411 - Core Network has to have IPv4 and IPv6 coexistence technology 412 - devices can be connected IPv6 only segment 413 - IPv4 address assigning protocol should be enabled for IPv6 414 address settings 415 - "A filter" on DNS server is effective for terminating IPv4 416 connection trial 418 5 Security Considerations 420 Possible security threats are same as what pointed out in original 421 protocols and technologies. 423 6 IANA Considerations 425 This document has no IANA implications. 427 7 References 429 7.1 Normative References 431 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 432 Requirement Levels", BCP 14, RFC 2119, March 1997. 434 [NAT64] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 435 NAT64: Network Address and Protocol Translation from IPv6 436 Clients to IPv4 Servers", RFC 6146, April 2011. 438 [DNS64] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 439 Beijnum, "DNS64: DNS Extensions for Network Address 440 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 441 April 2011. 443 [I-D.draft-hazeyama-widecamp-ipv6-only-experience-02]H. Hazeyama, R. 444 Hiromi, T. Ishihara and O. Nakamura, "Experiences from 445 IPv6-Only Networks with Transition Technologies in the 446 WIDE Camp Autumn 2012", draft-hazeyama-widecamp-ipv6-only- 447 experience-02, October 2012. 449 8 Acknowledgement 451 Here, we thank to all the participants of WIDE camp(s) on the 452 experiments. We also say thank you to whom serving implementations 453 and services in the Matsuhiro Royal Hotel. 455 Y. Ueno of Keio Univ. for IPv6 L2TP implementation 456 NTT EAST and IIJ for the commercial IPv6 service 457 R. Nakamura of Univ. of Tokyo, Y. Ueno of Keio Univ. and R. Shouhara 458 of Univ. of Tokyo for helping us on the base settings of the IPv6 459 only experiments and merging into the camp-net. 460 T. Jimei of Internet Systems Consortium for his quick hack on A 461 filter of Bind 9. 462 T. Ishihara of Univ. of Tokyo for his DNS operating advisory 463 Y. Atarashi of Alaxala Networks and R. Atarashi of IIJ Innovation 464 Institute for designing the items of face to face interview and 465 analyzing user survey data. 467 Authors' Addresses 469 R.Hiromi 470 INTEC Inc. 471 1-3-3, Shinsuna, 472 Koto-ku, 473 Tokyo, Japan 474 EMail: hiromi@inetcore.com 476 Hiroaki Hazeyama 477 NAIST 478 Takayama 8916-5 479 Nara, Japan 480 Phone: +81 743 72 5216 481 Email: hiroa-ha@is.naist.jp 483 Atsushi Onoe 484 SONY Corporation 485 EMail: onoe@wide.ad.jp 487 Osamu Nakamura 488 WIDE Project 489 5322 Endo 490 Kanagawa, Japan 491 Email: osamu@wide.ad.jp