Problems on IPv4-IPv6 network Transition
Ruri Hiromi Hideaki Yoshifuji
IntecNetCore, Inc.
Hiromi@inetcore.com
Abstract
 IPv6 㧔 Internet Protocol Version 6 㧕 is now
available in various OSs and applications. It is also
deployed in major ISP backbone networks.
Although most of all IPv6 features work as they
were designed, we may have potential problems
with them and they might exist in IPv4-IPv6 dual
stack environment. On the other hand, we don’t
have much opportunities to exchange enough
information about dual stack network operation.
We build a special research group named
“IPv6-Fix”[1] in WIDE Project in Japan to
investigate the potential issues related to IPv6
deployment. We concern about the problems on
IPv4-IPv6 dual stack environment from various
perspectives, such as specification, implementation
and network operation.
From our survey and analysis, we found some
problems to be fixed. In this paper, we show some
error cases taken by harmful specification, poor
implementations and wrong operation.
For the healthy coexistence of IPv4-IPv6, we’ll
share and consider how we should design and
operate dual stack network.
1 Expansion of IPv6 and the “IPv6-Fix”
activity
IPv6(Internet Protocol Version 6) had been
proposed at IETF(Internet Engineering Task Force)
as the next generation of Internet Protocol at early
in the 1990’s and it is now ready for practical use
after trial phase. A lot of applications, such as Web
browser or mail server and client, already support
IPv6. And IPv6 Protocol stack is also available on
many OSs(BSD*, HP-UX, Linux, MacOS, Solaris,
Windows and so on) even if it doesn’t work as
Proceedings of the International Symposium on Applications and the Internet Workshops (SAINTW’06)
0-7695-2510-5/05 $20.00 © 2005 IEEE
Keio University
yoshfuji@wide.ad.jp
default. This shows steady deployment and spread
in use of IPv6.
In the near future the population of IPv6 users will
be increasing more than that of IPv4 users. For the
preparation on the expansion of IPv6, now is the
time to verify the error cases and to fix them.
We build a special research group named
“IPv6-Fix” in WIDE Project in Japan in the end of
2004 and started to investigate the problems on
problematic development of IPv6.[2]
Here we introduce some cases in order to consider
safe and stable deployment of IPv6.
2 Packet Interception
For the communication with other node through
network, the node follows a regular TCP/IP
procedure. But sometimes the normal procedure is
broken by some reason and the node is failed to
connect to the targeted PC.
The considered reasons of this are (1)RA/DHCP
server pretender, (2)unwanted block at Firewall,
(3)inappropriate redirection.
́ Pretend as RA/DHCP Server
This problem caused by insertion of
mis-configured equipments into the network. A
node which is supposed to work as client works as
RA/DHCP server causes confusion in the network.
These problems were sometimes observed at some
kind of conference and fell into confusion of large
amount of attendee.
Network sharing function on an OS is able to
automatically start DHCP (Dynamic Host
Configuration Protocol) server. Once it starts on the
same link even while there is the correct DHCP
server, the clients get incorrect DHCP information
and can’t communicate with other nodes.
If IPv6 interface is activated with enabling
Neighbor Discovery mechanism as server, the node
 will send Router Advertisement message. This also
make the network into disorder and uncontrollable.
A lot of OSs enables to receive RA message and set
their interface addresses so that the impact of this
estimates big.
There are some variations of undesired RA usages,
such as sending RA packet with lifetime=0 option
towards all node on the segment, advertising other
prefix towards all node on the segment, sending
redirect-packet with undesired next hop address,
and so on.
This is not only the case caused in IPv6 Network
but also has in IPv4 network. Because the
mechanism for address auto-configuration function
based on the trust server model has potential
possibilities to make such kind of accident. The
details of this bad usages with a view from the
security consideration describes on RFC3756[4].
́ Interception of ICMP by Firewall
There is possibility of interception of
communication via Firewall.
The data exchange is facilitated by optimized
routing information and appropriate MTU
(Maximum Transfer Unit).
A firewall that blocks control messages such as
ICMP (Internet Control Message Protocol) and
ICMPv6 (ICMP for IPv6) breaks adjustment of
MTU size between the hosts then large-sized
packets won’t be able to be transferred.
A firewall may intercept the packets and the client
has no response from any nodes. “Black hole” by
firewall also has serious problem. Similar situation
might be caused by Transparent Cache.
3 Inappropriate Network Operation
Inappropriate network operation may cause
deterioration of network quality or rouge routing
problems. This group, IPv6-Fix, is produce own
tools to see existence of network troubles. In this
section, we introduce some status reports and point
out future problematic possibilities on network
operation.
́ Instable operation for DNS Server
response
To determine actual numbers of misbehaving DNS
Servers, IPv6-Fix team developed a tool and
surveyed on it. This work carried out with JaPan
Proceedings of the International Symposium on Applications and the Internet Workshops (SAINTW’06)
0-7695-2510-5/05 $20.00 © 2005 IEEE
Registry Service (JPRS) at the use of “JP” domains
list.
This tool simply put well-known host name such
as “www” and “ftp” into each JP domain name and
send queries for it’s A and AAAA RR to checkout
it’s authorized domain name servers.
Table.2 shows the rate of misbehaving DNS server.
From this research, it found that 0.1% of all hosts
have problems.
Table.3 shows the suspected reason of the
problems. From this, the most of misbehaving
caused by “lame delegation”.
This indicates us to keep proper setting of name
zone file is necessary if the widespread diffusion of
IPv6 network environment is coming.
́ Tunnel Network and lack of peer/path
As aspect of deployment of IPv6, it is important it
s service level. To determine the network service
quality, here is a tool. The tool uses mainly ping and
traceroute towards IPv4 and IPv6 dual stack sites to
know RTT(Round Trip Time).
At this moment it is observed that poor
configuring tunnels, experimental tunnel, and lack
of peering/paths at backbone connectivity are
worthless[6].
It is important to conserve network quality in data
transmission. But there are a lot of tunnel
connections for the promotional and deployment
reasons of IPv6. Sometimes those poorly configured,
unconsidered tunnels cause frustration at the end
sites.
For the ISP issue, to keep their network as same as
IPv4 quality, it is important that they have enough
IPv6 peering partners. The problems due to the lack
of peering partners are pointed out by the same
document[6].
Piling up the operational experiences on IPv6 is
also important. We have better to share knowledge
and information from experiences. In order to share
them, some organized party or system would be
necessary as it works same as IPv4 community
network.
4 Unconsciousness on fault tolerant design
At the last topic, move our eyes on
implementations aspect. Bad behavioral
components of IPv6 implementations would
discourage us to use and deploy IPv6.
 ́ Bad TCP Error reaction
The ICMP Errors can be categorized into ether
hard error or soft error.
At connection establishment stage, if a node gets
hard error or reset request from destination node,
the node falls back to connect with the next IP
address. However if a node receives a soft error, it
encounters delay caused by retransmitting. In this
manner, the robustness and quick response conflict
each other. This is common problem for TCP/IP,
not only for IPv6 [4].
The first answer of ICMP soft error is treated as a
hard error then cut the connection is the one
solution for the soft error problem.
For the no reaction at the SYN packet, to shorten
duration on time-out, connect to multiple targeted
hosts at the same time, caching connection status to
connect with assured host.
́ Bad IPv6 address resolution with DNS
For the coexistence of IPv4 and IPv6, applications
should be designed to use the multiple IP addresses
on a host.
In a normal case, if there is no RR for queried
name, DNS server returns “Response Code
0(Normal Termination) “ with empty Answer
Section in general. In order for this㧘the DNS client
can send next other query message at once.
But there are some DNS servers that make
inappropriate response. This kind of ill-behaved
DNS server makes fault in name resolution or it
takes a lot of time in reaction. As for this, user can’t
access a web page or wait for while when using a
web browser. After our survey, there are significant
ill-behaved DNS server program[3].
࡮Ignore queries for AAAA RR
Usual DNS Client program queries for AAAA RR
at first then tries to request following A RR if it is
necessary. Ignorance of queries for AAAA RR
takes longer time until it timed out.
࡮Return “Response Code 3(Name Error)”
“Response Code 3” means there is no RR related
domain name zone. If there are entries for IPv4 in
the name zone file, this response is obviously wrong
behavior. In addition, DNS cache server returns this
code at the queries of IPv4 address for a while.
Proceedings of the International Symposium on Applications and the Internet Workshops (SAINTW’06)
0-7695-2510-5/05 $20.00 © 2005 IEEE
࡮To be a Lame Delegation
Some DNS server returns “non-authoritative
answer” for AAAA RR queries while they have
authorized domain zone settings. A DNS cache
server does not use such server as “lame delegation”
server for a certain period and if DNS cache server
get request from their clients they send back
“Respond Code 2(Server Failure)” then make it fail
for their IPv4 queries.
࡮Return “A RR”
Some DNS server returns a specific A RR at
AAAA RR queries. There is some DNS clients
which use these type-mismatched answer even it
should be discarded. This causes the disconnection
at end hosts.
The action against to these circumstances , there
are 3 ways.
࡮ Set limitation for AAAA RR queries if there is
no IPv6 connectivity.
࡮ It can be work with some modification into
getaddrinfo() library.
࡮ Time adjustment with AAAA RR queries when
the DNS server ignores it.
For example, KAME for FreeBSD distributes like
this;
(1) Send A RR query first then send AAAA RR
query.
(2) Use “max(2T,1) seconds” to set timeout
duration.
5 Mixed disaster – a Hotel Internet
System
Here is an actual case. This case caused by
combination of problems; a wrong implementation
of a DNS client program and unfavorable operation
at a hotel internet service.
́ The Service
This hotel provides the internet access service for
each hotel room. A router-box has been stored in
each room and users just insert their Ethernet cable
into it. Then this rooter-box connects the user to
their portal web site for the accounting confirmation.
After the confirmation of usage agreement, the user
can login into their access control server then the
internet access is available.
́ Get into the network and result

We tried to access from a room by 4 client-PCs
with different OSs(Windows XP SP2, Linux2.6,
MacOS X 10.4.1, FreeBSD5.4-RELEASE) and
monitored the reactions then compared them. All
PCs were enabled IPv6 module. There is no IPv6
connectivity at the hotel network.
The successful behavior was described below.
(1) get into the hotel LAN
(2) get IPv4 private address via DHCP; get
notification of DNS server address
(3) Try to access to the Internet from WEB
browser. Ex.) http://v6fix.net
(4) Send “AAAA RR” query to the name
server(noticed by (2));then get answer with
IPv6 address and discard it because of no
connection of IPv6 then go fall back to IPv4
query; send A RR query to the name server;
finally get IPv4 address.
(5) Try to connect that server with IPv4 address
with port80(http)
(6) The hotel system grabs it’s http request and
insert other HTTP information to redirect to
their portal server.
(7) Send AAAA RR query for the new server to
the name server; then get IPv4 address.
(8) Ignore (7) because of the queried type is
mismatch; then go to request A RR in fallback
to IPv4;get IPv4 Address.
(9) Try to connect the portal address with IPv4
address; the portal page was appeared.
One Client has a problem. The DNS resolver
program remember the wrong answer for AAAA
RR query(In above procedure 8). Then the client
uses the IPv4 address and repeat above (5)-(7) until
someone stop the process.
There was another problem in the hotel system.
The name server always answers specific IPv4
address(A RR) at every queries in any kind of query
type about redirection server’s domain zone. This is
obviously mis-configuration around their zone
settings.
́ Description
In this case, 2 points must be modified.
For the hotel system side, the redirection server’s
name resolution(always answer a specific IPv4
address) is assumed a mis-configuration of the
domain zone setting file at their authorized name
Proceedings of the International Symposium on Applications and the Internet Workshops (SAINTW’06)
0-7695-2510-5/05 $20.00 © 2005 IEEE
server. A wildcard A RR might be caused this kind
of trouble. Or some illegal combinations might be
seen in their configuration. (After this observation,
the target zone file is updated and could not verify
their settings)
For the client side, reconsideration of the
implementation by vendor might be needed.
The solution might be simply ignore the IPv4
Address to the AAAA RR then move to fall back to
send a query for A RR.
6 For the stable network
The duration of the coexistence period of IPv4 and
IPv6 environment might be long so that smooth
transition without necessity of deep knowledge at
averaged users. IPv6 should be transparently
interoperable with IPv4.
In this paper, we introduced some possible
problems on IPv4- IPv6 dual stack environment.
For the last, brief summary of these we pointed out
here listed again.
- Interception by RA/DHCP server
- Interception by Firewall(middle-box)
- instable operation(lame,etc) in DNS zone record
- poor coordinated tunnel network
- lack of path/peering
- Bad TCP reaction
- misbehaving DNS resolution
These problems caused delay and disconnection.
But at the most cases, averaged users do nothing to
solve. We all keep in mind supporting ideal
coexistence of IPv4-IPv6 network.
We keep observation on harmful specification,
poor implementations and wrong operation and will
point out if there is problem. If you see other
problems at IPv4-IPv6 dual stack network, please
contact us to share the information.
 Reference

[1]http://v6fix.net/, <contact@v6fix.net>
[2]Kunitake, K., Shimojyo, T., Jinmei, T., Takeuchi,
S., Cho, K. and Yamamoto, K. : 2004 WIDE Project
Report, pp.499-511(2005).
[3] Morishita, Y. and Jinmei, T. : Common
Misbehavior Against DNS Queries for IPv6
Addresses, IETF RFC4074 (2005).
[4] Nikander, P. Kempf, K. and Nordmark, E. : IPv6
Neighbor Discovery Trust Model and Threats, IETF
RFC3756(2004)
[5]Gont, F. : TCP's Reaction to Soft Errors, IETF
Internet-Draft draft-gont-tcpm-tcp-soft-errors-01.txt
㧔2005㧕.
[6] Cho, K. Luckie, M. and Huffaker, B.:
Identifying IPv6 Network Problems in the
Dual-Stack World, SIGCOMM'04 Network
Troubleshooting Workshop, Portland, Oregon,
U.S.A.㧔2004㧕.

࡮1 BSD is a registered trademark of Berkeley

Software Design, Inc.
࡮ 2 HP-UX is a registered trademark of
Hewlett-Packard Company.
࡮ 3 Linux is a registered trademark of Linus
Torvalds.
࡮4 MacOS is a registered trademark of Apple
Computer, Inc.
࡮ 5 Solaris is a registered trademark of Sun
Microsystems, Inc.
࡮ 6 Windows is a registered trademark of
Microsoft Corporation.
࡮7 FreeBSD is a registered trademark of Walnut
Creek CDROM, Inc.

Proceedings of the International Symposium on Applications and the Internet Workshops (SAINTW’06)
0-7695-2510-5/05 $20.00 © 2005 IEEE