IPv6@HOME
Kuljaree Tantayakul Sinchai Kamolphiwong
Centre for Network Research (CNR) Centre for Network Research (CNR) Centre for Network Research (CNR)
Faculty of Engineering Faculty of Engineering
Prince of Songkla University, Hat Yai, Prince of Songkla University, Hat Yai, Prince of Songkla University, Hat Yai,
Songkhla, THAILAND Songkhla, THAILAND
+6674287397 +6674287367
kuljaree@gmail.com ksinchai@coe.psu.ac.th
ABSTRACT
This paper presents a practical approach to connecting a home
network to the IPv6 world. A number of connection methods have
been proposed and deployed, some suitable for a rich network
environment, e.g. enterprise networks. Home networks are
particularly significant due to the large number of sites. Home
networks are connected via a wide variety of access technologies,
e.g. xDSL, broadband, FTTH, however in general these all use
IPv4 only. Due to the shortage of IPv4 addresses, and the way
they are allocated to home users by service providers, there can be
problems with traditional method of transitional IPv6
connectivity. For example, v4 addresses assigned are often
changed frequently, whereas other providers use NAT and do not
allocate global addresses at all. In this paper we examine those
problems and suggest a possible method to connect a home IPv6
network by implementing existing transition mechanisms in the
home gateway. We also propose an easy way to access all devices
by interoperating with IPv6 Dynamic Domain Name Service
(DDNSv6). The solution is simply and has a low implementation
cost.
Keywords:
IPv6, DDNSv6, IPv6 Transition, home network
1. INTRODUCTION
The Internet requires Internet Protocol (IP) [1] addresses to
identify each host, network device, mobile phone and other
equipment to enable a variety of communications as required
between people, between people and devices, and between
devices. The use of the IPv4 protocol in home networks has
considerably increased the number of hosts that need easy access
to the global Internet. With the rapid growth of the Internet the
IPv4 address space is being depleted, which is causing problems.
This was mitigated by the introduction of Classless Inter-Domain
Routing (CIDR) [5], and reduced even more by the adoption of
Network Address Translators (NAT) [4]. However NAT breaks
end-to-end connectivity, fails for some applications, and reduces
flexibility. Other problems facing IPv4 are the lack of deployed
security, and the rapid growth of the size of the routing tables.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee. The International
Conference on Mobile Technology, Applications & Systems 2008
(Mobility Conference), 10-12 September, 2008, Ilan, Taiwan. Copyright
2008 ACM 978-1-60558-089-0. $5.00.
Touchai Angchuan
Faculty of Engineering
Songkhla, THAILAND
+6674287075, +6674287345
touch@coe.psu.ac.th
The Internet Engineering Task Force (IETF) designed a next
generation protocol, Internet Protocol version 6 (IPv6) [2][3] to
solve these problems, and eventually replace the existing Internet
Protocol, IPv4. However, the migration of IPv4 to IPv6 will not
happen overnight. Rather, there will be a period of transition
when both protocols are in use over the same infrastructure. The
transition will not be easy to achieve because the Internet has a
large number of hosts and network devices. There are many
different hardware architectures, all of which need support for
IPv6 added. Also current software, applications and Operating
Systems (OS) need to be upgraded to support IPv6. Because IPv6
addresses are longer than IPv4 addresses, application data
structures that embed IP addresses need to be changed. Many
current applications written for IPv4 need to be rewritten or
amended to support IPv6.
Currently, the number of hie Internet users is increasing and IP
connectivity is being adopted across a variety of consumer
electronic devices. So the requirement of use Internet at home had
more than one, impact to home user configured advance technique
for using IP connectivity of all devices that configured NAT.
But NAT breaks end-to-end connectivity. Therefore in this paper,
we propose a possible method to deal with the exhaustion of IPv4
addresses. Making the home gateway support an IPv6 kernel
module will allow end-to-end connectivity. Even through we can
upgrade our home gateway to support IPv6, we cannot use it
immediately because service providers (ISPs) in Thailand don't
currently offer IPv6 connectivity. Therefore in this paper, we
have proposed a way to use IPv6 connectivity through the legacy
IPv4 network by implementing a 6to4 tunnel on the home
gateway. We also propose an easy way to connect all devices by
interoperating with dynamic DNS.
In this first section, we have given overview of our work. In
Section II, we describe related work such as IPv4/IPv6 Transition
Mechanisms, and their operation. This includes an overview of
the DNS [11] and describes the observations on the home
network. In Section III, we purpose a possible method designed
for using IPv6 at home. Finally, in the last section, we give the
conclusion of our work and suggest future work.
2. RELATED WORKS
2.1 IPv4/IPv6 Transition Mechanism
Today almost every access network uses IPv4 and the growth of
the Internet has led to the exhaustion of available IPv4 addresses.
IPv6 is a new protocol which has been developed to solve this
problem. A transition from IPv4 to IPv6 in an orderly way is
required. However that will not happen overnight. Rather, there
will be a period of transition when both IP protocols coexist and
communicate over the same infrastructure. The transition is not
easy to accomplish because the Internet has a large number of
hosts and network devices. Hosts and network devices have
different hardware architectures. They must be extended to
support IPv6. Also current software, applications and Operating
Systems (OS) need to be upgraded to support IPv6. Because IPv6
addresses are longer than IPv4 addresses, a change in application
data structures that embed IP addresses is required. In general,
current applications for IPv4 need to be rewritten or upgraded to
support IPv6. Therefore IETF IPv6 Working Group (ngtrans) [10]
has discussed and designed an IPv4/IPv6 Transition Mechanism
for using during the period of transition.
Transition mechanisms are the topic which is discussed by the
IETF IPv6 Transition Working Group (ngtrans) [10]. The main
issue is the transition from IPv4 to IPv6 and how both versions
can coexist before complete migration. It is to be used for a long
time, but not forever. Transition mechanisms can be divided into
three categories as follows: Dual-Stack [6], Tunneling [7] and
Translation. Each category has difference principles and is
suitable for different network environments. The transition
process is complex as it has to deal with issues related to IPv4-
IPv6 interoperability including routing, DNS, error handling, etc.
The types of IPv4/IPv6 Transition Mechanisms can be shown as
in the following sections.
2.1.1 Dual-Stacks
Dual-Stacks [6] are the easiest to implement. Dual-Stacks literally
maintain both IPv4 and IPv6 protocol stacks. This can be
implemented in both hosts and network devices. In hosts, dual-
stack is enabled for applications to operate. Therefore the
applications can choose their protocol stack. IPv4 applications use
the IPv4 stack and IPv6 applications use the IPv6 stack. The
default behavior a dual-stacks host should observe is to DNS
query and attempt to resolve an IPv6 address first and if not
available, it resolves an IPv4 address. Also dual-stack capabilities
in the network devices allow handling of both IPv4 and IPv6
packet types by detection based on the IP header version field.
But dual-stack mechanisms do not solve IPv4 and IPv6
interworking problems. When running dual IPv4/IPv6 stacks, a
host can access to both IPv4 and IPv6 resources. And routers run
both protocols for forwarding the both IPv4/IPv6 packets to the
end nodes or the destination hosts. Figure 1 illustrates dual
Internet protocol stacks.
Figure 1 Dual Internet Protocol Stacks
The Dual-Stacks mechanism is the most widely deployed
transitioning solution. Dual-Stack hosts can communicate with
similar nodes, IPv4-only hosts and IPv6-only hosts. Much more is
required for a complete solution that allows IPv6-IPv4 and IPv4-
IPv6 communications.
2.1.2 Tunneling Mechanisms
Tunneling mechanisms [7] are the techniques were used for
communication between two hosts which have the same protocol
but are separated by a network that uses a different protocol.
For example, when no native IPv6 infrastructure exists between
two points, but there is IPv4 connectivity, tunneling of IPv6 in
IPv4 can be used. This is a very common scenario in the early
stages of the transition process. The tunneling technique provides
communication between IPv6 node and IPv6 node through the
IPv4 infrastructure. The IPv4 infrastructure does not need to be
upgraded to IPv6. IPv6 packets are encapsulated in IPv4 packets
and delivered across IPv4 infrastructure. The tunnel endpoints
must support both IPv4 and IPv6 protocol stacks. This can
configured between border routers or between a border router and
a host. When two IPv6 nodes that are connected by using
tunneling techniques have communication between them, the IPv6
packets are delivered to the tunnel endpoint which supports both
the IPv4 and IPv6 protocols stacks. The tunnel endpoint will
encapsulate the IPv6 packets in IPv4 packets and deliver them
across IPv4 infrastructure to the other endpoint. This endpoint
will decapsulate and send the IPv6 packets to their destination.
The general process of tunneling mechanisms is shown in the
Figure 2.
Figure 2 The general process of Tunneling Mechanism
Table 1 Overview of Tunneling Mechanisms
Tunneling Tunneling IPv4 Tunnel End-point
Type Address
Manual Configured Configuration
tunneling information in the
encapsulation node.
Semi- Tunnel Broker Use dedicated server
automatic which automatically.
IPv4- IPv4-compatible
compatible IPv6 address
 6 over 4 Mapping multicast the process of modifying network address information in
address from IPv6 to datagram packet headers while in transit across a traffic routing
IPv4 device for mapping address space into another.
Automatic 6 to 4 Embedding IPv4
address into the IPv6
prefix. 3. THE OPERATION OF THE PROPOSED
ISATAP Embedding IPv4
address into the IPv6 METHOD
interface ID. The proposed method can be separated to two parts. The first part,
Teredo Uses UDP (port called "IPv6 Home Gateway", was implemented on a broadband
3544) tunneling for router to establish a 6to4 tunnel to 6to4 Relay and send host
NAT traversal. information to a DDNS server when the connection renews or the
public IPv4 address is changed. The second part called "IPv6
2.1.3 Translation Mechanism Home Server" implemented a DNS server and web server to serve
Translation mechanisms use one of many algorithms to convert web-page for registrations of names for each device in the home
between the IPv4 and IPv6 protocols. The translation can occur at network, and also update the IP address of hosts after receiving
several layers in the protocol stack, including the network, the information from the home router.
transport, and application layers. The basic role of translation in
IPv4/IPv6 transition is the conversion of IP and ICMP packets. 3.1 IPv6 Home Gateway
Examples of the translation mechanisms are The Stateless This paper proposes a possible method for the assignment of IPv6
IP/ICMP Translation algorithm (SIIT), Network Address addresses in a home network by using the 6to4 tunneling
Translation Protocol Translation (NAT-PT), Bump-In-the-Stack mechanism. The proposed method can be implemented on
(BIS), Bump-In-the-API (BIA), SOCKS-Based IPv6/IPv4 broadband routers such as Linksys model WRT54GL and Asus
Gateway, and SOCKS64. model WL500GP that use open source firmware (OpenWRT
firmware). The original the broadband routers support the
Wireless-G networking solution. They can be used as Internet-
2.2 Domain Name System sharing routers which have a 4 port switch, and 54Mbps Wireless-
For users, it's difficult and very unpleasant to work with IP G (standard IEEE802.11g) Access Point. Also they share a single
addresses, especially IPv6 addresses. Fortunately, the Domain Internet connection and other resources with Ethernet wired and
Name System (DNS) [11] allows users to work with much more Wireless-G and -B devices. They contain setup features to make
simple symbolic names. The address is obtained by looking it up wireless configuration secure and simple with high security: TKIP
in the DNS, a distributed database containing name-address and AES encryption, wireless MAC address filtering, and a
mappings for each internet domain name. The IPv6 DNS standard powerful SPI firewall. However those features support only the
created two DNS record types each containing 128-bit addresses. IPv4 protocol. To make the broadband router support the IPv6
The first is AAAA or quad A record. It was developed from the A protocol stack, we upgraded the firmware. For this work we
record for IPv4. The second was the A6 record, designed to allow choose OpenWRT's firmware because it is open source firmware
network renumbering, but now obsolete. For this work, we use which uses linux kenel version 2.4 that is easy to edit and modify.
Dynamic DNS which supports dual-stack. Figure 3 shows the concept of the IPv6 at home network.

2.3 Observations on Home Network

Use of the Internet by home users has become common. They
usually only receive one public IPv4 address from their ISP, and
no IPv6. When they want to use many IP devices connect to the
Internet, they must use NAT to enable traffic to communicate
directly. NAT is the process of modifying network address
information in datagram packet headers while in transit across a
traffic routing device for mapping one address space into another.

While NAT allows easy creation of home networks, it has a

downside. Home networks are not directly addressable from the
outside Internet because of NAT's use of non routeable addresses.
As a result, the end-to-end principle is broken. The consequences
of breaking end-to-end by using non routeable addresses include
problems for multi-media services such as VoIP and other widely
enjoyed Internet entertainment, such as some online games. To
allow all devices on a home network to be publicly accessed from
Internet easily, they must enable the IPv6 protocol stack. The Figure 3 The concept of IPv6 at home network
home users normally use Internet at home today. They only
receive one public IPv4 from their ISP, not IPv6. When they want The first step is to upgrade the broadband router by downloading
to use many IP devices connect to Internet, they must specifically new firmware from http://xwrt.kicksass.org/xwrt/firmware_
setup NAT box to enable traffic to communicate directly. NAT is
images/whiterussian/0.9/latest-daily-build/default/ and try to echo " interface br0 { " > $RACONF
upgrade it. To enable 6to4 tunneling, the broadband router must echo " AdvSendAdvert on; " >> $RACONF
support dual-stack and run rdavd daemon for advertisement of the
prefix to hosts in the home network. So the next step is to install echo " MaxRtrAdvInterval 30; " >> $RACONF
two packages, which are "kmod-ipv6" which is the kernel module echo " MinRtrAdvInterval 10; " >> $RACONF
for the IPv6 protocol and "radvd", on the broadband router. After
echo " prefix ${ipv6prefix}:1234::/64 { " >> $RACONF
that use "nvram set br0_eui64=YOUR EUI64" command to set
the EUI-64 value of the br0 interface. Then save it by using echo " AdvOnLink on; " >> $RACONF
"nvram commit" command. Those commands are only used to echo " AdvValidLifetime 300; " >> $RACONF
initialize the value at first installation. Afterwards we generate
andedit the script files for running 6to4 service. Three essential echo " AdvPreferredLifetime 60; " >> $RACONF
script files are "/etc/init.d/tun6to4", "/etc/hotplug.d/iface/10- echo " }; " >> $RACONF
tun6to4" and "/etc/firewall.user".
echo " };
## Restarting radvd daemon
The "/etc/init.d/tun6to4" file was generated to establish the 6to4
tunneling to a 6to4 relay. We can change the 6to4 relay in this /etc/init.d/S51radvd stop
file. It also automatically adds configuration to the sleep 5
"/etc/radvd.conf" file. The file "/etc/hotplug.d/iface/10-tun6to4"
/etc/init.d/S51radvd start
was generated for automatic detection of the new tunnel network
interface. A final script file is "/ec/firewall.user" which was edited
to add the rules to allow protocol 41 (IPv6 protocol) to pass.
/etc/hotplug.d/iface/10-tun6to4
“/etc/init.d/tun6to4” #!/bin/sh
#!/bin/sh [ "$ACTION" = "ifup" ] && [ "$INTERFACE" = "wan" ] &&
/etc/init.d/tun6to4
PATH=/usr/sbin:/sbin:/usr/bin:/bin
br0_eui64=`nvram get br0_eui64`
# Delete former tun6to4 interface /etc/firewall.user
/usr/sbin/ip tunnel del tun6to4 ## -- Allow IPv6 protocol
# Flush IPv6 Address at br0 iptables -A output_rule -p 41 -j ACCEPT
/usr/sbin/ip -6 addr flush dev br0 iptables -A input_rule -p 41 -j ACCEPT
# Add Link Local to br0 iptables -A forwarding_rule -p 41 -j ACCEPT
/usr/sbin/ip -6 addr add fe80::${br0_eui64} dev br0
/usr/sbin/ip -6 addr add fe80::1 dev br0
# 6to4 tunnel When we upgraded firmware and installed the essential packages,
our home gateway supports IPv6 kernel module. After we
wan_if=`nvram get wan_ifname` generated and edited the necessary files, the home gateway
ipv4=`ifconfig $wan_if | cut -f2 -d: | cut -f1 -di i` established 6to4 tunnel to the 6to4 relay and advertised an IPv6
echo $ipv4 > /tmp/ppp-addr.log prefix to other hosts on the home network. However this would
require use of difficult to remember 6to4 addresses of devices, so
ipv6prefix=`echo $ipv4 | awk -F. '{ printf we added another web-page on the OpenWRT web-page on the
"2002:%02x%02x:%02x%02x", \ home gateway for discovery of all MAC addresses of devices that
$1, $2, $3, $4 }'` connect to the home network as showr in Figure 4. We can also
assign a name to each device which will be used to dynamically
## CNR 6to4 relay
update at the DNS server.
relay6to4=202.28.99.195
ip tunnel add tun6to4 mode sit ttl 64 remote any local $ipv4
ip link set dev tun6to4 mtu 1280
ip link set dev tun6to4 up
ip -6 addr add ${ipv6prefix}::1/16 dev tun6to4
ip -6 route add 2000::/3 via ::${relay6to4} dev tun6to metric 1
ip -6 addr add ${ipv6prefix}:1234::1/64 dev br0
## Adding config to /etc/radvd.conf
RACONF=/etc/radvd.conf
 Figure 4 Discovery all MAC addresses on home network.
3.2 IPv6 Home Server
When the connection of the home gateway is restarted, the IPv4
address is changed. The effect is to alter the 6to4 address of each
device. This is because the 6to4 prefix is generated from the IPv4
public address (in hexadecimal) combined with 2002/16. So it's
difficult to connect to a 6to4 device by using the 6to4 addresses.
In this paper, we also propose an easy way to connect and manage
each device by using the interoperation of IPv6 Dynamic DNS
(DDNSv6). Actually the current DDNSv6 service is a
commercial operation, however. it influenced us to build a similar
service by ourselves for ease of use. DDNSv6 is installed upon
Ubuntu 7.10 and uses the Berkeley Internet Name Domain
(BIND) DNS server software version 9.
On the same server, we setup a web server using Apache software
to serve the home users. The registration addresses of each 6to4
device can be done on our web-page at http://homeipv6.net. The
operation between the IPv6 Home Gateway and the DNS server
can be explained in the flowchart shown in Figure 5.
[10] IETF IPv6 Transition Working Group (ngtrans),
[11] M. Crawford,C. Huitema: “DNS extension to support IPv6
Figure 5 The operation between IPv6 Home Gateway and
DNS server.
4. CONCLUSION
In this paper we have described a possible way to enable IPv6
service on home network by using the existing transition
mechanism called 6to4 tunneling on home gateway which
operates with DDNSv6. Using DDNSv6 can solve uncertain IPv4
address assigned problem. The prototype has been built on open
software platform. Some real deployment has been carried out. It
shows that it is simple, effective and low cost solution for IPv6
transition.
5. REFERENCES
[1] J. Postel: “Internet Protocol”, RFC 791, September 1981.
[2] R.Hinden: “IP version 6 Addressing Architecture”, RFC
2373, July 1998.
[3] S.Deering: “Internet Protocol version 6 Specification”, RFC
2460, December 1998
[4] P.Srisuresh: “IP Network Translator (NAT) Terminology
and Considerations”, RFC 2663, August 1999.
[5] Y.Rekhter: “CIDR and Classful Routing”, RFC 1817, Augest
1995.
[6] R.Gilligan: “Transition Mechanisms for IPv6 Hosts and
Routers”, RFC 2893, August 2000
[7] S.Deering : “Generic Packet Tunneling in IPv6
Specification”, RFC 2473, December 1998.
[8] A.Durand : “IPv6 Tunnel Broker”, RFC 3053, January
2001.
[9] B. Carpenter, K.Moore: “Connection of IPv6 Domains via
IPv4 Clouds”, RFC 3056, February 2001
http://www.6bone.net/ngtrans/
address aggregation and renumbering”, RFC2874, July 2000.