ipv6_report

Department of Teleinformatics Network Services
Royal Institute of Technology Telia Research AB
,3Y#KRPH
A study on using IPv6 in home networks
A master thesis by
Christer Engman (e94_cen@e.kth.se)
Stockholm, Sweden
1999

IPv6@home
iii
$%675$7
The Internet has expanded enormously over the last few years. The development of new
services and the discovery of new application areas continue as the Internet gains inter-
est. Today, broadband Internet connections are spreading and connecting increasingly
more people at their homes. However, this expansion may require a prominent upgrade
of today’s Internet.
This thesis explores how the next generation Internet protocol, IPv6, may be introduced
in a home network environment. IPv6 is expected to eventually replace the current proto-
col, IPv4, since it provides many enhancements and new features of which many are ideal
for using in a home network.
The report includes a description of the home networking concept and a brief description
of IPv6 followed by a study that shows that home networking really could benefit from the
new features provided by the new protocol. Also described are the various transition
mechanisms required for IPv4 and IPv6 to coexist side by side during the introduction.
Finally, experiments conducted in a fictive home network is documented and analyzed to
show how some of the IPv6 features work in practice and how they are configured. The
experiments also revealed the current shortage of IPv6 implementations, which was quite
surprising.

IPv6@home
v
7$%/( 2) 217(176
1 INTRODUCTION...................................................................................................................1
1.1 BACKGROUND....................................................................................................................1
1.2 REPORT STRUCTURE ..........................................................................................................1
2 HOME NETWORKING ........................................................................................................3
2.1 VISION ...............................................................................................................................3
2.2 EXAMPLES..........................................................................................................................4
2.2.1 Residential Gateway (Telia)......................................................................................4
2.2.2 E-box (Ericsson)........................................................................................................4
2.3 LIMITATIONS TODAY .........................................................................................................5
3 IPV6 OVERVIEW ..................................................................................................................7
3.1 IPV6 HEADER FORMAT ......................................................................................................7
3.2 ICMPV6.............................................................................................................................8
3.3 ADDRESSING ......................................................................................................................8
3.3.1 Address Notation .......................................................................................................8
3.3.2 Address Assignment.................................................................................................10
3.3.3 The IPv6 Address Space..........................................................................................10
3.3.4 Unicast Addresses ...................................................................................................11
3.3.5 Multicast Addresses.................................................................................................12
3.3.6 Anycast Addresses ...................................................................................................13
3.3.7 Domain Name System (DNSv6)...............................................................................14
3.4 AUTOCONFIGURATION .....................................................................................................14
3.4.1 Mechanisms.............................................................................................................14
3.4.2 Procedure................................................................................................................14
3.5 REAL-TIME SUPPORT........................................................................................................15
3.5.1 Flows .......................................................................................................................15
3.5.2 Traffic Class ............................................................................................................15
3.5.3 Jumbograms ............................................................................................................15
3.6 MOBILITY.........................................................................................................................16
3.7 SECURITY.........................................................................................................................16
4 USING IPV6 AT HOME ......................................................................................................19
4.1 ADDRESSING ....................................................................................................................19
4.1.1 Node Naming...........................................................................................................19
4.1.2 Eliminating the NAT................................................................................................20
4.1.3 Choice of Service Provider......................................................................................20
4.2 PLUG AND PLAY...............................................................................................................21
4.2.1 Installing Devices....................................................................................................21
4.2.2 Mobile Devices........................................................................................................21
4.3 MULTIMEDIA....................................................................................................................22
4.3.1 Convergence............................................................................................................22
4.3.2 Quality of Service ....................................................................................................22
4.3.3 Broadcasting Media ................................................................................................22
4.3.4 Hierarchical Transmission......................................................................................23
4.4 SECURITY.........................................................................................................................24
5 INTRODUCING IPV6 TODAY ..........................................................................................25
5.1 TRANSITION STRATEGY ...................................................................................................25
5.2 TRANSITION ISSUES..........................................................................................................26
IPv6 Addressing ......................................................................................................................27
5.2.2 IPv4 Connectivity ....................................................................................................27
5.2.3 IPv6 Connectivity ....................................................................................................30
5.2.4 Old Applications......................................................................................................30
5.3 IMPLEMENTATION STATUS...............................................................................................31

IPv6@home
vi
6 EXPERIMENTAL SETUP.................................................................................................. 33
6.1 GOAL............................................................................................................................... 33
6.2 SCENARIO........................................................................................................................ 33
6.3 EXPERIMENTS.................................................................................................................. 33
6.3.1 Hardware and OS ................................................................................................... 33
6.3.2 IPv6 Support ........................................................................................................... 34
6.3.3 Connectivity check .................................................................................................. 35
6.3.4 DNS......................................................................................................................... 35
6.3.5 Router Advertisements ............................................................................................ 36
6.3.6 IPv6 connectivity..................................................................................................... 37
6.3.7 Transition mechanisms ........................................................................................... 37
7 RELATED INITIATIVES................................................................................................... 41
7.1 JINI ................................................................................................................................. 41
7.2 UNIVERSAL PNP .............................................................................................................. 41
8 CONCLUSIONS................................................................................................................... 43
9 FUTURE WORK.................................................................................................................. 45
10 REFERENCES.................................................................................................................. 47
APPENDIX A AUTOCONFIGURATION PROCESS........................................................... 49
APPENDIX B IPV6 IMPLEMENTATION STATUS ............................................................ 50
COMPANIES SUPPORTING IPV6 .................................................................................................... 50
IPV6 STACKS............................................................................................................................... 50
APPLICATIONS ............................................................................................................................. 50
TRANSITION MECHANISMS.......................................................................................................... 50
APPENDIX C EXPERIMENTAL SETUP DETAILS............................................................ 51
NODE DETAILS............................................................................................................................. 51
INTERFACE DUMPS....................................................................................................................... 51
Linux....................................................................................................................................... 51
Windows 2000......................................................................................................................... 52
APPENDIX D ACRONYMS..................................................................................................... 53

IPv6@home
1
,1752'87,21
%DFNJURXQG
The Internet was originally used as a minor message handling system restricted to small
research labs or campuses. Today, the Internet is the fastest growing media for distribut-
ing information and has already become a potential alternative to traditional information
channels such as magazines, television, radio and telephony. The Internet has also be-
come a vital part of many companies’ business strategies, which depends, partly or en-
tirely, on their Internet customers.
Geographically, the Internet already spans across the globe and interconnects the majority
of all countries with high capacity fibers. However, when investigating the “leaf nodes”
of the network topology we find that the facilities with high-speed connections are lim-
ited to research labs, universities and bigger companies. Users sitting at home may also
connect to a nearby server, but that connection is often a low-speed dial-up connection
using a modem. These connections are also made on a temporary basis, as they tend to
last no more than a couple of hours at a time. Now the Internet continues to grow with
broadband Internet access to the homes through alternative techniques such as the cable
TV network. When this phase is completed, the Internet will reach far more people than
today, and the usage of the net is expected to literally explode. New applications and
habits will be developed and the Internet will be part of everyone’s life, just as TV and
radio are today.
However, the Internet expansion will not stop there. Future homes will contain many
electronic devices and appliances, of which a substantial part will feature network con-
nectivity. The “home LAN” is born where an in-house network is used to interconnect all
of these devices and appliances, and finally connect them to the Internet. The market of
“home networking” is predicted to be enormous. Just think of the endless kinds of de-
vices and applications, which will be suitable for, or completely dedicated to, the home
network market. Surveillance, home automation, resource sharing and information re-
trieval are just a few examples.
This change in Internetworking was impossible to predict when the original Internet was
built in the early 70’s. The protocol used for transporting the information through the
network has ever since been the same Internet Protocol version 4 – IPv4. Now this is
about to change. The growth of the Internet and the new demands from new applications
requires the protocol to be upgraded with additional support for features such as scalabil-
ity, multimedia, mobility and security. Therefore, the development of a new Internet
protocol was started in 1992. The new protocol, Internet Protocol version 6, IPv6, will
eliminate most of today’s limitations, but not without a cost. Existing routers, hosts and
applications will be incompatible with IPv6 and therefore have to be upgraded. This tran-
sition period is estimated to span over multiple decades, and during that time IPv4 and
IPv6 will coexist side by side. Is it worth the upgrade? When should the upgrade begin?
Where should we start? The questions are rising, and the search for answers can begin…
5HSRUW 6WUXFWXUH
The scope of this report is limited to the home network and its closest surroundings. The
goal with the report is to match the demands of home networking with the features that
IPv6 provide. A brief analysis of how IPv6 may be introduced is also within the scope of
the report.

IPv6@home
2
The report is introduced with theoretical overviews of the home networking concept and
IPv6 in Chapter 2 and 3 respectively. If you have great understanding in either of these
areas, you can easily skip the corresponding chapter.
The central part of the report is located in Chapter 4. Here, the combination of home net-
working and IPv6 is analyzed by matching demands with features. The grouping in this
chapter is based on the demands present in a home network rather than the features pro-
vided by IPv6 to emphasize the focus on home networking. Real world examples and
terms are used to make the discussion concrete help the reader to get a greater under-
standing.
Chapter 5 is dedicated to the transition from IPv4 towards IPv6. The introduction of IPv6
will meet many obstacles since it is not compatible with IPv4 and therefore requires up-
grade of both hosts and routers. Several transition mechanisms are covered and compared
side by side to clarify the difference between them regarding availability, requirements
and features.
Next, Chapter 6 presents the results I gained from my practical experiments conducted in
a fictive home network environment. Features and mechanisms described earlier in the
report are verified and visually presented in the form of “packet dumps”.
Finally, the Chapters 7, 8 and 9 include a short description of research topics related to
the report together with conclusions and suggestions to further investigate the possibili-
ties with IPv6.

IPv6@home
3
+20( 1(7:25.,1*
9LVLRQ
With today’s cheap PCs, it has become increasingly common to find multiple computers
within a single household. Maybe there is one in the home office connected to the corpo-
rate LAN through a modem and to a printer. Another computer may reside in the teen-
ager’s room equipped with state of the art multimedia devices and a scanner. A third
computer could be found in the children’s bedroom, mainly used for computer games and
educational applications. Now, what if one would like to use the scanner to scan an image
into an educational application and then print it out on the printer. Alternatively, if every-
one want to be able to access the Internet through the modem connection in the home
office?
The solution to these problems is to interconnect the three computers making a local area
network in the home – a home LAN or home network. This enables resource sharing,
which will become even more important in a near future with increasing varieties of net-
work aware products and appliances. Probably future home electronics will be intercon-
nected enabling new interesting possibilities of accessing everything wherever you are,
whenever you are there. For example, one could pop in a CD in the player located in the
living room and then continue listening to it through the speakers in the kitchen while
preparing dinner.
Access Network
Home Server
Home Network
Figure 2.1 A typical home network scenario.
Besides communicating locally on the home network, users probably want to be able to
access common networks such as the Internet, as stated earlier. In the 1960s, the Internet
was only accessible to a few academic scientists in their labs. The Internet grew beyond
the lab boundaries and soon universities and commercial companies could get access. The
next natural step in this evolution is to get the broadband Internet access into the house-
holds and make it as common as today’s telephone and TV distribution mediums. A fast
connection to the Internet is believed to be one of the driving forces to establish the home
networking concept.
Another important aspect of home networks is home automation. This concept will give
you the ability to control and monitor your house, even if you are not at home by con-
necting to your home network from your office, your car or from the airplane on your
way to Hawaii! It will also be possible to create “smart” houses by letting the house take

IPv6@home
4
advantage of sensors distributed over the house, and use them to adjust parameters such
as heat, light and humidity.
With hundreds of millions of households in the world, the home network market is enor-
mous and will definitely involve many companies in the future. Both hardware and soft-
ware vendors will have lucrative possibilities. Many experts believe that the home net-
work market will explode in the next couple of years, which drives the development of
the architecture faster than ever before.
The possibilities and applications for home LANs seems endless but are beyond the scope
of this report. More information about home networking can be found in any of the nu-
merous reports or articles written in this topic.
([DPSOHV
2.2.1 Residential Gateway (Telia)
At Telia Research AB, home networks are a hot topic in research projects. The develop-
ment has brought the concept with a home server called Residential Gateway (RG). An
RG is placed between the access network and the home LAN in each home and acts as a
border gateway to the home LAN. It also acts as a communications central featuring mul-
tiple connectivity interfaces such as Ethernet or IEEE 1394 (Firewire) for Internet access,
POTS for analog telephony and LonWorks for home automation.
A user may access the RG through a web interface which lets the user configure its home,
both from inside the home LAN and remotely. Besides web server software, the RG con-
tains firewall and routing software to provide Internet access.
2.2.2 E-box (Ericsson)
Ericsson also wants to take part in the home network market. Their contribution is a home
server similar to the RG called the e-box. The e-box provides much the same functionality
as the RG, except for the POTS connectivity. It is however equipped with two I/O-slots,
which can be fitted with various interface cards to expand connection possibilities.
Today, the e-box is already available as a prototype to the market. Despite the lack of IP
enabled appliances, this is an important step to show the customers where the develop-
ment is leading.
Figure 2.2 Telia’s RG and Ericsson’s e-box

IPv6@home
5
/LPLWDWLRQV 7RGD
Home networking is still a vision. Many companies and research labs are involved in the
development and have already presented working prototypes and solutions suitable for
home LANs. However, there are limitations with today’s technologies which delays fur-
ther development in several areas.
ƒ Price. A home server must be cheap to be appealing to customers. This is a major
problem with the prototypes of both the RG and the e-box. However, the price will
eventually decrease when mass production begins.
ƒ Bandwidth. To be able to serve a household’s demands on bandwidth through the
connection to Internet, new technologies such as xDSL or cable modems have to be
commercially available in a large scale. For a complete home LAN solution, it
should be possible to distribute high-quality audio and video over the network.
ƒ Wiring. To connect the future devices and appliances in your home you will need
some sort of medium in between, which is able to transmit data. Today most of-
fices are equipped with Ethernet LAN cabling or some other link-level architecture.
This is not the case with regular residences, which therefore may need rewiring.
There are, however, multiple solutions for this already. For example, different
techniques for communicating over the existing telephone wiring such as the
HomePNA type of technologies, or by using wireless communication solutions
such as Lucent’s WaveLAN. It has also been proven that even the mains can
transmit limited amounts of data without problem.
The development in overcoming the problems mentioned above has come far the last few
years, which should help to eliminate them in a near future. However, even without those
problems it would be hard to achieve the home networking vision due to the current
limitations of the Internet protocol, which is responsible for all data transfers over the
Internet. The current version of the Internet protocol (IPv4) was simply not designed with
home networking in mind. It lacks desired functionality such as security, bandwidth allo-
cation (QoS) and easy administration and configuration.
In the following, the new Internet Protocol version 6 (IPv6) will be studied as an alterna-
tive to today’s IPv4. After an overview of the protocol, the scenario of using it in a home
network environment will be covered.

IPv6@home
7
,39 29(59,(:
The Internet Protocol version 6 (IPv6) has been developed to replace today’s Internet
Protocol version 4 (IPv4). IPv4 has its roots in the early 1970s when the Internet con-
sisted only of limited research networks. The new protocol has been in development since
1992 when network experts realized that the nature of the Internet had changed and was
in the need of a prominent upgrade.
The new protocol brings new functionality and higher performance into internetworking
in several aspects. When designing IPv6, much research was made to assure that IPv6
would handle the expected growth of the Internet and all the new services that will follow
with it.
In this chapter, IPv6 features related to home networking will be briefly described. For
further information, please refer to the referenced sources. For application examples and
usage, refer to Chapter 0.
,3Y +HDGHU )RUPDW
IPv6 introduces many enhancements to IPv4. To begin with, the IP header format has
changed from a variable sized header with 12 fields and options into a fixed size 40-byte
header containing only eight fields as shown in Figure 3.1. Although the IPv6 header is
bigger measured in bytes, the slimmed structure with only eight fields together with the
fixed size provides for easier implementations and higher performance in hosts and
routers.
Figure 3.1 Header format in IPv4 and IPv6
In brief, the following changes has been made [15]:
ƒ The Type of Service field (ToS) has been replaced by the Traffic Class field, which
together with the new Flow Label field provides for prioritized traffic and Quality
of Service (QoS). Further described in Section 3.5.
ƒ Time to Live (TTL) has been replaced by the Hop Limit field, which more cor-
rectly states its meaning.
ƒ The header checksum in IPv4 has been completely removed since error checking in
most cases still is performed in the other network layers. This gives a major per-
formance boost for routers and firewalls since they don’t have to recalculate a
checksum when something in the header is changed (such as TTL or the
source/destination address).
Options
Ver IHL ToS Total Length
Identification Flags Fragment Offset
TTL Protocol Header Checksum
Source Address
Destination Address
Ver Traffic Class Flow Label
Payload Length Next Header Hop Limit
Source Address
Destination Address
3116150 3116150

IPv6@home
8
ƒ Fragmentation Offset and the Options fields have been completely removed from
the IPv6 header. Instead, this information is put into separate extension headers in-
serted between the IPv6 header and the payload in a daisy-chain fashion as shown
in Figure 3.2. Each extension header has a next header field, which specifies the
type of the following header. The technique makes the handling of extra options
and special delivery cases more slimmed, and provides for easy future expansions
with new headers types.
Figure 3.2 Daisy-chaining of extension headers in IPv6.
,03Y
IPv6 uses the Internet Control Message Protocol version 6 (ICMPv6) defined in [12],
which is a further development of the ICMP, available in IPv4. The changes include re-
moval of seldom-used messages and the introduction of Internet Group Management
Protocol (IGMP) messages used for joining and leaving multicast groups. ICMPv6 is also
used for diagnostics (i.e. ping) and autoconfiguration (further described in Section 3.4).
Table 3.1 shows the ICMPv6 messages currently defined:
Table 3.1: Defined ICMPv6 messages
ID Message
1 Destination Unreachable
2 Packet Too Big
3 Time Exceeded
4 Parameter Problem
128 Echo Request
129 Echo Reply
130 Group Membership Query
131 Group Membership Report
132 Group Membership Reduction
133 Router Solicitation
134 Router Advertisement
135 Neighbor Solicitation
136 Neighbor Advertisement
137 Redirect
$GGUHVVLQJ
IPv6 introduces 128-bit wide addresses instead of the 32 bits used in IPv4. With 128 bits
it is theoretically possible to assign approximately 665,985,621,475,071,937 IP addresses
per square millimeter of the earth’s surface, thus the lack of IP addresses seems to be
solved! However, in practice the gigantic address space will be used to introduce a more
hierarchical address structure than the one present in IPv4. A hierarchical structure will
also optimize routing in the networks since routers then don’t have to examine the whole
address.
3.3.1 Address Notation
Plain old IPv4 addresses are written in “four dotted decimal” form as in
192.168.0.1
IPv6
Header
Fragmentation
Header
TCP
Header
Payload Fragment
…

IPv6@home
9
With 128 bits instead of 32 bits, this notation would require 16 decimal integers to form
an IPv6 address, which could be quite troublesome to handle. Instead, IPv6 addresses are
written as eight groups of hexadecimal 16-bit words separated by colons as in these two
examples:
FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
FE80:0000:0000:0000:0200:F8FF:FE22:26C8
By using hexadecimal digits, this form is somewhat shorter than using decimal ones. Still,
writing IPv6 addresses like these can be very tedious. To reduce the notation further, the
specification introduces some simplifications.
There will likely be many zeros in the addresses because of the big address space avail-
able. By removing leading zeros in the words and thereby replacing words like 0200 with
200, the address is shortened. Furthermore, words consisting entirely of zeros (0000)
may be replaced by a double colon (::). A double colon can represent one or more adja-
cent words of this kind and can therefore simplify the notation further. The second ad-
dress above in compressed form now reads
FE80::200:F8FF:FE22:26C8
This is the common way of writing IPv6 address and will be used in the rest of this re-
port. To expand the compressed address you only need to align whatever is left to the
colons to the left, the rest to right and then pad with zeros. It is not possible to use multi-
ple double colons to replace zeros since that makes the expansion ambiguous.
There is also a convenient form of writing IPv6 addresses derived from an IPv4 address.
Such addresses may be expressed as a six hexadecimal groups followed by the plain old
“four dotted decimal” form:
0:0:0:0:0:0:192.168.0.1
In compressed form, the address becomes very easy to handle:
::192.168.0.1
Besides addresses assigned to individual hosts, IPv6 introduces address prefixes. An ad-
dress prefix is similar to the network prefix used in IPv4 and is used in the same way (for
more information, please refer to Section 3.3.3). The address prefix is denoted as an IPv6
address followed by a slash and the prefix length in bits. The following examples show
the same prefix written in three different ways:
3FFE:0000:0A12:1200:0000:0000:0000:0000/60
3FFE::A12:1200:0:0:0:0/60
3FFE:0:A12:1200::/60
Even if only the 60 firsts bits are interesting, the following notations is NOT legal (the
faulty expansion is shown for each prefix accordingly):
3FFE::A12:1200/60 →
3FFE:0000:0000:0000:0000:0000:0A12:1200/60 =
3FFE::/60
60 bits

IPv6@home
10
3FFE:0:A12:120::/60 →
3FFE:0000:0A12:0120:0000:0000:0000:0000/60 =
3FFE:0:A12:0120::/60
3.3.2 Address Assignment
IPv6 addresses are assigned to interfaces such as Ethernet NICs, PPP virtual interfaces
and so on. However, an interface is not limited to one single address as in IPv4, but can in
fact have an infinite number of addresses assigned to it. This is very useful for separating
different kinds of network traffic over the same interface.
3.3.3 The IPv6 Address Space
The IPv6 address space is gigantic! Going from 32 to 128 bits wide addresses means a
drastic increase in addresses available. Moreover, the 128 bits not only makes it possible
to assign billions of billions of hosts, but also provides for a greater hierarchical structure
than the network, subnetwork and host layers defined in IPv4.
In the top level of hierarchy in the IPv6 address space, different address types are defined.
Each type has its own address subspace identified by an address prefix similar to those
used in Classless Inter-domain Routing (CIDR). Table 3.2 below shows the initial alloca-
tion defined in [17]. The table shows the named allocation together with its corresponding
prefix followed by the fraction of the address space it allocates.
Table 3.2 Initial allocation of address prefixes.
Allocation Prefix
(binary)
Prefix
(hex)
Fraction of
address space
Reserved 0000 0000 ::/8 1/256 (0.4%)
Unassigned 0000 0001 100::/8 1/256
NSAP Allocation 0000 001 200::/7 1/128 (0.8%)
IPX Allocation 0000 010 400::/7 1/128
Unassigned 0000 011 600::/7 1/128
Unassigned 0000 1 800::/5 1/32 (3.1%)
Unassigned 0001 1000:/4 1/16 (6.3%)
Aggregatable Global Unicast Addresses 001 2000::/3 1/8 (12.5%)
Unassigned 010 4000::/3 1/8
Unassigned 011 6000::/3 1/8
Unassigned 100 8000::/3 1/8
Unassigned 101 A000::/3 1/8
Unassigned 110 C000::/3 1/8
Unassigned 1110 E000::/4 1/16 (6.3%)
Unassigned 1111 0 F000::/5 1/32 (3.1%)
Unassigned 1111 10 F800::/6 1/64 (1.6%)
Unassigned 1111 110 FC00::/7 1/128 (0.8%)
Unassigned 1111 1110 0 FE00::/9 1/512 (0.2%)
Link-Local Unicast Addresses 1111 1110 10 FE80::/10 1/1024 (0.1%)
Site-Local Unicast Addresses 1111 1110 11 FEC0::/10 1/1024
Multicast Addresses 1111 1111 FF::/8 1/256 (0.4%)

IPv6@home
11
As indicated in the table, more than 70% of the address space remains unassigned. These
unassigned prefixes can later be replaced by additional existing address types (e.g. more
multicast or aggregatable addresses) or with new ones. There are already plans to include
a geographically based address scheme where the address maps directly to a geographical
position and vice versa.
3.3.4 Unicast Addresses
A unicast address identifies a single interface, and packets sent to a unicast destination
address are delivered to that unique interface alone. IPv6 includes different subtypes of
unicast addresses.
Aggregatable Unicast Addresses
Aggregatable Global Unicast Addresses is a hierarchically structured addressing scheme
intended to be the initially used assignment plan for IPv6 nodes [18]. This address format
is designed to optimize high-speed routing in the core networks of the Internet by intro-
ducing a multi-level address topology divided into Public, Site and Interface topologies.
The address format is as follows:
The address format consists of four ID fields for a four level hierarchical structure:
ƒ Top-Level Aggregation Identifiers (TLA ID) used in the top level in the routing hi-
erarchy.
ƒ Next-Level Aggregation Identifiers (NLA ID) used by organizations.
ƒ Site-Level Aggregation Identifiers (SLA ID) which corresponds to today’s subnets
in IPv4.
ƒ Interface ID, which specifies a single interface of an IPv6 host.
There is also a reserved field (RES) to provide future expansion of the TLA and/or NLA
fields.
Local addresses
IPv6 defines three types of addresses for local use only – that is IP packets containing
local source or destination addresses are limited to physical area. Local packets are never
routed outside this local area.
The Loopback address, 0:0:0:0:0:0:0:1 (or ::1), is referring to the virtual interface
built-in into every IPv6 host for host-local communication. It has the same functionality
as the localhost interface (127.0.0.1) in IPv4.
Link-local addresses are used for communication over a single link or segment in an IPv6
network. In reality this could mean a single household, a small office or just two hosts
directly connected to each other. Every IPv6 interface is required to have at least one
link-local address assigned and automatically assigns itself one at boot time. How this
Site
Topology
Interface ID001 TLA ID
64 bits3
RES NLA ID SLA ID
13 8 24 16
Public Topology Interface Topology

IPv6@home
12
assignment is done depends on the underlying media (i.e. Ethernet, ATM, IEEE 1394
etc.).
A link-local address is constructed by the prefix FE80::/10 and a 64-bit interface ID
padded with 54 bits of zeros in between:
Link-local addresses are heavily used in IPv6’s autoconfiguration procedures as will be
shown in Section 3.4.
Site-local addresses are designed to let sites with multiple links or segments communicate
locally without the need for a global prefix. This could be the case for an isolated corpo-
rate network or residential area without the need of global communication.
The structure of the site-local address is similar to the link-local, except for the new pre-
fix FEC0::/10 and a new field for subnet ID.
3.3.5 Multicast Addresses
A multicast address is used to send packets from one source to multiple destinations. IPv6
will make multicasting a more common way of communicating since every IPv6 router is
required to handle multicast routing.
An IPv6 multicast address consists of the address prefix 11111111 (FF::/8) followed
by some flags, the scope of the multicast and finally an identifier for the multicast group:
In the flags field, the fourth bit indicates if the multicast address is transient or not. Tran-
sient addresses are constructed for temporary multicasting sessions such as a videocon-
ference while a non-transient address is reserved for special pre-registered services. For
example, the multicast group FF02::1 refers to all nodes on the current link, and
FF02::2 refers to all routers. For a complete list of registered multicast addresses, please
refer to IANA’s web page [2].
The scope field tells how far the packets sent to the multicast group may be routed in
some sense of routing distance. In IPv4 the TTL field in the IP header is used to limit the
scope. IPv6 provides a much more precise definition closer related to real world bounda-
ries. This requires however that the routers are configured to know their location and to
which areas they belong. Table 3.3 shows the currently assigned scope values defined in
[17].
Interface ID1111111010 0
64 bits54 bits10 bits
Interface ID1111111011 Subnet ID
0
16 bits
11111111
Flags Scope
4 bits
Group ID

IPv6@home
13
Table 3.3 Multicast scopes
Value Definition Scope
0 Reserved
1 Node-local scope
2 Link-local scope
5 Site-local scope
8 Organization-local scope
E Global scope
F Reserved
The “missing” values are currently unassigned and are available to network administra-
tors to define themselves. In the concept of home networking, these could represent addi-
tional geographical hierarchies, e.g. “National scope”, “Continental scope” and so on.
Finally, the group identifier in the address distinguishes a multicast session within the
current scope. In IPv6, multicast is considered as a common type of communication,
which is not the case with IPv4. This can be easily conceived by looking at the 112-bit
wide group identifier in IPv6 compared to the 28 bits available in the IPv4 class D ad-
dresses. For example, multicasts in IPv6 replace broadcasts in IPv4.
3.3.6 Anycast Addresses
Anycasting is new feature introduced with IPv6. An anycast address is an IPv6 address
assigned to multiple interfaces, often belonging to separate nodes. The anycast addresses
are indistinguishable from unicast address and may use any unicast address assignment
scheme. Packets sent to an anycast address are received by the interface closest to the
sender, in means of the routing protocols’ measure of distance. Figure 3.3 shows a simple
example with two hosts (A and C) both specifying B as their destination address. The
actual server requested depends on the network topology since the shortest route is cho-
sen.
Figure 3.3 Anycasting in IPv6
Anycasting could be used for load balancing between multiple DNS, web or database
servers. Fuzzy routing is another feature possible with anycast addresses where the sender
specifies that the packets should be routed through any router in a specified network.
Since anycasting is quite new to the Internet world, it is still a topic for research and new
applications are evolving continuously
A
B
B
C

IPv6@home
14
3.3.7 Domain Name System (DNSv6)
DNS extensions to support IPv6 have been proposed in [31]. The extensions include a
new record type for IPv6 addresses called AAAA and a new DNS domain for the IPv6
address rooted as IP6.INT. Thereby, an IPv6 address such as
4321:0:1:2:3:4:567:89ab
will have the lookup address
b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT.
Currently, another new resource type called A6 is being defined [14] to better support
prefixes and simplify renumbering. When the A6 resource type are widely deployed, the
AAAA type will no longer be needed.
$XWRFRQILJXUDWLRQ
IPv6 introduces the term autoconfiguration – the capability of configuring a node without
the help of a human. This is a very welcomed feature for network administrators, but also
for non-experienced end users.
3.4.1 Mechanisms
IPv6 delivers the autoconfiguration functionality using three mechanisms:
ƒ Neighbor Discovery (ND) [27] is actually a set of ICMPv6 messages, which re-
places the services provided by ARP and Router Discovery defined in IPv4.
ƒ Stateless autoconfiguration [33] assigns a globally valid address to an interface by
combining its link-local address with address prefix information advertised by
nearby routers. No servers or human interaction is required for this operation.
ƒ Stateful autoconfiguration provides additional autoconfiguration parameters such
as DNS servers by using the Dynamic Host Configuration Protocol for IPv6
(DHCPv6) [8]. This is the preferred method of administrating address assignments
since it gives full control over the assignment process. However, DHCPv6 is still a
work in progress and has not been fully implemented or tested yet.
These mechanisms may be used together or separately depending on the network topol-
ogy and router parameters set by the network administrator as described in the next sec-
tion.
3.4.2 Procedure
The automatic configuration of a node is a multi-step process. A flow chart illustrating
the steps involved can be found in Appendix A. The complete process is as follows:
1) The interface is activated.
2) A link-local address is generated (but not assigned to the interface) by concatenat-
ing the predefined prefix FE80::/10 with a 64-bit interface identifier as described
in Section 3.3.4. The interface identifier can typically be the IEEE-802 address of
the interface card (e.g. Ethernet, FDDI) or another unique number taken from other
parts in the node (e.g. the main board serial number).
3) Neighbor discovery is then used to check if the newly constructed address is unique
(on the link). This is done by sending ND solicitation messages with the destina-

IPv6@home
15
tion address set to the address being tested, and source address set to the unspeci-
fied address (::). If a ND advertisement message is received, the address is not
unique and has to be recreated either manually or randomly.
4) Once the link-local address is known to be unique, the address is assigned to the
interface being configured.
5) Using the new link-local address as a source address, a ND router solicitation mes-
sage is sent to the all-routers multicast group (FF02::2).
6) In response to the ND router solicitations, routers send a unicast ND router adver-
tisement message back to the node. The advertisement specifies if the node should
use stateless or stateful autoconfiguration by setting the managed configuration
flag accordingly. If stateless autoconfiguration is to be used, a site-local or global
address is constructed using an address prefix included in the advertisement and the
current link-local address. The new address is then assigned to the interface (which
now has two addresses). The host is now configured for communication inside the
site or even on the Internet at large.
7) If there is no response from a router, or the advertisement specifies managed ad-
dressing, stateful autoconfiguration should be used. This is handled by DHCPv6,
which defines message types for configuring all necessary parameters.
5HDOWLPH 6XSSRUW
To meet the demands of today’s increase in real-time application such as streaming audio
or video, IPv6 specifies the following new related features.
3.5.1 Flows
In the IPv6 header, there is a 20-bit Flow Label field defined. A flow is implicitly defined
as a set of packets that come from the same source to the same (unicast or multicast) des-
tination bearing the same flow label. New flow labels are generated randomly in the range
1 to FFFFF hex. Packets are however not forced to use flow labels and then use a value of
zero as flow label. In fact, most packets will probably have this unspecified flow label.
Flows may be used to indicate that some packets require special handling by the IPv6
routers in the network such as low delay or high bandwidth. Then may also be used in
conjunction with the router header [15] to restrain all packets to the same path through the
network. To provide resource allocation, a protocol such as the Resource Reservation
Protocol (RSVP) [9] could be used. RSVP is based on the use of flows and is therefore
well suited for IPv6 as described in [6].
The usage of the flow label is still experimental, and a final decision on the usage will be
made when the needs come clearer.
3.5.2 Traffic Class
The 8-bit Traffic Class field can also be found in the IPv6 header. Much as the Type of
Service field in IPv4, this field provides the usage of differentiated services [28]. It also
provides prioritized routing where packets sent with higher priority originating from the
same source will be prioritized.
3.5.3 Jumbograms
To support extreme high-speed traffic in real-time, IPv6 provides a possibility of sending
very big packets; so called Jumbograms [7]. Usually, the 16-bit Payload length field in
the IPv6 header limits the maximum payload length to 65,535 bytes. Using the Jumbo
Payload option in a hop-by-hop extension header [15], the maximum length is extended

IPv6@home
16
to 4,294,967,295 bytes (using a 32-bit length field). However, the use of Jumbograms
requires the underlying link layer having a link MTU of at least 65,575 bytes (65,535 +
40 for the IPv6 header).
When using the Jumbo Payload options, the Payload length field in the IPv6 header must
be set to zero. The Next header field in the header is also set to zero, indicating the fol-
lowing hop-by-hop extension header where the actual payload length can be retrieved as
illustrated in Figure 3.4.
Figure 3.4: The Jumbo Payload option
0RELOLW
IPv6 has to support mobile nodes since they are expected to be very common in the fu-
ture. A method for accomplish this is defined in [20] as Mobile IPv6 and is currently un-
der study. Mobile IPv6 has much in common with Mobile IP for IPv4. Some improve-
ments should however be mentioned:
ƒ The care-of address is used as source instead of the home address.
ƒ Route Optimization is built-in eliminating “triangle routing”.
ƒ Simplified routing of multicast packets with the care-of address as source.
ƒ Foreign agents defined in Mobile IPv4 are no longer needed since the autoconfigu-
ration mechanisms are built into IPv6.
ƒ IPsec is used for all security instead of special solutions as in Mobile IPv4.
ƒ IPv6 Routing headers can often be used instead of tunneling between the home
agent and the mobile node to minimize overhead.
ƒ Using Neighbor Discovery instead of ARP eliminates link layer consideration is-
sues.
6HFXULW
With IPv6 comes security. Every IPv6 node is required to handle encryption and authen-
tication according to the specification. Although IP security is available for IPv4, it is far
from commonly used. The security is made possible by introducing two extension head-
ers.
The Authentication Header (AH) [22] makes it possible for a receiving host to guarantee
whether the sender is authentic or not, and that the received packet has not been altered
on its way. Introducing authentication in a network prevents spoofing attacks from hack-
ers where packets are sent from a hackers computer while using a trusted computers ad-
dress as a source address. Authentication is also important since the autoconfiguration
IPv6
Header
Hop-by-Hop
Options
Payload
…
Next Header Hdr Ext Len Option Type
(0xC2)
Option Length
(0x04)
Jumbo Payload Length
(0x00000000 – 0xFFFFFFFF)

IPv6@home
17
mechanisms introduced in IPv6 otherwise would let any computer join the network, get a
valid IPv6 address, and thereby access to the network.
The Encapsulated Security Payload (ESP) header [23] is used to encrypt packets. This
assures that only legitimate receivers will be able to read the contents. Intervening users
trying to read the packets for valuable information will only see a garbled version, which
prevents another known hacker attack: snooping.
The two headers could be used either separately or combined to make a secure connection
between two hosts, or a steel pipe between two networks as illustrated in Figure 3.5.
Figure 3.5 Network and header configuration for a steel pipe
Internet
steel pipe
Gateway Gateway
LANLAN
PayloadESPAHIPv6

IPv6@home
19
86,1* ,39 $7 +20(
Home networking and IPv6 are both hot topics today. They are both designed to meet the
new demands and services developing around the corner for the next millenium. So, why
not test the combination of the two together? In fact, it is quite easy to match the features
provided by IPv6, with the demands appearing in a home-networking scenario.
In brief, IPv6 provides the following enhancements over IPv4 in home networking:
ƒ Better addressing and routing using larger address space and flexible header struc-
ture
ƒ Built-in autoconfiguration of hosts for easier installation and administration
ƒ Low-level authentication and encryption security for safe transactions
ƒ Mobility support for using future devices which most likely will be portable
ƒ Real-time traffic support with multicasting for broadcasting media etc.
All of these enhancements conform to the needs in a home network very well. In fact,
home networking was one of the driving forces when considering IPv6 as a replacement
for IPv4. The goal is to revolutionize the usage of IP networks to the extents that every-
thing may be transmitted using it, anytime and everywhere.
In the following, the enhancement areas will be covered and discussed from a home net-
working perspective using real-world examples and applications.
$GGUHVVLQJ
The most important and critical factors when considering the new Internet protocol was
the addressing issue. Every node in an IP network needs at least one unique address to
communicate. Based on elementary arithmetic the IPv4 address space will be exhausted
sometime between the years 2005 and 2015 [19]. That is, no globally unique addresses
will then be available. Home networking will dramatically make this problem even more
critical since every connected device preferably should get a globally unique address for
seamless Internet access. Just imagine every mains socket or light bulb having their own
IP addresses in every connected household in the world. In Sweden alone with about 4.3
million households and, let’s say, 30 connected appliances, this would make up to nearly
130 million IP-addresses. This is about three percent of the total (theoretical) number of
addresses available in the IPv4 address space. When considering the loss for hierarchy
and other ineffective address allocation factors, this clearly shows the urgent need for a
larger address space.
4.1.1 Node Naming
With addresses such as 3ffe:2100:1da7:5c3:5633:4011:2ab:23, typing complete
IPv6 addresses will be a very tedious and error prone thing to do. It would be much more
convenient to reference the front door at home by using a common name instead such as
frontdoor.smith.stockholm.se as the destination. Of course, DNS is already
being used with IPv4, but it will become even more important in IPv6. That is why IPv6
will rely on the use of Domain Name System (DNS) more heavily than IPv4, even in
small LANs such as a home network. As mentioned in Section 3.3.7 there are already
DNS extensions developed for use with IPv6 to handle the new addressing space.
When home networking is to be introduced using IPv6, DNS has to be implemented
somewhere in the home LAN. The most feasible place to locate the DNS server would be

IPv6@home
20
in the home server (e.g. Residential Gateway or e-box). This would make it possible for
the end users to assign names to all connected devices within the residence. However,
including DNS functionality in the home server would increase the price and administra-
tion needs of the server. Another alternative could therefore be to let multiple home net-
works share one DNS server located at the network provider. While simplifying con-
struction and administration of the home servers, this solution could limit the users’ pos-
sibility of updating the DNS server.
4.1.2 Eliminating the NAT
To prevent the IPv4 address space from being exhausted, or at least doing it at a more
moderate rate, temporary solutions have been developed. The most common solution
today is by using Network Address Translation (NAT). NAT lets a local network con-
nected to the Internet use its own local address space, completely different from the
global address space. These is done by placing the NAT machine between the Internet
and the local network and then apply the appropriate mapping between the internal local
addresses into global addresses. This is very useful for small offices or homes using a
dial-up connection to the Internet where only a limited number of globally unique ad-
dresses are available. There are, however, disadvantages when using a NAT. It could
easily become a performance bottleneck since it has to replace the address fields inside
every IP packet. Also, certain protocols that embeds the source and destination address
inside the packet will not work without especially configured NAT machines.
When IPv6 is fully deployed, the need for NAT will be eliminated. The home network
will be able to use global addresses such as the aggregatable unicast addresses described
in Section 3.3.4 and thereby provide every node with a globally unique IP address. The
IPv4 NAT may then be replaced by a simple IPv6 router as illustrated in Figure 4.1.
However, during the transition period NAT may be very useful as will be described in
Section 5.2.1.
Figure 4.1: Eliminating the IPv4 NAT
4.1.3 Choice of Service Provider
With a modem and dial-up connectivity, the customer can easily choose which service
provider to use simply by dialing the appropriate telephone number. With a broadband
connection directly to your house always connecting you to the Internet, the choice will
no longer be so obvious.
The Global Aggregatable Unicast addressing scheme described in Section 3.2 was previ-
ously known as provider based addressing. The reason for this is that the address hierar-
chy defined in the scheme permits a site, or residence, to change service provider easily.
It is also possible to have multiple providers at the same time since each IPv6 interface
may be assigned multiple addresses with different prefixes. The user may then choose the
source address for outgoing packets depending on the application.
The renumbering of sites involved with changing provider is taken care of by the IPv6
autoconfiguration mechanism. A new prefix caused by the renumbering propagates
throughout the network as the old addresses and routes on the hosts eventually time out
IPv4
NAT
Local addressesGlobal addresses
IPv6
Router
Home LAN
Global addresses
Internet Home LAN
Global address
Internet

IPv6@home
21
when no router advertisements for that address/route are received. This will help provid-
ers and network administrators when introducing new network topologies. With today’s
trends of opening up the market with many competing providers, this feature is also most
welcome for the customer!
3OXJ DQG 3OD
4.2.1 Installing Devices
When home networking is to be introduced to the masses, a variety of network devices
and appliances will probably already be available. The problem is that far from everyone
has the network administrator’s knowledge that may be required to configure them and
get them all working together. Without an easy-to-use, plug-and-play fashion solution,
home networking would have a hard time entering the market.
This is the reason why the IPv6 working groups put a lot of effort into making IPv6 a
protocol that anyone could use without extra knowledge. It seemed reasonable that it
should not be any difference in plugging in an intelligent IPv6 enabled television set from
plugging in a conventional one.
With the autoconfiguration mechanisms defined in IPv6, installing and connecting new
devices or appliances to a home network will be a very simple task for anyone to do. In
fact, just plugging the device into a network socket should be enough to give it global
Internet access presuming the security policies admits it. If the network medium also is
capable of acting power supply (e.g. IEEE 1394/Firewire, mains) plug-and-play is really
the true word!
4.2.2 Mobile Devices
Future homes will most certainly contain numerous mobile devices connected to the
Internet. Simple devices such as door keys, remotes, portable radios and watches may all
have a small IPv6 stack implemented, enabling them to communicate with other devices
and appliances.
The autoconfiguration mechanisms featured in IPv6 provides for powerful, yet easy to
use, mobility support and makes mobile computing a simple task. By using the home
server as a mobile IPv6 home agent, it will also be possible to maintain a single IPv6
address wherever the device may be located. This brings up an interesting topic about the
addressing in IPv6. Since the IPv6 address space easily can provide every person with a
personal IPv6 address, why not give everyone a static address? The address should be
based on a unique number such as birth date together with codes for place of birth etc, or
maybe the SSN. With the mobility support, this address would then serve as a direct line
to that person wherever he or she is, much like the number to the persons cellular tele-
phone or pager. Incoming messages may then be rerouted to any device by assigning it
with the appropriate address. Of course, this requires tight security as described in Sec-
tion 4.4.

IPv6@home
22
0XOWLPHGLD
4.3.1 Convergence
The world of communication is about to change. Today, multiple separate services for
transporting real-time information such as speech or video are used in parallel (e.g. TV,
radio, and telephone). Each service typically requires its own specific medium, billing
and end-user devices. This “redundancy”, with multiple services serving the same pur-
pose of delivering information, will probably end with the introduction of home net-
working. By using a single information network such as the Internet, all kinds of infor-
mation could be delivered in a uniform and easy accessible way (Figure 4.2).
Figure 4.2 The world of media is converging
4.3.2 Quality of Service
Today there are already many examples of real-time applications for internetworking
available. These includes tools for listening to streaming music, watching streaming
video on demand and Internet telephony (Voice over IP, VoIP). However, today’s Inter-
net makes it hard for real-time applications to deliver the quality needed, especially all the
way to the homes. The most limiting factor for home users today is probably the lack of
bandwidth. Watching a movie in broadcast quality requires several megabits per second.
Even with advanced compression algorithms, a single modem is simply not enough. The
bandwidth problem will probably be solved in a very near future since many competing
operators all racing to be the dominant provider with the majority of the homes as cus-
tomers. The most common way to provide broadband today is through the cable TV net-
work, which has proven to be a very attractive bearer.
However, Quality of Service (QoS) is more than just bandwidth. It has to provide means
for limiting or control the latency and jitter. In addition, resource reservation is desired
when many different services are to be sharing the same medium.
IPv6 is well prepared for real-time services. The latency will still depend heavily on the
routers in the core networks, but with a fixed header size and no need for the routers to
recalculate the header checksum every hop, the delay will probably be lower than today.
The latency variation, the jitter, caused by changing routing decisions during a transmis-
sion, could also be limited by using the flow label. This would cause intermediate routers
to serve all packets belonging to the same flow in the same way. Additionally, using the
flow label in conjunction with a resource reservation protocol such as RSVP as described
in Section 3.5.1 and the draft written by S. Berson [6], would also take care of the re-
source reservation issue.
4.3.3 Broadcasting Media
If broadcasting media such as TV and radio are to be carried over the Internet, it must
support multicasting. Multicasting is used to send packets from one source to multiple
destinations without unneeded replication. It is a hot topic, and much research is being
IPv6
Telephony Television
Data Radio

IPv6@home
23
performed to make multicasting available in IPv4. Currently, a “virtual” Internet called
the MBONE makes multicasting possible by using tunnels between multicast capable
routers, but still IPv4 multicast is far from fully deployed.
IPv6, on the other hand, has native support for multicasting, making it ideal for broad-
casting media. Every IPv6 capable router is required to handle multicast routing accord-
ing to the specifications. An IPv6 node also has full multicast management support
through the group management messages included in ICMPv6.
When sending a TV broadcast, it would also be important to specify where the broadcast
should be available. The multicast scope features in IPv6 multicasting make this selection
an easy task. A regional news agency could choose to broadcast only to customers within
the local neighborhood or the city. In the same way, national broadcasting companies
could choose to limit their broadcasts to the country border as listed in Table 4.1. This
requires however that the conceptual borders are known by the routers and that all as-
signed scope values are commonly known.
Table 4.1: Example of home networking multicast scopes
Value Definition Scope Home Networking Scope Example
0 Reserved
1 Node-local scope Appliance scope “The fridge”
2 Link-local scope Apartment scope “Floor 2, apartment 214”
5 Site-local scope Building scope “4020 Long Street”
8 Organization-local scope Residential area scope “North docks”
A City scope “Stockholm”
C Country scope “Sweden”
E Global scope “Earth”
F Reserved “Universe?”
In home networking, the more common usage of broadcasting would be in-house distri-
bution of audio and video. As a source, any IPv6 enabled TV receiver, DVD player or hi-
fi equipment would do. The receivers would typically be video monitors and speakers
used to present the streaming data. These kinds of transmissions would often use more
local scopes than those used by the TV companies, maybe limited to “Apartment scope”
or “Building scope”. The scope control would also be welcomed by all kinds of local
authorities and persons such as hotels, tenants’ associations and employees for internal
communication.
4.3.4 Hierarchical Transmission
When broadcasting real-time multimedia to a vast number of customers, not all of those
will use the Internet under equal conditions. While some may have the luck to access the
Internet through the cable TV network featuring several megabits per second of band-
width, others may have to be content with a simpler connection. The broadcast has to be
accessible to all those customers, but the users using a high-speed connection will surely
not settle with only getting the poor quality limited by the low-speed connections. One
solution is of course to split the stream into multiple ones with well-defined bit rates.
However, this method wastes bandwidth since the same content will have to be made
available in parallel.
A better solution is to use hierarchical transmission. By separating the source stream into
incremental parts that together make up the original stream, a receiver may choose how
much quality that should be received. For example, a videoconference with audio sam-
pled at 22 kHz and video with a resolution of 640 by 480 pixels may be split up into four
streams, or layers as illustrated in Figure 4.3.

IPv6@home
24
Figure 4.3: Hierarchical transmission
The low-capacity customer may now choose to receive only the first layer with low-
quality audio, while the high-speed user may be able to combine them all and thereby
getting a higher quality stream.
By using the Traffic Class field provided by IPv6 and assigning the streams with incre-
mental priority accordingly, the filtering can be made automatically at the network layer.
The highest prioritized stream (in this case the low-quality audio) will always be re-
ceived, while the additional streams will be used only if the bandwidth admits it.
6HFXULW
When home networking is a reality, security will be of highest importance to protect the
private home LAN from “network intruders”. For example, while you should be able to
program your VCR or unlock your front door remotely over the Internet, you probably
don’t want to give everyone in world access to do the same! That is, some kind of
authentication is required. IPv6 solves this issue by providing native security support in
every IPv6 node.
Still, a problem is the design and physical location of the security mechanisms in a home
network scenario. One solution is illustrated in Figure 4.4 where a “access server” is in-
troduced in the network and acts as a firewall to the home networks connected to it.
While limiting the traffic to and from the Internet, it also takes care of traffic between
inner home networks if all traffic is set up to go through the access server. This would
help non-experienced users to secure their home network, while more advanced users
could be given an “open” connection without security limitations.
Figure 4.4 The access server limits both external and internal traffic
11 kHz audio
320 x 200 video
Additional audio
Additional video
+
+
+
Priority
Full quality
High quality
Medium quality
Low quality
Access Server
Internet
Home Server Group Server

IPv6@home
25
,1752'8,1* ,39 72'$
Today the Internet is based on IPv4 as the main network protocol. Introducing IPv6 in
this world is far from trivial when considering everything that has to be upgraded: both
hardware and software implementations of the IP stack in every host or router together
with additional protocols etc. The transition may well take several decades to complete,
and during that period, IPv4 and IPv6 will have to work side by side.
The transition issue has been given high priority in the Internet Engineering Task Force
(IETF) where a special working group called NGTRANS (Next Generation Transition
Working Group) has been working on tools and mechanisms for the transition since De-
cember 1994. The group has published many Internet-drafts and RFCs describing the
transition tools and mechanisms in various scenarios where IPv6 is to be introduced.
7UDQVLWLRQ 6WUDWHJ
Transforming the whole Internet to IPv6 is a major task. A natural question would be
where to begin. Two major strategies have been proposed for introducing IPv6 in today’s
networks:
ƒ Upgrade the core IPv4 routers to support IPv6 first, and then propagate throughout
the network until all access networks and nodes are IPv6 enabled.
ƒ Reverse the path and start with the edges of the network topology, i.e. local Intra-
nets or home LANs. As the upgrade extends into the core net through the access
network, the border between IPv6 and IPv4 moves further into the network as il-
lustrated in Figure 5.1.
The first strategy is beyond the scope of this report. Instead, the transition of home net-
works, and the affects of it appearing to the end users, will be covered. A typical transi-
tion of a home network connected to the Internet may be divided into four phases as
shown in Figure 5.2. In each step, IPv6 is gradually replacing IPv4 as the default proto-
col.
Figure 5.1 Transition from the edges and in
Core network
Access network
Access network
Access network
Home
Networks
IPv6
IPv4

IPv6@home
26
Figure 5.2 Four phases in an IPv4 to IPv6 transition
1. IPv4 Only. The situation for almost everyone of today’s households already con-
nected to the Internet. As illustrated in Figure 5.2(a), IPv4 is used throughout the
network all the way from the end users into the core. All communications are car-
ried over IPv4 and no IPv6 nodes have been introduced.
2. IPv6 in the homes. IPv6 is introduced as a secondary protocol in the home net-
works. IPv4 is still used as the only protocol in the access network. In the home
network, IPv4 is used as a complementary protocol to enable IPv4-only nodes to
communicate or dual stack IPv4/IPv6 nodes to access IPv4 resources. By tunneling
IPv6 packets inside IPv4 packets, IPv6 connectivity may also be achieved.
3. IPv6 in the access network. To let the IPv6 enabled nodes take advantage of all
the new features provided, IPv6 has to be implemented in the access network to
interconnect the IPv6 islands contrived in the homes. At this stage, IPv6-only
nodes will also become increasingly common while IPv4-only nodes will be lim-
ited to small old systems. Additionally, it will probably be more common to encap-
sulate IPv4 packets in IPv6 than the other way around.
4. IPv6 Only. At this stage, there are no longer any IPv4-only nodes since they have
been replaced with a newer generation product line. When all IPv4-only nodes has
been eliminated, and thereby the need for IPv4 communication, IPv4 capable nodes
can be completely transformed into pure IPv6 nodes. IPv6 can now be fully de-
ployed as the only protocol and thereby provide everyone with the new features it
brings.
The early transition phase has already begun in many research labs and institutions,
which together creates a global IPv6 network called the 6bone [1]. The 6bone uses tun-
nels for transporting IPv6 inside IPv4 packets and spans across many countries.
7UDQVLWLRQ ,VVXHV
As mentioned earlier, the IETF NGTRANS working group has presented various mecha-
nisms for the transition from IPv4 to IPv6. The choice of appropriate mechanisms to use
IPv4 router
4
IPv4 router
Group Server
Building/apartment Access Network Core Network
4 4 4 4
IPv4 router
4
Transition Box
Group Server
4 4/6 4/6 4
IPv4 router
4/6
Transition Box
Group Server
4/6
6
4/6 4/6
IPv4 router
6
IPv6 router
Group Server
6
6
6 6
(a)
(b)
(c)
(d)

IPv6@home
27
depends on the particular transition scenario being studied. In our case, with the home
network environment, we first have to isolate the transition problems we need to solve.
The first steps towards an IPv6 enabled home network involve many aspects, which has
to be taken into consideration. What kind of addressing scheme should be used? Will it
still be possible to reach IPv4 resources or use IPv4 applications? Which IPv6 features
will be applicable and how?
5.2.1 IPv6 Addressing
Each IPv6 network needs its own address space. A home network inside a house will
most likely be limited to a single network segment, such as an Ethernet LAN with hubs.
In this case, the IPv6 link local addresses (prefix fe80::/10) are sufficient to allow the
nodes to communicate internally as illustrated in Figure 5.3. These addresses are gener-
ated by the hosts themselves as described in Section 3.3.4 and therefore no stateful server
such as DHCP is needed for the address assignment.
Figure 5.3 Addressing scheme for home networks
In areas with multiple households, such as a block with many flats or a complete residen-
tial area, it would also be necessary to use site local addresses since link local packets
must not be routed. To employ site local addressing, a border router has to be configured
to send router advertisements with a desired site local prefix, which then will propagate
throughout the network and configure all hosts with additional site local addresses. The
complete addressing solution is presented in Figure 5.3.
5.2.2 IPv4 Connectivity
After an introduction of IPv6 in the homes, many servers on the Internet will still be lim-
ited to only use IPv4. Therefore, an IPv6 enabled node inside the home network should
be able to access these servers. Currently, there are several transition mechanisms for
overcoming this problem.
NAT-PT/NAPT-PT
To enable IPv6-only hosts to communicate with IPv4-only hosts, the NAT-PT (Network
Address Translation – Protocol Translation) was defined [35]. The NAT-PT works much
like a plain IPv4 NAT where one IPv4 address is translated into another. In the NAT-PT
however, the translation is made between IPv6 and IPv4 addresses. Additionally, the PT
part of the NAT-PT makes a stateless translation between the IPv6 and IPv4 protocols
using the Stateless IP/ICMP Translation (SIIT) method defined in [29]. A typical setup
and the main function blocks in the NAT-PT are shown in Figure 5.4.
fe80:0:0:0::/64
fe80:0:0:0::/64
fe80:0:0:0::/64
Router/Transition box
fec0:xxxx:yyyy:zzzz::/64
Router Ad
Intranet
Internet

IPv6@home
28
Figure 5.4 The NAT-PT/NAPT-PT transition mechanism
When a new session starts, a new IPv4 addresses is acquired dynamically from a prede-
fined pool of IPv4 addresses, which then is used throughout the session. When the session
ends, the address is returned to the pool ready to be assigned to another host.
A limitation of NAT-PT is that the maximum number of simultaneously connected hosts
is limited by the number of IPv4 addresses in the address pool. To overcome that limita-
tion, the NAT-PT mechanism was extended to NAPT-PT, where the extra P stands for
Port [35]. With NAPT, a single IPv4 address can be used to communicate with external
resources. This is made possible by using different TCP or UDP ports for each host. This
means a maximum of about 63K hosts per IPv4 address.
A limitation of both NAT-PT and NAPT-PT is that the connectivity is limited to TCP and
UDP traffic (ICMP queries are also supported since the ICMP header includes identifier
that can match incoming replies with the outgoing queries). Another limitation is that
protocols, which embed the network addresses in the higher application layers such as
DNS, FTP and H.323, are not supported without further help. This can however be solved
by using so-called Application Level Gateways (ALGs), which performs more in-depth
analysis and translation of the corresponding packets.
DSTM
Another way of providing IPv4 connectivity in the IPv6 home network is to equip the
hosts with dual IP stacks as proposed in the Dual Stack Transition Mechanism (DSTM)
[34]. With dual stacks, an IPv6 stack is used for internal (and future external) communi-
cation, and an IPv4 stack provides true IPv4 connectivity. A problem with using dual
stacks might seem to be the need for two IP addresses – one for each stack. Of course, the
simplest way would be to assign each host both an IPv4 address and an IPv6 address.
However, this approach would not benefit from the huge address space available in IPv6
since the IPv4 address assignment would limit the number of hosts. Instead, DSTM util-
izes a dynamic address allocation mechanism called Assignment of IPv4 Global Ad-
dresses to IPv6 hosts (AIIH). Previously, AIIH was the name of a whole transition
mechanism defined in the draft [34], but recently, the name changed to DSTM to empha-
size the dual stack design model.
The AIIH mechanism is handled by an AIIH server – a combined DNS and DHCP server.
The DNS part is used as a cache for assigned IPv4 addresses. For example, when an in-
ternal IPv4/IPv6 host requests communication with an IPv4 host, a temporary IPv4 ad-
dress is assigned to the host and the binding is stored in the DNS as shown in Figure
5.5(a). The dynamic assignment also works in the opposite direction, which is illustrated
in Figure 5.5(b). When an external IPv4 host wants to communicate with an internal
IPv4/IPv6 host, and a DNS entry for this IPv4 address does not exist, a DHCP reconfig-
ure command is sent to the host to assign it an IPv4 address. The two hosts can now
freely communicate using IPv4.
NAT/NAPT
IPv4IPv6
SIIT
Internet
Home network
131.115.0.0/16fe80::/10

IPv6@home
29
Figure 5.5 Internally (a) and externally (b) initiated IPv4 session using AIIH
SOCKS/Application proxies
Another solution based on SOCKS version 5 has also been proposed in [25]. By com-
bining an ordinary socks server with a protocol translator, a transparent solution can be
created. A downside with using SOCKS has always been the need for the special configu-
ration on the hosts to “socksify” the application sessions. This would also cause a promi-
nent need for support from home users if introduced into the home networks.
Similar to the SOCKS solution, application layer proxies can be used to translate be-
tween IPv4 and IPv6. For example, a web proxy server can easily be fitted with a proto-
col translator and thereby accept incoming IPv6 requests on one interface and send them
out another one using IPv4 and vice versa. The implementations of such proxies are quite
simple, but they still share the problem with limited application support and the need for
special host configuration.
Summary
It is hard to tell which of these mechanisms is most suitable depending on the various
demands of both the customers and the network administrators in different scenarios. The
most promising solution for the initial transition steps seems to be the DSTM since it
provides true IPv4 and IPv6 connectivity in parallel. The requirement of dual stack may
however be a problem for embedded systems that today only have IPv4 stacks. The NAT
and SOCKS solutions both have limited IPv4 connectivity since applications that embed
IP addresses in higher protocol layers won’t work without special configuration. Another
big disadvantage for using SOCKS in a home network environment is that the client ap-
plication has to be “socksified” to work. This can easily lead to a massive demand for
support since not everyone has the knowledge of a network administrator. Table 5.1
summarizes the features of the mentioned mechanisms for a quick overview.
Z
IPv4
AIIH Server
IPv4/IPv6
X
IPv4/IPv6
Internet
Z
IPv4
AIIH Server
IPv4/IPv6
X
IPv4/IPv6
Internet
1. DNS Request for X2. IPv4 Address
2. IPv4 Address
1. DNS Request for Z
(a)
(b)

IPv6@home
30
Table 5.1 Overview of transition mechanisms for IPv4 connectivity
NAT-PT, NAPT-PT DSTM SOCKS 5/
Application proxies
IPv4 address re-
quirements
≥1 per site1
≥1 per site1
1 per site1
Host Requirements IPv6 stack Dual IP stacks + DHCPv6 Application configuration
Advantages ƒ Very low IPv4 address
requirements (NAPT)
ƒ Implementations
available
ƒ True IPv4 connectivity
ƒ Low IPv4 address
requirements
ƒ Very low IPv4 address
requirements
ƒ Implementations
available
ƒ Simple configuration
Disadvantages ƒ Limited IPv4 applica-
tion support
ƒ No implementations
available
ƒ IPv4 stack required
ƒ DHCP client required
ƒ Hosts need socks
configuration
ƒ Limited IPv4 applica-
tion support
Specification Status Internet draft Internet draft Internet draft
Implementation
Status
Versions for NetBSD and
Windows 2000 available
Expected for Linux and
NetBSD in 4 months
Available for various
systems
1
A site may range from a single household to a residential area depending on the transition phase
5.2.3 IPv6 Connectivity
Short after the introduction of IPv6 in the homes, home users will most likely want to be
able to communicate with other IPv6 resources on the Internet. This IPv6 connectivity
can be achieved even before the access or core networks have been upgraded by tunnel-
ing IPv6 packets in IPv4. It is already possible for anyone with an IPv6 enabled host to
connect to the 6bone, which interconnects isolated IPv6 island all over the world using
tunnels [1]. However, the methods developed for this scenario is beyond the scope for
this report.
5.2.4 Old Applications
Today there are thousands and thousands of Internet applications based on IPv4. This
includes all kinds of applications such as simple diagnostic tools, games, web browsers,
and mail clients. If a home network would be upgraded to IPv6, it would be feasible, or
required, to be able to use these existing applications without any fuss. Without this pos-
sibility, users would have to wait until their applications were upgraded to handle IPv6,
where a time schedule is hard to estimate.
The NGTRANS working group has announced a mechanism for solving this problem
called the Bump-in-the-Stack Technique [36]. By extending an ordinary IPv4 stack with
extra functionality for IPv6 connectivity as illustrated in Figure 5.6(a), a transparent solu-
tion can be achieved.
The first addition to the IPv4 stack is the Extension Name Resolver. It translates the IPv4
application’s single DNS request to a request for both ‘A’ and ‘AAAA’ records (the
drafts have not been updated with the ‘A6’ record type yet). If an ‘A’ record could be
found, traditionally IPv4 communication can continue using the IPv4 stack. If only an
IPv6 entry (‘AAAA’ or ‘A6’) could be found, the Address Mapper maps the returned
IPv6 address to an IPv4 address taken from a local address pool. The address pool may
contain private address such as 192.168.0.0 or 10.0.0.1 since the scope is limited to the
host. When an IPv4 address corresponding to the IPv6 host is available, the communica-
tion can be set up through the Translator and the IPv6 stack. The translator uses SIIT [29]
for the translation, and the IPv6 stack is a fully featured stack with features such as
Neighbor Discovery and security.

IPv6@home
31
A diagram of a typical communication scenario between an IPv4 application and an IPv6
host is shown in Figure 5.6(b). Communication initiated by the IPv6 host is established in
a similar way:
ƒ The IPv6 packet reaches the translator
ƒ The address mapper resolves the IPv6 address into a corresponding IPv4 address
ƒ The new IPv4 packet is sent to the IPv4 application with the IPv4 address as the
source address.
Figure 5.6 The Bump-in-the-Stack architecture
Using this technique, compatibility with old IPv4 application is not a problem for the
introduction of IPv6.
,PSOHPHQWDWLRQ 6WDWXV
To introduce a new protocol such as IPv6, only writing Internet-drafts and specifications
are not enough. At some stage implementations of the specifications has to begin to real-
ize the visions and to let people experiment with the new protocol. Implementation of
IPv6 stacks and IPv6 adaptation of applications has been underway since 1994, and today
there are IPv6 stacks available for almost every platform such as MS Windows, UNIX,
SUN OS among others. However, these stacks often lack some functionality such as se-
curity, mobility or DHCP. In fact, the DHCP extensions for IPv6 has not yet been fully
standardized, thus there are no DHCP implementations available.
IPv6 enabled applications have also become available. These applications include the
standard net tools such as ping, traceroute and tcpdump. Also more useful applications
for using telnet, ftp and http are available.
All of the transition mechanisms except for AIIH have also reached implementation.
However, the work is still in progress and many implementations still suffer from bugs or
other cavities.
More details on the implementation status together with where to find IPv6 software can
be found in Appendix B.
translator
IPv6
address
mapper
extension
name
resolver
IPv4 applications
TCP/IPv4
Physical network layer
IPv4
application
TCP/
IPv4
extension
name
resolver
address
mapper
translator IPv6
IPv6
host
Query of A records for host6
Query of A and AAAA records for host6
name
server
Reply only contains an AAAA record
Request an IPv4 address for host6
Reply with an IPv4 address from the pool
Reply with an A record
IPv4 packet
Resolve IPv6 address
from the IPv4 address
IPv6 packet
IPv6 packet
IPv4 packet
(a) (b)

IPv6@home
33
(;3(5,0(17$/ 6(783
*RDO
During the development of this report, I was also conducting some simple experiments in
order to get a greater understanding of IPv6 and verify its functionality. Another goal was
to investigate the current implementation status of IPv6 stacks, transition mechanisms,
and application for various platforms. The compatibility between the different imple-
mentations was also a topic of interest.
6FHQDULR
The network which I set up was a very simple “home network” consisting of one home
server and two clients as illustrated in Figure 6.1. The home network was connected to
the local Intranet of Telia Research, which only supported IPv4 and therefore simulated
the IPv4-only access network.
Figure 6.1 Experimental network setup
([SHULPHQWV
6.3.1 Hardware and OS
As a first step in the experiments, I acquired the necessary hardware and installed the
operating systems. On the ‘rg’, I decided to install Linux as it provides good network
support and free server software such as DNS and web servers. I also had previous expe-
rience with Linux, which made the final choice the Red Hat Linux 6.0 distribution.
The clients were to simulate common home-user environments, so I chose to install Win-
dows 2000 and Windows 98 SE on those machines with default installation options. Until
Microsoft’s new OS called Millenium is released, Windows 98 will probably be the num-
ber one OS in homes followed by Windows NT or Windows 2000 for distance working
people.
Cloud
Intranet
rg
win2k win98
131.115.
10.0.0.1/
::200:f8ff:fe32:5fc
ipv6.trab.se
10.0.0.3/
290:27ff:fe72:93b5
10.0.0.2/
210:4bff:fe71:3e2
131.115.159.40

IPv6@home
34
6.3.2 IPv6 Support
The next step was to enable IPv6 support on the machines. Initially, I followed Peter
Bieringer’s excellent step by step instructions [3] to enable IPv6 on the ‘rg’ and compiled
the software by hand. Later, a precompiled RPM-based IPv6 distribution for Linux was
announced on Bieringer’s page, which simplified the installation significantly. I then
wiped the Linux machine to try this alternative installation method. The installation of the
RPM packages was very simple, starting with replacing the kernel followed by additional
networking tools for configuration.
For the ‘win2k’ client equipped with Windows 2000, the IPv6 stack available was Micro-
soft Research’s experimental stack (MSRIPv6). To install, I only had to follow the stan-
dard procedure for adding a new protocol in Windows from the network properties as
shown in Figure 6.2(a). The rest was automatically configured. In fact, the “Properties…”
button was grayed out since there is nothing to configure in IPv6 – everything is based on
autoconfiguration.
(a) (b)
Figure 6.2 Network configuration in MSRIPv6 (a) and Winsock 5.0 (b)
To enable IPv6 support on the Windows 98 machine I used Trumpet Software’s latest
release –Winsock 5.0. Actually, the software includes both an IPv4 and an IPv6 stack,
and therefore the standard Microsoft TCP/IP stack first had to be removed from the sys-
tem. Trumpet Winsock also supports autoconfiguration for IPv6. I only had to configure
the IPv4 part of the stack to use 10.0.0.2 as IP address. All configuration was made
through the configuration panel shown in Figure 6.2 (b).
After the installation of IPv6 stacks on all hosts, I verified that all hosts had been assigned
with a link local IPv6 address. On ‘rg’ I used the standard (but IPv6 enabled) command
ifconfig to extract the interface information. The output of this command can be found
in Appendix C together with the output from the ipv6 program on ‘win2k’ provided
with Microsoft’s IPv6 stack. On ‘win98’, Trumpet Winsock’s configuration window pro-
vided the necessary information as shown in Figure 6.2 (b).
The IPv6 addresses had been built using the stateless autoconfiguration method. The link
local addresses created were based on the MAC addresses of the installed Ethernet NICs
according to the mapping described in [13].

IPv6@home
35
6.3.3 Connectivity check
The next step was to test the IPv6 connectivity between the newly installed IPv6 stacks.
To do this, I used the “ping” tool available on all hosts. On ‘rg’, the original ping appli-
cation was replaced during installation by a new IPv6 enabled version. I first tried to ping
‘win2k’ from ‘rg’:
[root@rg ~]# ping fe80::290:27ff:fe72:93b5
PING fe80::290:27ff:fe72:93b5 (fe80::290:27ff:fe72:93b5): 56 data bytes
64 bytes from fe80::290:27ff:fe72:93b5: icmp_seq=0 ttl=64 time=2.263 ms
--- fe80::290:27ff:fe72:93b5 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 1.568/2.186/2.471 ms
Success! The first IPv6 packets on my network had just been successfully sent!
To provide further investigation of the network traffic, I also installed an IPv6 enabled
version of the traffic analyzer tcpdump on ‘rg’. The resulting output of the above ping
session describes the communication more in detail:
[root@rg ~]# tcpdump -i eth0
tcpdump: listening on eth0
fe80::200:f8ff:fe32:5fc ff02::1:ff72:93b5 icmpv6: neighsol
fe80::290:27ff:fe72:93b5 fe80::200:f8ff:fe32:5fc icmpv6: neigh adv (SO)
fe80::200:f8ff:fe32:5fc fe80::290:27ff:fe72:93b5 icmpv6: echo request
fe80::290:27ff:fe72:93b5 fe80::200:f8ff:fe32:5fc icmpv6: echo reply
fe80::200:f8ff:fe32:5fc fe80::290:27ff:fe72:93b5 icmpv6: echo request
fe80::290:27ff:fe72:93b5 fe80::200:f8ff:fe32:5fc icmpv6: echo reply
...
As one can see, not only the echo request and reply messages was sent. The session be-
gins with a neighbor discovery process where ‘rg’ learns the MAC address of ‘win2k’.
Compare the behavior of a plain IPv4 ping where ARP is used instead:
arp who-has 10.0.0.3 tell 10.0.0.1
arp reply 10.0.0.3 is-at 0:90:27:72:93:b5
10.0.0.1 10.0.0.3: icmp: echo request
10.0.0.3 10.0.0.1: icmp: echo reply
10.0.0.1 10.0.0.3: icmp: echo request
10.0.0.3 10.0.0.1: icmp: echo reply
...
The neighbor solicitation message is sent to the special multicast address
ff02::1:ff72:93b5 destined to ‘win2k’ instead of a broadcast message as with ARP. The
solicitation message carries the MAC address of ‘rg’, which makes it possible for ‘win2k’
to reply. In response to the solicitation, ‘win2k’ sends a neighbor advertisement back to
‘rg’ with its MAC address embedded inside the message. The flags in the tcpdump out-
put indicate that the advertisement was in response to a solicitation (S), and that the
newly acquired MAC address should override any old records in the cache (O).
To verify that all nodes where able to communicate with each other, I repeated the “ping
test” between all machines. Microsoft included a new application, ping6, with their IPv6
stack to ping IPv6 hosts, which I used on ‘win2k’. Trumpet Winsock on ‘win98’ also
included a ping tool in its configuration program.
6.3.4 DNS
IPv6 addresses are long and error prone to type in by hand. Therefore, to simplify further
application testing I decided to install a DNS server on the ‘rg’ machine. It appeared that
the version of Bind (version 8.2-6) provided with the Red Hat Linux distribution already
had support for the IPv6 ‘AAAA’ resource record type, which made it the natural choice.

IPv6@home
36
Further investigation showed however that this version was not able to communicate over
IPv6. It supported ‘AAAA’ records, but IPv4 was the only protocol supported.
Despite this lack of IPv6 support, I installed the package and configured a new fictional
domain called ipv6.trab.se. For my experimental setup, I typed in all resource rec-
ords by hand in the master files:
ns A 10.0.0.1
AAAA fe80:0:0:0:200:f8ff:fe32:5fc
rg CNAME ns
win98 A 10.0.0.2
AAAA fe80:0:0:0:210:4bff:fe71:3e2
win2k A 10.0.0.3
AAAA fe80:0:0:0:290:27ff:fe72:93b5
In the future of home networking this will most probably be automatically configured so
that a connected device automatically registers its name in the DNS. In fact, dynamic
DNS updates have already been covered in RFC2136 [32], and Microsoft has imple-
mented the functionality in Windows 2000.
After the DNS server was started, and all nodes’ (IPv4) DNS servers where set to ‘rg’
(10.0.0.1), I could successfully ping the hosts by name such as
[root@rg ~]# ping win2k
PING win2k (fe80::290:27ff:fe72:93b5): 56 data bytes
...
It can be noticed that the IPv6 enabled ping seems to send the ‘AAAA’ first since the
IPv6 address was chosen over the IPv4 address. To override the preference, ping allows
selection of address family with the flag –a:
[root@rg ~]# ping -a inet win2k
PING win2k (10.0.0.3): 56 data bytes
64 bytes from 10.0.0.3: icmp_seq=0 ttl=128 time=2.253 ms
64 bytes from 10.0.0.3: icmp_seq=1 ttl=128 time=2.39 ms
...
[root@rg ~]# ping -a inet6 win2k
PING win2k (fe80::290:27ff:fe72:93b5): 56 data bytes
...
Besides the Bind name server, I found an experimental IPv6 enabled name server called
newbie. However, I did not manage to get it running since it was written for FreeBSD
and in an early stage of implementation, which made it hard to port to Linux.
6.3.5 Router Advertisements
To test more of the autoconfiguration mechanisms, I decided to install and test a router
advertisement service on ‘rg’. The application needed was available as a precompiled
RPM package (radvd-0.5.0) and installed itself as a daemon. In the configuration file
(/etc/radvd.conf) I specified the address prefix which was to be advertised. I had to be
content with a site local prefix (e.g. FEC0:0:0:1::/64) for the test since I was not able
to get a global prefix assigned to me.

IPv6@home
37
After starting the daemon, I verified the router advertisements generated using tcpdump:
14:09:42.909022 fe80::200:f8ff:fe32:5fc ff02::1 icmpv6: router ad
Apparently, the router advertisement is sent to the all-nodes multicast group FF02::1 in
intervals of between approximately 4 and 10 minutes. According to the specification of
neighbor (and router) discovery [27], the interval should be chosen randomly between 3
and 10 minutes which thus has been verified.
On the client side, the router advertisements are received used to configure the interfaces
on link with additional addresses and routes. For example, after the first advertisement
had reached ‘win2k’, its Ethernet interface was assigned the new site local address
fec0::1:290:27ff:fe72:93b5 constructed by concatenating the advertised prefix
with the IPv6 suffix of ‘win98’. The routing tables where also updated accordingly with
new routes for the prefix and the address.
6.3.6 IPv6 connectivity
To further test the IPv6 connectivity, I decided to try connecting my experimental net-
work to the 6bone. The Linux IPv6 stack could handle the IPv6-in-IPv4 tunneling re-
quired, so setting up a static tunnel to a site already connected to the 6bone seemed like a
minor problem. However, my network was connected to Intranet protected by a very re-
stricted firewall. IPv6 packets encapsulated in IPv4 packets use the IP protocol number
41 as an identifier while the firewall appeared to allow only TCP and UDP packets.
Despite several tries to have the firewall opened, I finally gave up since global IPv6 con-
nectivity wasn’t really part of the scenario with an IPv4-only Internet provider.
6.3.7 Transition mechanisms
At this stage, the internal nodes where able to communicate internally using IPv6 (and
IPv4), while IPv4 was the only working protocol outside ‘rg’. This is the typical scenario
for the initial transition towards IPv6 described in Chapter 1. The next step would be to
combine these two worlds by using some kind of transition box.
This phase of the experiments was the most interesting one. The goal was to have a fully
functional IPv6 network where users could use IPv6 to communicate internally, and yet
be able to access the IPv4 resources available as described in Section 5.2.2. It should also
be possible to use old IPv4 applications to communicate over IPv6 (Section 5.2.4).
NAT-PT/NAPT-PT
Through a mailing list available at the IPv6 Information Page [4], I got in contact with
Peter Hovell at British Telecom (BT). He announced that BT had an implementation of a
NAT-PT available. It was however written for the KAME stack on FreeBSD and seemed
hard to port (after some unsuccessful attempts by me). Therefore, I was not able to test
the BT NAT-PT at all.
Another NAPT-PT was provided by Microsoft in their MSRIPv6 package (originally
written by the University of Washington). Since Microsoft’s NAPT-PT required their
IPv6 stack running under Windows 2000, I installed Windows 2000 as a secondary OS
on ‘rg’. I then installed the software in the form of a simple NT service and configured
the mapping parameters in the registry.

IPv6@home
38
However, despite several attempts of configuration and discussions through mailing lists,
I was unable to get the NAPT-PT working.
DSTM (AIIH)
Currently, there are no implementations of AIIH available. However, in a mail from Jim
Bound (bound@zk3.dec.com) he states that the implementation is now underway and is
expected to be publicly available for Linux and “BSDish” OS in spring 2000.
Bump in the Stack
In this experiment, I wanted to test the dual stack functionality through an IPv4 applica-
tion using the bump-in-the-stack mechanism described in Section 5.2.4. Luckily, the
mechanism is included in the Winsock 5.0 stack installed on host ‘win98’, so no further
configuration was needed.
Since I did not have access to the 6bone for accessing IPv6 resources, I installed an IPv6
enabled version of the web server Apache on ‘rg’. To be able to choose between IPv4 and
IPv6, I also updated the DNS with additional records for separating IPv4 and IPv6 inter-
faces. In the database file the following lines where added:
rg-4 A 10.0.0.1
rg-6 AAAA fec0:0:0:1:200:f8ff:fe32:5fc
The DNS server was restarted, and the new configuration verified by pinging the “new”
hosts.
On the client ‘win98’ I now started up a plain old IPv4 Netscape. I typed in “rg-4” as the
URL, and instantly I reached the homepage on ‘rg’. The page had been transferred using
IPv4, which also could be verified using tcpdump.
Now I tried the IPv6 reference “rg-6” as the URL, and again the home page was in-
stantly visible! Using tcpdump again, I could verify that this time the page had been
transferred using IPv6. That is, first Winsock had translated the IPv4 ‘A’ request for “rg-
6” from Netscape to a both a ‘A’ and a ‘AAAA’ request. When only the IPv6 ‘AAAA’
response was returned, the protocol translation was used between Netscape and the IPv6
stack. Apparently the bump-in-the-stack mechanism works!
SOCKS
For the SOCKS server, NEC provides a publicly available SOCKS5 server-client solu-
tion. The server was easy to install on the ‘rg’ and by using an enclosed patch the stan-
dard SOCKS server extended with a protocol translator. The server needed no configura-
tion as long as I was confident with web access.
On the client side, NEC provides their ‘SOCKSCAP’ software which “socksifies” the
application you want to run. I installed the software on both client machines, and using
the configuration tool, I created a “profile” for Internet Explorer. I could now for the first
time access the global web from both clients, but only using IPv4. The reason for this was
that SOCKSCAP only accepted an IPv4 address for the SOCKS server, and thus only
uses IPv4 between the client and the SOCKS server. IPv6 support is expected in the next
release of SOCKSCAP.

ipv6_report

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (9)

Similar to ipv6_report

Similar to ipv6_report (20)

ipv6_report