INTERNET-DRAFT R.Hiromi Intended Status: Informational Intec,Inc. Expires: April 18, 2013 Hazeyama NAIST A.Onoe Sony Corporation O.Nakamura Keio University October 15, 2012 A workaround for termination of IPv4 network services draft-hiromi-sunset4-termination-ipv4-00 Abstract After sun-setting of IPv4, many devices are connected to IPv6 single stack network. In this document we describe a workaround of IPv6 enabled network configuration. At this moment, the condition of IPv6 adoption on the consumer devices such as PC, tablet, mobile terminal and entertainment devices are various. For example, some devices are fully support IPv6 client but some are not. It is very hard to provide IPv6 network service with these various conditioned devices. To solve this problem, we tried to verify some configurations to connect these devices into IPv6 enabled consumer network for termination of IPv4 network services. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at Expires April 18, 2013 [Page 1] INTERNET DRAFTOctober 15, 2012 http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2012 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 (http://trustee.ietf.org/license-info) 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Test Network . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problems Statement . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Device classification . . . . . . . . . . . . . . . . . . . 4 2.2 Observation on personal device . . . . . . . . . . . . . . . 6 3 Workaround . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 trial and result . . . . . . . . . . . . . . . . . . . . . . 7 Experiment #1: . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Experiment #2: . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Experiment #3: . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 remaining issue . . . . . . . . . . . . . . . . . . . . . . 8 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1 Normative References . . . . . . . . . . . . . . . . . . . 8 6.2 Informative References . . . . . . . . . . . . . . . . . . 9 7 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Expires April 18, 2013 [Page 2] INTERNET DRAFTOctober 15, 2012 1 Introduction After sun-setting of IPv4, many devices are connected to IPv6 only network. In this document we describe a workaround of IPv6 enabled network configuration. At this moment, the condition of IPv6 adoption on the consumer devices such as PC, tablet, smart phones and entertainment devices are various. For example, some devices are fully support DHCPv6 client function but some are not. In IETF, additional function for connecting clients are still discussed. Implementation of client function will be changing for a while. It must be very hard to provide IPv6 network service with these various conditioned devices. To solve this issue, we tried to verify some configurations to connect these devices into IPv6 enabled consumer network. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.2 Test Network In this document we call "IPv6-only network" as a user network which connects IPv6 clients and carries IPv6 packets. We made an IPv6-only test network as following configuration. We brought this IPv6-only network to seasonal WIDE Camp from 2011 to 2012. WIDE Camp was hold 3 times. Through DNS64/NAT64 translation, the clients can access IPv4 Internet services and with this technique the users can turn off IPv4 at the edge network. We can observe simply IPv6 client behavior and solve the specified points. Here is the basic configuration; User-Access: WiFi(IEEE802.11a,b,g,n) IPv6 Address Configuration: SLAAC(address prefix,router),DHCPv6(DNS) ISP(IPv6): DHCP-PD or static setting of prefix IPv4 Internet: using coexistence mechanism(4rd,464XLAT,SA46T,DNS64/NAT64) over IPv6, base technology is DNS64/NAT64 DNS64/NAT64: Map all IPv4 on Internet into IPv6 RA: Enable Other Config (for DHCP6) DHCPv6: Distribute DNS64 address DHCP4: No DHCPv4 running! +-------------+ | IPv6 router | Expires April 18, 2013 [Page 3] INTERNET DRAFTOctober 15, 2012 | on ISP | +-------------+ | | +--------------- IPv6 Internet ----------------------+ | | +---------+ | User GW | +---------+ | | | +--------+ +-------+ +------+ | | DHCP6 | | DNS64 | | NAT64| | +--------+ +-------+ +------+ | | | | | | | | +---------------- /64 prefix segment ---------------------+ | +--------------+ | user devices | +--------------+ Fig.1 Basic Network Topology 2. Problems Statement "IPv6 support" on consumer devices are inconsistent in implementation. Especially some devices are designed with IPv6 limitation if no IPv4 information provided on the device. The IPv6 network services has to absorb these differences in some way. 2.1 Device classification Over 300 devices were brought into every WIDE Camp. We classified their Device Type, OS, OS version. We determined deference of DHCP6 client behavior and possible precondition per OS. Table 1 and 2 shows the result of them. Popular OS on PC was both Windows and MacOS X series. Various versions were observed. Popular OS on Mobile Phone was both Android and iOS. Feature phone were also popular but there were no WiFi function on such feature phone so that they were out of our target. In Table 1, we listed up auto-address configuration function on each OS. The last column means the failure occurred case with checked mark if they got IPv4 local address within 169.254.0.0/16. In Table 2, we picked up the OS which has no IPv6 friendly User Interface. Expires April 18, 2013 [Page 4] INTERNET DRAFTOctober 15, 2012 +---------+----------+----------+----------+----------+ |OS |Version |RA |DHCPv6 |169.254/16| +---------+----------+----------+----------+----------+ |Windows |XP |o |x | | | |Vista |o |o | | | |7 |o |o | | | |8 |o |o | | +---------+----------+----------+----------+----------+ |MacOS X |10.6 |o |x | | | |10.7 |o |o | | | |10.8 |o |o | | +---------+----------+----------+----------+----------+ |Android |1.6 |x |x | | | |2.3.4 |o |x |x | | |2.3.5 |o |x |x | | |2.3.6 |o |x |x | | |4.0.3 |o |x |x | | |4.0.4 |o |x |x | | |4.1 |o |x |x | +---------+----------+----------+----------+----------+ |iOS |4.3.2 JB |o |x |x | | |5 |o |x |x | +---------+----------+----------+----------+----------+ |iPad iOS |5 |o |o | | | |6 |o |o | | +---------+----------+----------+----------+----------+ |kindle |3.1 |x |x | | +---------+----------+----------+----------+----------+ |NetBSD |5.1 |o |x | | | |6.99.4 |o |x | | +---------+----------+----------+----------+----------+ |Ubuntsu |12.0.4 |o |o | | +---------+----------+----------+----------+----------+ Table 1. Result of the client behavior per OS +----------+-----------+--------------+--------------+ |OS |Version |display |configuration | +----------+-----------+--------------+--------------+ |Android |2.3.4 |x |x | | |2.3.6 |x |x | +----------+-----------+--------------+--------------+ |iOS |5 |x |x | +----------+-----------+--------------+--------------+ |iPad iOS |5 |x |x | +----------+-----------+--------------+--------------+ Table 2. List of OS without IPv6 support on User Interface Expires April 18, 2013 [Page 5] INTERNET DRAFTOctober 15, 2012 2.2 Observation on personal device 5 problematic behaviors are observed. (a). failed to set name server(v6) information(WinXP, MacOS SL, Android) (b). failed to input name server(v6) by manual configuration(Android) (c). failed to resolve resource record under (a) or (c) condition(WinXP, MacOS SL, Android) (d). "network setting" won't be completed before getting set of IPv4 information(DNS,router,IPv4 Address)(iOS5,Android) (e). waiting for IPv4 connection timeout(MacOS) The causes of problems on consumer devices are sorted by 3 types. First one is IPv6 implementation issue, which we listed on Table 1. The other issue is User Interface issue, which we listed on Table 2. The last one is coming from other layer's function, typical issue is a WiFi controller which provided by vendor(Lenovo Access Connections) and turn off IPv4 with the controller setting then the client was able to connect to IPv6-only network. Expires April 18, 2013 [Page 6] INTERNET DRAFTOctober 15, 2012 3 Workaround In this document, we focused on the problem which occurred by IPv6 implementation on the clients. How do we solve the problematic behavior? It might be a distant idea that waiting for all devices fully support IPv6. We considered to put additional configuration parameters to comply with improvements. 3.1 trial and result To solve (a)to(e) in Section 2.2, we reconsidered network setting and putting into testbed network step by step. (1) DNS64/NAT64 Map all IPv4 on Internet into IPv6 (2) DHCPv6 for DNS(IPv6) configuration (3) DHCPv4 for IPv4 private address configuration (4) DHCPv4 for DNS(IPv4) and Default Router (actual packet transfer is prohibited on this router) (5) DNS(IPv4) is located local segment (6) DNS(IPv4, IPv6) set 'A' filter (7) DNS(IPv4, IPv6) always returns 'NODATA' with 'A' query (Over both IPv4 and IPv6 transport) (8) AAAA queries forward to DNS64 server Experiment #1: With "IPv4 private address assignment via DHCP4 without Default Router nor DNS", no issues were solved. - Timeout problem exist on MacOSX. - iOS applications are sometimes working,but periodically fails due to retrying Wi-Fi connection. Experiment #2: Put BIND9 forwarder on-link and configure DHCP4/6 to use this DNS. Configure BIND9 forwarder with: deny-answer-addresses { 0.0.0.0/0; }; Which direct no IPv4 address answer should be trusted. It returns SERVFAIL to resolver. - Android is now working: Browser, Twitter, Facebook are OK. - iOS is working: but periodically fails due to retrying. - MacOS is working: but still encountered fallback timeout. - Windows is NOT WORKING: all DNS queries failed due to SERVFAIL. Experiment #3: Hack AAAA filtering code on BIND9 to filter 'A' instead of 'AAAA' both on IPv4/IPv6 transport. Put BIND9 above to local link, which is configured to forward all queries to DNS64. Configure DHCP4/DHCP6 to use the DNS proxy. - Windows, MacOS X, iOS, Android is now working. Expires April 18, 2013 [Page 7] INTERNET DRAFTOctober 15, 2012 - Some of applications still failed on IPv6 only, but many are OK: IE/Safari/Chrome/Firefox, Twitter, Facebook, Instagram, APNS, ... After bringing all new additional network configuration, most of all clients were able to connect IPv6-only network with zero- configuration on the client side. This is the technique for IPv6-only network but also can be useful for terminating IPv4 network environment at the user network. 3.2 remaining issue "Waiting for IPv4 connection timeout on MacOS" is still issued. A possible reason for this connection failure during 1-2 minutes after WiFi connection established is timing of sending RS(Router Solicitation). RS is sent from kernel before Wi-Fi link is established. No IPv6 address is obtained until periodical RA(Router Advertisement) is received. Workaround for this is considered as follows but we were not unable to examine it on the camp at this time. - shorten RA interval to 5-10 seconds (though it disturb Wi-Fi...) - Detect association through AP log and kick RS or RA. 4 Security Considerations Possible security threats are same as what pointed out in original protocols and technologies. 5 IANA Considerations This document has no IANA implications. 6 References 6.1 Normative References [NAT64] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. [DNS64] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011. Expires April 18, 2013 [Page 8] INTERNET DRAFTOctober 15, 2012 6.2 Informative References TBD 7 Acknowledgement Here, we thank to all the participants of WIDE camp(s) on the experiments. We also say thank you to whom serving implementations and services in the Matsuhiro Royal Hotel. Y. Ueno of Keio Univ. for IPv6 L2TP implementation NTT EAST and IIJ for the commercial IPv6 service R. Nakamura of Univ. of Tokyo, Y. Ueno of Keio Univ. and R. Shouhara of Univ. of Tokyo for helping us on the base settings of the IPv6 only experiments and merging into the camp-net. T. Jimei of Internet Systems Consortium for his quick hack on A filter of Bind 9. T. Ishihara of Univ. of Tokyo for his DNS operating advisory Y. Atarashi of Alaxala Networks and R. Atarashi of IIJ Innovation Institute for designing the items of face to face interview and analyzing user survey data. Authors' Addresses R.Hiromi INTEC Inc. 1-3-3, Shinsuna, Koto-ku, Tokyo, Japan EMail: hiromi@inetcore.com Hiroaki Hazeyama NAIST Takayama 8916-5 Nara, Japan Phone: +81 743 72 5216 Email: hiroa-ha@is.naist.jp Atsushi Onoe SONY Corporation EMail: onoe@wide.ad.jp Expires April 18, 2013 [Page 9] INTERNET DRAFTOctober 15, 2012 Osamu Nakamura WIDE Project 5322 Endo Kanagawa, Japan Email: osamu@wide.ad.jp Expires April 18, 2013 [Page 10]