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