Department of Teleinformatics
Royal Institute of Technology
Network Services
Telia Research AB
IPv6@home
A study on using IPv6 in home networks
A master thesis by
Christer Engman (e94_cen@e.kth.se)
Stockholm, Sweden
1999
IPv6@home
ABSTRACT
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 interest. 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 protocol, 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.
iii
IPv6@home
TABLE OF CONTENTS
1
INTRODUCTION .................................................................................................................. 1
1.1
1.2
2
BACKGROUND ................................................................................................................... 1
REPORT STRUCTURE.......................................................................................................... 1
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
v
IPv6@home
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
7.2
JINI ................................................................................................................................. 41
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
vi
IPv6@home
1 INTRODUCTION
1.1 Background
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 distributing information and has already become a potential alternative to traditional information channels such as magazines, television, radio and telephony. The Internet has also
become a vital part of many companies’ business strategies, which depends, partly or
entirely, 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 limited 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 connectivity. 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 devices and applications, which will be suitable for, or completely dedicated to, the home network market. Surveillance, home automation, resource sharing and information retrieval
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 scalability, 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 transition
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…
1.2 Report Structure
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.
1
IPv6@home
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 networking 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 provided 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 understanding.
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 upgrade 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 possibilities with IPv6.
2
IPv6@home
2 HOME NETWORKING
2.1 Vision
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 corporate LAN through a modem and to a printer. Another computer may reside in the teenager’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 everyone 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 network aware products and appliances. Probably future home electronics will be interconnected 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.
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 households 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 connecting 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 ad-
3
IPv6@home
vantage 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 enormous and will definitely involve many companies in the future. Both hardware and software vendors will have lucrative possibilities. Many experts believe that the home network 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 numerous reports or articles written in this topic.
2.2 Examples
2.2.1 Residential Gateway (Telia)
At Telia Research AB, home networks are a hot topic in research projects. The development 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 multiple 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 contains 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 development is leading.
Figure 2.2 Telia’s RG and Ericsson’s e-box
4
IPv6@home
2.3 Limitations Today
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 further 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 offices 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 allocation (QoS) and easy administration and configuration.
In the following, the new Internet Protocol version 6 (IPv6) will be studied as an alternative to today’s IPv4. After an overview of the protocol, the scenario of using it in a home
network environment will be covered.
5
IPv6@home
3 IPV6 OVERVIEW
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 consisted 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.
3.1 IPv6 Header Format
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.
0
15
Ver
IHL
31
ToS
Total Length
Identification
TTL
16
Flags
Protocol
Fragment Offset
0
Ver
15
16
Traffic Class
Payload Length
31
Flow Label
Next Header
Hop Limit
Header Checksum
Source Address
Source Address
Destination Address
Options
Destination Address
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 correctly 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 performance 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).
7
IPv6@home

Fragmentation Offset and the Options fields have been completely removed from
the IPv6 header. Instead, this information is put into separate extension headers inserted 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.
IPv6 Header
Fragmentation
Header
TCP
Header
…
Payload Fragment
Figure 3.2 Daisy-chaining of extension headers in IPv6.
3.2 ICMPv6
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 removal 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
3.3 Addressing
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
8
IPv6@home
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 available. 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 adjacent words of this kind and can therefore simplify the notation further. The second address 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 report. 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 multiple 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 address 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:
60 bits
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
9
IPv6@home
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 allocation 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.
10
Allocation
Prefix
(binary)
Prefix
(hex)
Fraction of
address space
Reserved
0000 0000
::/8
1/256
Unassigned
0000 0001
100::/8
1/256
NSAP Allocation
0000 001
200::/7
1/128
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%)
(0.8%)
(0.4%)
IPv6@home
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 introducing a multi-level address topology divided into Public, Site and Interface topologies.
The address format is as follows:
3
13
8
001 TLA ID RES
24
16
NLA ID
SLA ID
Public Topology
64 bits
Interface ID
Interface Topology
Site
Topology
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 hierarchy.

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
11
IPv6@home
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:
10 bits
54 bits
64 bits
1111111010
0
Interface ID
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 corporate 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 prefix FEC0::/10 and a new field for subnet ID.
10 bits
38 bits
16 bits
64 bits
1111111011
0
Subnet ID
Interface 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:
8 bits
11111111
4 bits
4 bits
Flags Scope
112 bits
Group ID
In the flags field, the fourth bit indicates if the multicast address is transient or not. Transient addresses are constructed for temporary multicasting sessions such as a videoconference 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 boundaries. 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].
12
IPv6@home
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 administrators to define themselves. In the concept of home networking, these could represent additional 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 addresses. 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 chosen.
B
A
C
B
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
13
IPv6@home
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.
3.4 Autoconfiguration
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 replaces 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 topology and router parameters set by the network administrator as described in the next section.
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 concatenating 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-
14
IPv6@home
tion address set to the address being tested, and source address set to the unspecified 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 message is sent to the all-routers multicast group (FF02::2).
6) In response to the ND router solicitations, routers send a unicast ND router advertisement 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 addressing, stateful autoconfiguration should be used. This is handled by DHCPv6,
which defines message types for configuring all necessary parameters.
3.5 Real-time Support
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) destination 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
15
IPv6@home
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 following hop-by-hop extension header where the actual payload length can be retrieved as
illustrated in Figure 3.4.
IPv6
Header
Hop-by-Hop
Options
Next Header
Payload
…
Hdr Ext Len
Option Type
(0xC2)
Option Length
(0x04)
Jumbo Payload Length
(0x00000000 – 0xFFFFFFFF)
Figure 3.4: The Jumbo Payload option
3.6 Mobility
IPv6 has to support mobile nodes since they are expected to be very common in the future. A method for accomplish this is defined in [20] as Mobile IPv6 and is currently under study. Mobile IPv6 has much in common with Mobile IP for IPv4. Some improvements 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 autoconfiguration 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 issues.
3.7 Security
With IPv6 comes security. Every IPv6 node is required to handle encryption and authentication 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 headers.
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 hackers where packets are sent from a hackers computer while using a trusted computers address as a source address. Authentication is also important since the autoconfiguration
16
IPv6@home
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
17
IPv6@home
4 USING IPV6 AT HOME
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 structure

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 everything may be transmitted using it, anytime and everywhere.
In the following, the enhancement areas will be covered and discussed from a home networking perspective using real-world examples and applications.
4.1 Addressing
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
19
IPv6@home
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 administration needs of the server. Another alternative could therefore be to let multiple home networks share one DNS server located at the network provider. While simplifying construction and administration of the home servers, this solution could limit the users’ possibility
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 connected 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 addresses 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.
Internet
Global addresses
Internet
Global addresses
IPv4
NAT
IPv6
Router
Home LAN
Local addresses
Home LAN
Global address
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 previously known as provider based addressing. The reason for this is that the address hierarchy 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
20
IPv6@home
when no router advertisements for that address/route are received. This will help providers 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!
4.2 Plug and Play
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 telephone 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 Section 4.4.
21
IPv6@home
4.3 Multimedia
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 purpose of delivering information, will probably end with the introduction of home networking. By using a single information network such as the Internet, all kinds of information
could be delivered in a uniform and easy accessible way (Figure 4.2).
Telephony
Television
IPv6
Data
Radio
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 Internet
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 customers. The most common way to provide broadband today is through the cable TV network, 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 transmission, 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 resource 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
22
IPv6@home
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 broadcasting media. Every IPv6 capable router is required to handle multicast routing according 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 assigned 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 distribution of audio and video. As a source, any IPv6 enabled TV receiver, DVD player or hifi 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 bandwidth, 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 sampled 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.
23
IPv6@home
+
Priority
Additional video
+
Additional audio
320 x 200 video
Full quality
High quality
+
Medium quality
11 kHz audio
Low quality
Figure 4.3: Hierarchical transmission
The low-capacity customer may now choose to receive only the first layer with lowquality 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 incremental 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 received, while the additional streams will be used only if the bandwidth admits it.
4.4 Security
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 introduced 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.
Internet
Access Server
Home Server
Group Server
Figure 4.4 The access server limits both external and internal traffic
24
IPv6@home
5 INTRODUCING IPV6 TODAY
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 December 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.
5.1 Transition Strategy
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 Intranets 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 illustrated in Figure 5.1.
The first strategy is beyond the scope of this report. Instead, the transition of home networks, and the affects of it appearing to the end users, will be covered. A typical transition 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 protocol.
IPv
6
IP
Access netw ork
v4
Home
Netw orks
Access netw ork
Core netw ork
Access netw ork
Figure 5.1 Transition from the edges and in
25
IPv6@home
Building/apartment
Access Network
Core Network
Group Server
IPv4 router
(a)
4
IPv4 router
4
4
4
4
Group Server
IPv4 router
(b)
4
Transition Box
4
4/6
4/6
4
Group Server
IPv4 router
(c)
4/6
4/6
Transition Box
6
4/6
4/6
Group Server
IPv4 router
(d)
6
6
IPv6 router
6
6
6
Figure 5.2 Four phases in an IPv4 to IPv6 transition
1. IPv4 Only. The situation for almost everyone of today’s households already connected 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 carried over IPv4 and no IPv6 nodes have been introduced.
2. IPv6 in the homes. IPv6 is introduced as a secondary protocol in the home networks. 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 limited to
small old systems. Additionally, it will probably be more common to encapsulate
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 deployed 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 tunnels for transporting IPv6 inside IPv4 packets and spans across many countries.
5.2 Transition Issues
As mentioned earlier, the IETF NGTRANS working group has presented various mechanisms for the transition from IPv4 to IPv6. The choice of appropriate mechanisms to use
26
IPv6@home
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 generated 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.
fe80:0:0:0::/64
fec0:xxxx:yyyy:zzzz::/64
fe80:0:0:0::/64
fe80:0:0:0::/64
Router Ad
Intranet
Internet
Router/Transition box
Figure 5.3 Addressing scheme for home networks
In areas with multiple households, such as a block with many flats or a complete residential 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 limited 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.
27
IPv6@home
fe80::/10
NAT/NAPT
131.115.0.0/16
SIIT
IPv6
IPv4
Internet
Home netw ork
Figure 5.4 The NAT-PT/NAPT-PT transition mechanism
When a new session starts, a new IPv4 addresses is acquired dynamically from a predefined 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 limitation, 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) communication, 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 utilizes a dynamic address allocation mechanism called Assignment of IPv4 Global Addresses 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 emphasize
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 internal IPv4/IPv6 host requests communication with an IPv4 host, a temporary IPv4 address 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 reconfigure command is sent to the host to assign it an IPv4 address. The two hosts can now
freely communicate using IPv4.
28
IPv6@home
(a)
1. DNS Request for Z
Internet
2. IPv4 Address
Z
IPv4
AIIH Server
IPv4/IPv6
X
IPv4/IPv6
(b)
Internet
X
IPv4/IPv6
2. IPv4 Address
AIIH Server
IPv4/IPv6
1. DNS Request for X
Z
IPv4
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 combining 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 configuration on the hosts to “socksify” the application sessions. This would also cause a prominent 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 between IPv4 and IPv6. For example, a web proxy server can easily be fitted with a protocol 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 application 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.
29
IPv6@home
Table 5.1 Overview of transition mechanisms for IPv4 connectivity
NAT-PT, NAPT-PT
DSTM
SOCKS 5/
IPv4 address requirements
1 per site
1 per site
Host Requirements
IPv6 stack
Dual IP stacks + DHCPv6 Application configuration
Advantages
 Very low IPv4 address
requirements (NAPT)
 True IPv4 connectivity
Application proxies
1
 Implementations
available
1
 Low IPv4 address
requirements
1 per site1
 Very low IPv4 address
requirements
 Implementations
available
 Simple configuration
Disadvantages
 Limited IPv4 application support
 No implementations
available
 Hosts need socks
configuration
 IPv4 stack required
 DHCP client required
 Limited IPv4 application 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 tunneling 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 possibility, 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 solution 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 communication 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.
30
IPv6@home
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.
IPv4
application
TCP/
IPv4
extension
name
resolver
address
mapper
translator
IPv6
IPv6
host
Query of A records for "host6"
name
server
Query of A and AAAA records for "host6"
Reply only contains an AAAA record
Request an IPv4 address for "host6"
Reply with an IPv4 address from the pool
IPv4 applications
Reply with an A record
IPv4 packet
TCP/IPv4
extension
name
resolver
address
mapper
Resolve IPv6 address
from the IPv4 address
translator
IPv6 packet
IPv6
Physical netw ork layer
(a)
IPv6 packet
IPv4 packet
(b)
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.
5.3 Implementation Status
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 realize 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 security, 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.
31
IPv6@home
6 EXPERIMENTAL SETUP
6.1 Goal
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 implementations was also a topic of interest.
6.2 Scenario
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.
131.115.
Intranet
ipv6.trab.se
131.115.159.40
rg
10.0.0.1/
::200:f8ff:fe32:5fc
Cloud
10.0.0.3/
290:27ff:fe72:93b5
10.0.0.2/
210:4bff:fe71:3e2
w in2k
w in98
Figure 6.1 Experimental network setup
6.3 Experiments
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 experience 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 Windows 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 number one OS in homes followed by Windows NT or Windows 2000 for distance working
people.
33
IPv6@home
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 Microsoft Research’s experimental stack (MSRIPv6). To install, I only had to follow the
standard 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 system. 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 provided 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].
34
IPv6@home
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 application 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):
64 bytes from fe80::290:27ff:fe72:93b5: icmp_seq=0 ttl=64
64 bytes from fe80::290:27ff:fe72:93b5: icmp_seq=1 ttl=64
64 bytes from fe80::290:27ff:fe72:93b5: icmp_seq=2 ttl=64
64 bytes from fe80::290:27ff:fe72:93b5: icmp_seq=3 ttl=64
56 data bytes
time=2.263 ms
time=2.471 ms
time=1.568 ms
time=2.443 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 begins 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 output 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
35
IPv6@home
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.
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 records by hand in the master files:
ns
A
AAAA
CNAME
10.0.0.1
fe80:0:0:0:200:f8ff:fe32:5fc
ns
win98
A
AAAA
10.0.0.2
fe80:0:0:0:210:4bff:fe71:3e2
win2k
A
AAAA
10.0.0.3
fe80:0:0:0:290:27ff:fe72:93b5
rg
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 implemented 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
64 bytes from fe80::290:27ff:fe72:93b5: icmp_seq=0 ttl=64 time=2.365 ms
64 bytes from fe80::290:27ff:fe72:93b5: icmp_seq=1 ttl=64 time=2.453 ms
...
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
64 bytes from fe80::290:27ff:fe72:93b5: icmp_seq=0 ttl=64 time=3.438 ms
64 bytes from fe80::290:27ff:fe72:93b5: icmp_seq=1 ttl=64 time=2.446 ms
...
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.
36
IPv6@home
After starting the daemon, I verified the router advertisements generated using tcpdump:
14:09:42.909022
14:13:34.909032
14:23:00.909021
14:31:44.909017
14:40:19.909023
14:49:38.909020
fe80::200:f8ff:fe32:5fc
fe80::200:f8ff:fe32:5fc
fe80::200:f8ff:fe32:5fc
fe80::200:f8ff:fe32:5fc
fe80::200:f8ff:fe32:5fc
fe80::200:f8ff:fe32:5fc
>
>
>
>
>
>
ff02::1
ff02::1
ff02::1
ff02::1
ff02::1
ff02::1
icmpv6:
icmpv6:
icmpv6:
icmpv6:
icmpv6:
icmpv6:
router
router
router
router
router
router
ad
ad
ad
ad
ad
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 network to the 6bone. The Linux IPv6 stack could handle the IPv6-in-IPv4 tunneling required, 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 restricted 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 connectivity 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.
37
IPv6@home
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 application 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 interfaces. In the database file the following lines where added:
rg-4
rg-6
A
AAAA
10.0.0.1
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 instantly 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 solution. The server was easy to install on the ‘rg’ and by using an enclosed patch the standard SOCKS server extended with a protocol translator. The server needed no configuration 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.
38
IPv6@home
Application Proxy
It came to my knowledge that the Apache web server contains proxy code and thus could
act as an application proxy for http traffic. To enable the proxy functionality the following lines had to be added to the /etc/httpd/conf/http.conf configuration file:
ProxyRequests on
<Directory proxy:*>
<Limit GET PUT POST DELETE CONNECT OPTIONS>
order deny,allow
deny from all
allow from 10.0.0.0/8
allow from fe80::/10
allow from fec0::/10
</Limit>
</Directory>
By running a clean instance of Netscape (without SOCKSCAP) and specifying the proxy
server as 10.0.0.1 (IPv4 address of ‘rg’), I could again reach the whole Internet. As with
SOCKS, I was only able to test IPv4 connectivity between the client and the proxy server.
39
IPv6@home
7 RELATED INITIATIVES
As stated earlier, home networking is currently a very hot topic. Besides the development
of a new Internet protocol, various other technologies are being developed to realize the
vision of home networking.
7.1 JINI
Jini is a high-level connection technology developed by SUN Microsystems. The goal is
to enable the implementation of “smart devices” – a device that can self-configure, selfdiagnose, and self-install. New concepts includes:

Instant on: true plug and play support. Services and resources are immediately
made available without fuss.

Impromptu community: Automatically creates the Jini network or community –
anytime, anywhere.

Resilient: Jini communities adapt very quickly to changes in the topology.

Special delivery: Jini technology services are available on demand, whenever they
are needed.
For more information about Jini and its applications, please refer to SUN’s web site dedicated to the Jini technology at http://www.sun.com/jini.
7.2 Universal PnP
Universal Plug and Play (UPnP) represents Microsoft’s initiative in home networking.
UPnP is an open standard technology based on traditional IP solutions, which makes it
both flexible and cost effective.
Some key features in UPnP includes:
 Automatic Private IP Addressing based on DHCP and AutoIP (similar to IPv6
Neighbor Discovery)

Multicast Name Resolution and Dynamic DNS updates.

Simple Service Discovery Specification including the new Simple Service Discovery Protocol (SSDP).
UPnP extends IPv4 with new features similar to native functionality in IPv6. Although,
this adapts IPv4 for home networking, the solution is not as future proof as upgrading to
IPv6. The development of this kind of extensions may hold back the development of IPv6
since the need of an upgrade is reduced.
41
IPv6@home
8 CONCLUSIONS
It is time to summarize, and the big question to be answered seems to be:
– Should IPv6 be introduced as the standard protocol for home networking?
A short answer to this question turns out to be:
– Yes! Eventually…
IPv6 will definitely become the dominating protocol in the future. It provides many new
features suited for the upcoming demands in internetworking and especially home networking. Throughout this report, many advantages over IPv4 have already been revealed:

128-bit address to allow more globally unique nodes

autoconfiguration with neighbor discovery and mobility support

hierarchical addressing and routing

anycasting and native support for multicast

better performance through optimized headers

quality of service support with flows and traffic classes

integrated security using IPsec
All these new or enhanced features will indeed suit the home network environment to
some extent in the future. It is hard to say, though, since neither IPv6 nor home networking has been fully deployed yet. Personally, I consider the autoconfiguration mechanisms
the most appealing feature in a home network.
The number one reason for developing IPv6, the larger address space, is of course also a
very important factor. Eventually, IPv6 will allow home users to assign all their devices
and appliances with globally unique IP addresses for easy access. However, initially the
solution with using IPv6 in the home network while the outside networks still only provide IPv4 will not be different from using private IPv4 addresses. Only when IPv6 is
introduced throughout the whole access and core networks, and IPv6 connectivity will be
more common, the addressing advantages will become obvious. It’s like the hen and
chicken problem – IPv6 addressing will not be superior IPv4 until global IPv6 addressing
is introduced.
Today, many of the advantages IPv6 has over IPv4 have already been realized as additional extensions to IPv4 such as multicasting and router discovery. Technologies such as
Jini and UPnP also introduce features such as autoconfiguration and discovery to try to
adapt IPv4 for home networking. This is however not nearly as good as using IPv6,
which provides this functionality natively.
So, when should the IPv6 introduction in the homes begin? Is it too early to begin now?
Commercial deployment of IPv6 today is far too risky due the experimental status of the
protocol. Many specifications are still in progress and implementations likewise. Personally, I was quite surprised over the incompleteness of IPv6. There is currently not one
single implementation of the IPv6 stack, which includes all of the specified functionality.
Overall, IPv6 implementations today are very experimental and often contain bugs or lack
functionality. This was quite surprising to discover bearing in mind that the development
has been underway since 1994.
43
IPv6@home
As a final conclusion, IPv6 should be taken into consideration in future projects related to
home networking and similar areas to provide more insight and understanding. However,
the introduction should wait until a complete solution can be presented and verified.
44
IPv6@home
9 FUTURE WORK
IPv6 is still under development and currently lacks commercial implementations. For
Telia, this means a unique possibility to participate and affect the final specifications to
suit Telia’s needs. To keep up with the competing operators, Telia should also consider
the following actions:

Follow the development of IPv6 by joining the major mailing lists and participate
in discussions and seminars.

Conduct more research and thesis works related to IPv6 to further investigate the
suitability in various scenarios.

Follow the transition strategy and investigate the possibilities for IPv6 in access
and core networks.

Look for “killer applications” that utilizes IPv6 and thereby increase its importance.

Investigate the possibility of using IPv6 for dial-up connections. To further increase the interest, IPv6 traffic could be billed at a reduced rate.
45
IPv6@home
10 REFERENCES
Web Resources
[1]
6bone – The testbed for deployment of IPv6, <http://www.6bone.net/>
[2]
Internet Assigned Numbers Authority (IANA), <http://www.iana.org/>
[3]
IPv6 & Linux – Howto, <http://www.bieringer.de/linux/IPv6/IPv6HOWTO>
[4]
IPv6 Information Page, <http://www.ipv6.org/>
Literature
[5]
W. Biemolt, M. Kaat, R. van der Pol, H.Steenman, “A Guide to the Introduction of IPv6
in the IPv4 World”, draft-ietf-ngtrans-introduction-to-ipv6-transition-01.txt (work in
progress).
[6]
S. Berson, “RSVP and Integrated Services with IPv6 Flow Labels”, draft-berson-rsvpipv6-fl-00.txt (work in progress)
[7]
D. Borman, S. Deering, R. Hinden, “IPv6 Jumbograms”, RFC 2675, August 1999.
[8]
J. Bound, C. Perkins, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6)”, draftietf-dhc-dhcpv6-14.txt (work in progress)
[9]
R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, “Resource ReSerVation Protocol
(RSVP)”, RFC 2205, September 1997
[10]
B. Carpenter, K. Moore, “Connection of IPv6 Domains via IPv4 Clouds without Explicit
Tunnels”, draft-ietf-ngtrans-6to4-02.txt (work in progress).
[11]
B. Carpenter, C. Jung, “Transmission of IPv6 over IPv4 Domains without Explicit
Tunnels”, RFC 2529, March 1999.
[12]
A. Conta, S. Deering, “Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification”, RFC 2463, December 1998.
[13]
M. Crawford, “Transmission of IPv6 Packets over Ethernet Networks”, RFC 2464,
December 1998
[14]
M. Crawford, C. Huitema, S. Thomson, “DNS Extensions to Support IPv6 Address
Aggregation and Renumbering”, draft-ietf-ipngwg-dns-lookups-04.txt (work in progress).
[15]
S. Deering, R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, RFC 2460,
December 1998.
[16]
R. Gilligan, E. Nordmark, “Transition Mechanisms for IPv6 Hosts and Routers”, draftietf-ngtrans-mech-04.txt (work in progress).
[17]
R. Hinden, S. Deering, “IP Version 6 Addressing Architecture”, RFC 2373, July 1998.
[18]
R.Hinden, M. O’Dell, S. Deering, “An IPv6 Aggregatable Global Unicast Address
Format”, RFC 2374, July 1998.
[19]
C. Huitema, “IPv6, The New Internet Protocol”, Second edition, Prentice-Hall 1998.
[20]
D. Johnson, C. Perkins, “Mobility Support in IPv6”, draft-ietf-mobileip-ipv6-08.txt (work
in progress).
[21]
C. Karlsson, “RFI: Residential Gateway”, Telia Research AB, October 1998.
[22]
S. Kent, R.Atkinson, “IP Authentication Header”, RFC 2402, November 1998.
[23]
S. Kent, R. Atkinson, “IP Encapsulating Security Payload (ESP)”, RFC 2406, November
1998.
47
IPv6@home
[24]
S. King, R. Fax, D. Haskin, W. Ling, T. Meehan, R. Fink, C. E. Perkins, “The Case for
IPv6”, draft-ietf-iab-case-for-ipv6-04.txt (work in progress).
[25]
H. Kitamura, A. Jinzaki, S. Kobayashi, “A SOCKS-based IPv6/IPv4 Gateway
Mechanism”, draft-ietf-ngtrans-socks-gateway-02.txt (work in progress)
[26]
T. Larder, “Transition Scenarios and Solutions”, draft-ietf-ngtrans-trans-scenes-00.txt
(work in progress).
[27]
T. Narten, E. Nordmark, W. Simpson, “Neighbor Discovery for IP Version 6”, RFC
2461, December 1998.
[28]
K. Nichols, S. Blake, F. Baker, D. Black, “Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers”, RFC 2474, December 1998.
[29]
E. Nordmark, “Stateless IP/ICMP Translator (SIIT)”, draft-ietf-ngtrans-siit-06.txt (work
in progress)
[30]
W. Stallings, “Data and Computer Communications”, Fifth edition, Prentice-Hall 1997.
[31]
S. Thomson, C. Huitema, “DNS Extensions to support IP version 6”, RFC 1886,
December 1995.
[32]
S. Thomson, Y. Rekhter, J. Bound, “Dynamic Updates in the Domain Name System (DNS
UPDATE)”, RFC 2136, April 1997
[33]
S. Thomson, T. Narten, “IPv6 Stateless Address Autoconfiguration”, RFC 2462,
December 1998.
[34]
L. Toutain, J. Bound, “Dual Stack Transition Mechanism”, draft-toutain-ngtrans-dstm00.txt (work in progress)
[35]
G. Tsirtsis, P. Srishuresh, “Network Address Translation - Protocol Translation (NATPT)”, draft-ietf-ngtrans-natpt-06.txt (work in progress)
[36]
K. Tsuchiya, H. Higuchi, Y. Atarashi, “Dual Stack Hosts using the "Bump-in-the-Stack"
Technique (BIS)”, draft-ietf-ngtrans-bis-00.txt (work in progress).
[37]
C. Walton, “IPv6 - At the Starting Line”, Netware Connection, May 1999, pp 6-17.
48
IPv6@home
Appendix A
AUTOCONFIGURATION PROCESS
The autoconfiguration process described in Section 3.4.2 can also be visualized in a
flowchart describing the steps involved – from activation of the interface to the final address assignment:
Interface activated
Neighbor
discovery
Create Linklocal address
Unique?
No
Manual/Random
address
Yes
Stateless AC
No
Assign to
interface
Router
present?
Yes
Managed
flag set?
No
Create address
from given prefix
Yes
Site-local or global
address assigned
Stateful AC
DHCP server
available?
No
Use Link-local
address
Yes
Get configuration
parameters
Site-local or global
address assigned
49
IPv6@home
Appendix B
IPV6 IMPLEMENTATION STATUS
Companies supporting IPv6
Numerous companies and institutions around the world have been working on IPv6 for a long time
and have IPv6 implementations publicly available. An updated list is available at
http://playground.sun.com/pub/ipng/html/ipng-implementations.html.
IPv6 Stacks
There are many IPv6 stacks available today ranging from limited 1000 byte stacks intended for embedded systems to fully featured stacks for use in an ordinary operating
system. Below, some of the available IPv6 stacks possibly suited for the future market of
home networks are listed.
Stack
Platform
More information
Linux kernel 2.2.12
Linux
http://www.linux.org
KAME
BSD Unix
http://www.kame.net
MSR IPv6 release 1.3
Windows NT/2000
http://www.research.microsoft.com/msripv6
Trumpet Winsock 5.0
Windows 95/98/NT/2000
http://www.trumpet.com.au/index.html
Epilogue Attaché Plus6™
Integrated systems
http://www.isi.com
Applications
There are already several IPv6 enabled applications publicly available including web
servers, web browsers, ftp servers/clients, router software etc. However, the experimental
state of IPv6 makes many implementations very platform dependent. Therefore, it can be
hard to find the applications suited for your specific needs. Below, some of the most
common resources for IPv6 software are listed together with their targeted stack.
Target Stack
Resource URL
Linux
http://www.inner.net/pub/ipv6/
KAME
ftp://ftp.kame.net/pub/kame/misc/
MSR IPv6
ftp://ftp.research.microsoft.com/users/msripv6/
Transition Mechanisms
Implementation of various transition mechanisms are available or underway. The status
of some selected implementations are shown below:
Transition Mechanism
Implementation status
More information
NAPT-PT
Available for FreeBSD (KAME
stack) and Windows (MSRIPv6
stack)
http://www.labs.bt.com/technical/nat_pt/
http://www.research.microsoft.com/msripv6
DSTM (AIIH)
Implementation underway and
estimated for Linux and BSD in
Q1 2000
Jim Bound, bound@zk3.dec.com
SOCKS 5
Available for various platforms
http://www.socks.nec.com/
Application proxies
Available in various applications
such as Apache (www), squid
(www), and sendmail (mail)
http://www.apache.org/
http://squid.nlanr.net/
http://www.sendmail.org/
50
IPv6@home
Appendix C
EXPERIMENTAL SETUP DETAILS
Node details
rg
win98
win2k
Role
server/router
client
client
IPv4 Address(es)
10.0.0.1, 131.115.159.40
10.0.0.2
10.0.0.3
IPv6 Suffix
200:f8ff:fe32:5fc
210:4bff:fe71:3e2
290:27ff:fe72:93b5
OS
Red Hat Linux 6.0
Windows 2000 Professional RC2 (build 2128)
Windows 98 SE
Windows 2000 Professional RC2 (build 2128)
IPv4 Stack
kernel
MS TCP/IP
Trumpet Winsock 5.0
MS TCP/IP
IPv6 Stack
kernel-2.2.12-7v6.rpm
MSR IPv6 release 1.3
Trumpet Winsock 5.0
MSR IPv6 release 1.3
Applications
inet6-apps-0.36-2.rpm
MSR NAPT-PT
Trumpet Winsock 5.0
MSR IPv6 kit:
ipv6.exe, ping6.exe,
tracert6.exe
net-tools-1.53_v6-1.rpm
Netscape 4.5
radvd-0.5.0-2
bind-8.2-6.rpm
apache-1.3.9-1_v6.rpm
SOCKS 5 server
Interface dumps
Linux
root@rg> ifconfig
eth0
Link encap:Ethernet HWaddr 00:00:F8:32:05:FC
inet addr:10.0.0.1 Bcast:10.255.255.255 Mask:255.0.0.0
inet6 addr: fec0::1:200:f8ff:fe32:5fc/64 Scope:Site
inet6 addr: fe80::200:f8ff:fe32:5fc/10 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:218 errors:0 dropped:0 overruns:0 frame:0
TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Interrupt:9 Base address:0xfc80
eth1
Link encap:Ethernet HWaddr 00:00:E8:D9:AB:EB
inet addr:131.115.159.40 Bcast:131.115.255.255
Mask:255.255.0.0
inet6 addr: fe80::200:e8ff:fed9:abeb/10 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:543434 errors:0 dropped:0 overruns:0 frame:0
TX packets:136 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Interrupt:9 Base address:0xff80
lo
Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:3924 Metric:1
RX packets:52 errors:0 dropped:0 overruns:0 frame:0
TX packets:52 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
sit0
Link encap:IPv6-in-IPv4
inet6 addr: ::131.115.159.40/96 Scope:Compat
inet6 addr: ::127.0.0.1/96 Scope:Unknown
inet6 addr: ::10.0.0.1/96 Scope:Compat
UP RUNNING NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
51
IPv6@home
Windows 2000
Interface 4:
uses Neighbor Discovery
link-level address: 00-90-27-72-93-b5
preferred address fe80::290:27ff:fe72:93b5, infinite/infinite
preferred address fec0::1:290:27ff:fe72:93b5, infinite/604464s
link MTU 1500 (true link MTU 1500)
current hop limit 64
reachable time 15500ms (base 30000ms)
retransmission interval 1000ms
DAD transmits 1
Interface 3:
uses Neighbor Discovery
link-level address: 10.0.0.3
preferred address fe80::a00:3, infinite/infinite
link MTU 1280 (true link MTU 1280)
current hop limit 128
reachable time 34000ms (base 30000ms)
retransmission interval 1000ms
DAD transmits 1
Interface 2:
does not use Neighbor Discovery
link-level address: 0.0.0.0
preferred address ::10.0.0.3, infinite/infinite
link MTU 1280 (true link MTU 1280)
current hop limit 128
reachable time 0ms (base 0ms)
retransmission interval 0ms
DAD transmits 0
Interface 1:
does not use Neighbor Discovery
link-level address:
preferred address ::1, infinite/infinite
link MTU 1460 (true link MTU 0)
current hop limit 1
reachable time 0ms (base 0ms)
retransmission interval 0ms
DAD transmits 0
52
IPv6@home
Appendix D
AIIH
ALG
BIS
CIDR
DHCP
DNS
DS
DSTM
DSTM
FTP
IANA
ICMP
IETF
IGMP
IP
IPv4
IPv6
ISP
LAN
MTU
NAPT
NAT
ND
NGTRANS
NIC
OS
QoS
RFC
RG
RPM
SIIT
SSN
TOS
TTL
UPnP
ACRONYMS
Assignment of IPv4 addresses to IPv6 hosts
Application Level Gateway
Bump in the Stack
Classless Inter-Domain Routing
Dynamic Host Configuration System
Domain Name System
Differentiated Services
Dual Stack Transition Mechanism
Dual Stack Transition Mechanism
File Transfer Protocol
Internet Assigned Numbers Authority
Internet Control Message Protocol
Internet Engineering Task Force
Internet Group Management Protocol
Internet Protocol
Internet Protocol version 4
Internet Protocol version 6
Internet Service Provider
Local Area Network
Maximum Transmission Unit
Network Address Port Translator
Network Address Translator
Neighbor Discovery
Next Generation Transition Working Group
Network Interface Card
Operation System
Quality of Service
Request for Comments
Residential Gateway
Redhat Package Manager
Stateless IP/ICMP translator
Social Security Number
Type of Service
Time to Live
Universal Plug and Play
53