INTERNET-DRAFT                                                  R.Hiromi
Intended Status: Informational                                Intec,Inc.
Expires: September 12, 2013                                     Hazeyama
                                                                   NAIST
                                                                  A.Onoe
                                                        Sony Corporation
                                                              O.Nakamura
                                                         Keio University
                                                          March 11, 2013


         A workaround for termination of IPv4 network services
                draft-hiromi-sunset4-termination-ipv4-01


Abstract

    After sun-setting of IPv4, many devices will be connected to IPv6
   single stack network. In this document we describe a workaround for
   IPv6 enabled network configuration. At this moment, the condition of
   IPv6 adoption on the consumer devices such as PC, tablet, mobile
   terminal and entertainment device 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
 


<Hiromi, et al.>       Expires September 12, 2013               [Page 1]

INTERNET DRAFT<A workaround for termination of IPv4 ne    March 11, 2013


   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2013 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  Problem Statement . . . . . . . . . . . . . . . . . . . . .  3
     1.3  Test Network  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Variety of devices . . . . . . . . . . . . . . . . . . . . . .  6
     2.1  Device classification . . . . . . . . . . . . . . . . . . .  6
     2.2 Observation on devices . . . . . . . . . . . . . . . . . . .  8
   3  Workaround  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.1 trial and result . . . . . . . . . . . . . . . . . . . . . .  9
     3.2 remaining issue  . . . . . . . . . . . . . . . . . . . . . . 10
   4  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   5  Security Considerations . . . . . . . . . . . . . . . . . . . . 10
   6  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10
   7  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     7.1  Normative References  . . . . . . . . . . . . . . . . . . . 11
   8  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 12









 


<Hiromi, et al.>       Expires September 12, 2013               [Page 2]

INTERNET DRAFT<A workaround for termination of IPv4 ne    March 11, 2013


1  Introduction

    After sun-setting of IPv4, many devices will be 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, 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 several 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  Problem 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.

1.3  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 with 3 patterns of configurations. The pattern A is the
   basic configuration. In the pattern B, DNS64[DNS64]/NAT64[NAT64] is
   located in the User router segment and users refer DNS proxy. In the
   pattern C, DNS64/NAT64 is located in ISP segment.

   We brought above IPv6-only network to seasonal WIDE Camp from 2011 to
   2012[I-D.draft-hazeyama-widecamp-ipv6-only-experience-02]. 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)
   ISP(IPv6):     DHCP-PD or static setting of prefix
 


<Hiromi, et al.>       Expires September 12, 2013               [Page 3]

INTERNET DRAFT<A workaround for termination of IPv4 ne    March 11, 2013


   IPv4 Internet: using coexistence mechanism(4rd,464XLAT,SA46T,
                  DNS64/NAT64) over IPv6, base technology
                  is DNS64/NAT64
   DNS64/NAT64:   Map all IPv4 toward IPv4 Internet into IPv6
   RA:            Enable Other Config flag for DHCP6
   DHCP6:         Distribute DNS64 server address
   DHCP4:         No DHCPv4 running
                  (this is for whom really needs IPv4 connection)
   IPv6 Address Configuration: 
                  SLAAC(address prefix, default router), DHCPv6
                  (DNS server)


Fig.1 Pattern A(Basic Network Topology)

                   +-------------+
                   | IPv6 router |
                   |   on ISP    |
                   +-------------+
                          |
                          |
+--------------- IPv6 Internet ----------------------+
                          |
                          |
                     +---------+
                     | User GW |
                     +---------+
                          |        +--- IPv4 Internet ---+
                          |                 |        |
 +-----+                  |  +--------+ +-------+ +------+
 |DHCP4|                  |  | DHCP6  | | DNS64 | | NAT64|
 +-----+                  |  +--------+ +-------+ +------+
    |                     |      |          |          |
    |                     |      |          |          |
+----------------  /64 prefix segment ---------------------+
                                              |
                                          +--------------+
                                          | user devices |
                                          +--------------+









 


<Hiromi, et al.>       Expires September 12, 2013               [Page 4]

INTERNET DRAFT<A workaround for termination of IPv4 ne    March 11, 2013


Fig.2 Pattern B

                   +-------------+
                   | IPv6 router |
                   |   on ISP    |
                   +-------------+
                          |
                          |
+--------------- IPv6 Internet ----------------------+
                          |
                          |      +--- IPv4 Internet ---+
                   +--------------+     |         |
                   | IPv6 router  |  +-----+   +-----+
                   | on user side |  |DNS64|   |NAT64|
                   +--------------+  +-----+   +-----+
                          |    |        |         |
                          |  +--- /64 prefix segment ---+
                          |
                     +---------+
                     | User GW |
                     +---------+
                          |
                          |
 +-----+ +------------+   |  +--------+ 
 |DHCP4| |DNS Proxy   |   |  | DHCP6  | 
 +-----+ |wt. A filter|   |  +--------+ 
    |    +------------+   |      |      
    |          |          |      |      
+----------------  /64 prefix segment ---------------------+
                                              |
                                          +--------------+
                                          | user devices |
                                          +--------------+















 


<Hiromi, et al.>       Expires September 12, 2013               [Page 5]

INTERNET DRAFT<A workaround for termination of IPv4 ne    March 11, 2013


Fig.3 Pattern C

                                +-- IPv4 Internet --+
                                      |      |
                                  +-----+ +-----+
                                  |DNS64| |NAT64|
                                  +-----+ +-----+
                                     |       |
+--------------- IPv6 Internet ----------------------+
                          |
                   +-------------+
                   | IPv6 router |
                   |   on ISP    |
                   +-------------+
                          |
                          |
+--------------- IPv6 Internet ----------------------+
                          |
                          |
                     +---------+
                     | User GW |
                     +---------+
                          |
                          |
 +-----+ +------------+   |  +--------+ 
 |DHCP4| |DNS Proxy   |   |  | DHCP6  | 
 +-----+ |wt. A filter|   |  +--------+ 
    |    +------------+   |      |      
    |          |          |      |      
+----------------  /64 prefix segment ---------------------+
                                              |
                                          +--------------+
                                          | user devices |
                                          +--------------+


2.  Variety of devices

In this section, we describe what kinds of devices we examined in the
test network.

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
 


<Hiromi, et al.>       Expires September 12, 2013               [Page 6]

INTERNET DRAFT<A workaround for termination of IPv4 ne    March 11, 2013


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 SLAAC/DHCP6 failed if they got IPv4 local
address. In Table 2, we picked up the OS which does not have IPv6
friendly User Interface and could not input IPv6 address manually with
the UI.

Table 1. Result of the client behavior per OS
+---------+----------+----------+----------+----------+
|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         |          |
+---------+----------+----------+----------+----------+






 


<Hiromi, et al.>       Expires September 12, 2013               [Page 7]

INTERNET DRAFT<A workaround for termination of IPv4 ne    March 11, 2013


Table 2. List of OS without IPv6 support on User Interface

+----------+-----------+--------------+--------------+
|OS        |Version    |display       |configuration |
+----------+-----------+--------------+--------------+
|Android   |2.3.4      |x             |x             |
|          |2.3.6      |x             |x             |
+----------+-----------+--------------+--------------+
|iOS       |5          |x             |x             |
+----------+-----------+--------------+--------------+
|iPad iOS  |5          |x             |x             |
+----------+-----------+--------------+--------------+


2.2 Observation on devices

We observed 5 problematic behaviors.

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











 


<Hiromi, et al.>       Expires September 12, 2013               [Page 8]

INTERNET DRAFT<A workaround for termination of IPv4 ne    March 11, 2013


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.
 


<Hiromi, et al.>       Expires September 12, 2013               [Page 9]

INTERNET DRAFT<A workaround for termination of IPv4 ne    March 11, 2013


   - 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  Conclusion

   We determined several network configurations with variety of devices.
    For IPv4 sun-setting, the network should have these capabilities
   described below.

   - Core Network has to connect IPv4 Internet
   - Core Network has to have IPv4 and IPv6 coexistence technology
   - devices can be connected IPv6 only segment
   - IPv4 address assigning protocol should be enabled for IPv6 
     address settings
   - "A filter" on DNS server is effective for terminating IPv4 
     connection trial

5  Security Considerations

   Possible security threats are same as what pointed out in original
   protocols and technologies.


6  IANA Considerations

   This document has no IANA implications.
 


<Hiromi, et al.>       Expires September 12, 2013              [Page 10]

INTERNET DRAFT<A workaround for termination of IPv4 ne    March 11, 2013


7  References

7.1  Normative References


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.


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

   [I-D.draft-hazeyama-widecamp-ipv6-only-experience-02]H. Hazeyama, R.
              Hiromi, T. Ishihara and O. Nakamura, "Experiences from
              IPv6-Only Networks with Transition Technologies in the
              WIDE Camp Autumn 2012", draft-hazeyama-widecamp-ipv6-only-
              experience-02, October 2012.

























 


<Hiromi, et al.>       Expires September 12, 2013              [Page 11]

INTERNET DRAFT<A workaround for termination of IPv4 ne    March 11, 2013


8  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


Osamu Nakamura
WIDE Project
5322 Endo
Kanagawa, Japan
Email: osamu@wide.ad.jp
 


<Hiromi, et al.>       Expires September 12, 2013              [Page 12]

INTERNET DRAFT<A workaround for termination of IPv4 ne    March 11, 2013





















































<Hiromi, et al.>       Expires September 12, 2013              [Page 13]