A workaround for termination of IPv4 network services
draft-hiromi-sunset4-termination-ipv4-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Ruri Hiromi , Hiroaki Hazeyama , Atsushi Onoe , Osamu Nakamura | ||
| Last updated | 2012-10-25 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hiromi-sunset4-termination-ipv4-00
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
<Hiromi, et al.> Expires April 18, 2013 [Page 1]
INTERNET DRAFT<A workaround for termination of IPv4 network services>October 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
<Hiromi, et al.> Expires April 18, 2013 [Page 2]
INTERNET DRAFT<A workaround for termination of IPv4 network services>October 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 |
<Hiromi, et al.> Expires April 18, 2013 [Page 3]
INTERNET DRAFT<A workaround for termination of IPv4 network services>October 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.
<Hiromi, et al.> Expires April 18, 2013 [Page 4]
INTERNET DRAFT<A workaround for termination of IPv4 network services>October 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
<Hiromi, et al.> Expires April 18, 2013 [Page 5]
INTERNET DRAFT<A workaround for termination of IPv4 network services>October 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.
<Hiromi, et al.> Expires April 18, 2013 [Page 6]
INTERNET DRAFT<A workaround for termination of IPv4 network services>October 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.
<Hiromi, et al.> Expires April 18, 2013 [Page 7]
INTERNET DRAFT<A workaround for termination of IPv4 network services>October 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.
<Hiromi, et al.> Expires April 18, 2013 [Page 8]
INTERNET DRAFT<A workaround for termination of IPv4 network services>October 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
<Hiromi, et al.> Expires April 18, 2013 [Page 9]
INTERNET DRAFT<A workaround for termination of IPv4 network services>October 15, 2012
Osamu Nakamura
WIDE Project
5322 Endo
Kanagawa, Japan
Email: osamu@wide.ad.jp
<Hiromi, et al.> Expires April 18, 2013 [Page 10]